Challenge-coin secondary market

toc

What it is

This is my working document on how to create a challenge coin registry, so that people can --brag-- announce which coin(s) they have, and also put them up for adoption, sale, or trade, look up by series/number for the numbered coins, etc.

I'm doing this for the Schlock Mercenary Challenge Coins as issued via [http:http:www.kickstarter.com/projects/692211058/schlock-mercenary-challenge-coins Kickstarter].

Notes

Draft

This is a DRAFT recommendation. If (and only if) it receives a nod from the Powers That be (sic... see what I did there?), will I implement it. The implementation will be on my own hardware, or hostmonster or something that supplies tools like database backends and DDS.

FAQ

Here - 2 Questions, 2 Answers

Coin Lists

Coins will be searchable by list, by holder, by state (being one of "It's MINE! MINE! ALL MINE!", "ForTrade", "ForSale", "Lost", ...). Displayed lists will be similar to:

Coin	Series	Stamp Number	Holder	State
TagonsToughs	-	020	rip...	It's MINE!
TagonsToughs	-	314	rip...	ForTrade
				etc...

Not sure about the "Series" identifiers, whether these will be numeric ("no mark", "1", ...) or alpha ("no mark", "A", ...)

Process

Step 1: Conceptual Model

There are three entities found in the model. PoI (Person of Interest), Auctions (and sales) and the coins themselves. There may also be minor entities (The security model, etc) but those are either not being covered in this document (for ... um ... security reasons), or because I haven't thought of them yet (or they haven't been pointed out to me).

(Compact, Pseudo Gellish. Aspects with [N..M] to indicate cardinality, default is [1..1])

PoI <is> an entity PoI <can> log in, log out, transfer a Coin, change state, change password PoI <has as aspect> UserName, PasswordHash, State, Email[1..2], RealName[0..1] ...

Coin <is> an entity Coin <has as aspect> Face, Series[0..1], Serial[0..1], GUID, State[0..N], Owner, History ...

Auction <is> an entity Auction <can> transfer a Coin ...

Step 3: Type Model

Data model for the DB back-end, as expressed in Extensible Types IDL (see Extensible and Dynamic Topic Types for DDS.

code typedef unsigned long ulong32;

Role based access. Not sure if using these labels, may just go back to "reader", "reader-writer", "creater", "mod"

enum PoIState {

   Confined,         probation, basically everything will be moderated
   Brigged,          read-only access, if they want write access, they
                     have to apply to an Officer_Staff or above
   Terminated,       No longer active
   Newbert,
   Grunt,
   NCO_Company,
   NCO_Field,
   NCO_Staff,
   Officer_Company, // Merit (Mustangs)
   Officer_Field,    Must have a series TagonsToughs A099 or less
   Officer_Staff,    Must have a series TagonsToughs A020 or less
   Officer_General,  Mod

};

enum CoinState {

   Unclaimed,
   Lost,
   Claimed,
   ForTrade,
   ForAdoption,
   NotForSaleAtAll,
   MakeAnOffer,
   ForSale

};@extensibility EXTENSIBLE_EXTENSIBILITY

Note that CoinType may or may not be serial#stamped. enum CoinType {

   TagonsToughs,
   NotMyMonkey,
   Maxim_2_3,
   StrohlMunitions,
   PartnershipCollective,
   MoralCompass,
   Kitesfear,
   TouchAndGo,
   PostDatedCheckLoan,
   SerialPeacemaker

};@extensibility EXTENSIBLE_EXTENSIBILITY

struct POI {

   ulong32    userid; @key
   PoIState   state;
   ulong32    boosts;  "karma" on other boards.
   string<64> username;
   string<64> realname;
   string<64> pash;
   string<64> email_primary;
   string<64> email_secondary;

};@extensibility EXTENSIBLE_EXTENSIBILITY

struct CoinData {

   CoinType   CoinType;      @key  Like:  TagonsToughs
   ulong32    GUID;          @key  unique across all coins, psu-ran generated
   ulong32    state_SeqId;   @key
   string<5>  CoinID;              Like: 0-001 through 9-999 or 2000 - 99999
   CoinState  state;
   string<28> dtg_registeredat;
   string<28> dtg_laststatechange;
   ulong32    owner_poi;
   string<128> state_comment;

... what else?

};@extensibility EXTENSIBLE_EXTENSIBILITY

code

Step 2: CRUD

This is currently the programming interface between the data, its in-motion state, and its at-rest state. I'm using DDS as the in-motion state as it gives me access to the time-date stamps on creation, so if there're auctions, I'll know which entry comes first. Can't rely on the DB for its time-date stamps, as those could be, for performance reasons, batched. This allows multiple bids to be posted at what amounts to the same time, even if they are microseconds apart. And we can have that.

Create:

• create new (coin) entry (These will be done in bulk for the numbered coins)
• create new (poi) entry (These will be webpage-signup driven)
• create new (auction) entry (These will be webpage driven)

Read:

• read (coin) entries from the DB and format for read-only
• read (poi) entry from the DB and format for read-only
• read (auction) entry from the DB and format for read-only

Update:

• Page to update information about a (coin) entry, backend to update entry in DB
• Page to update information about a (poi) entry, backend to update entry in DB
• Page to manage an (auction), which may be any type of coin state change (sale, loss, trade, etc)

Delete:

• (coin) entries, will be a no/op. Lost coins will carry "LOST" state, not be deleted from the DB
• (poi) entries, will be a no/op. Users who retire their logins will be set to Terminated for historical/regulatory reasons
• (auction) entries, will be a no/op. A finalized/failed auction will be stored for historical/regulatory reasons

Step 3: Front-end

And lo, your eyes will BLEED, until someone steps up and says .... Dude, You need to fix the front end! It is teh ULGY to which I will wave my "Not my monkey, Not my circus" coin in front of them and say "You fix it, you get it".