Flaxscrip
commented
4 years ago The protocol SHOULD be as generic as possible, allowing new peers to define their own roles.
Just like on Bitcoin, the ability to create an "ID" should be relatively unlimited. An ID on our network with no transactions (ie: no relations with a Batch_ID, Peer_ID, or any Claim_ID) is like a Bitcoin address that never gets used.
In our web-of-trust model, profile attributes become "claims" about that profile's identity. A great live example of this approach is Keybase. In my Keybase profile I claim to be the owner of cryptotech.guru and I submit a "proof" (evidence) for my claim. This generates a rich profile identity that is reinforced by adding new claims.
I don't know yet what Peer_ID.role looks like. Maybe the bicycle delivery gal has something to say about the product before it gets to the consumer. We could define a "Role Type" that would segment various roles into generic and well established supply chain roles.
Q: Is a "farmer" a distinct data type from other "people"? My thoughts: If we are sticking to "the simplest thing that could possibly work", "farmer" is what we need for the very first use case, as defined in the 2020 Pilot Example. OTOH, we do know that there will be other actors, and designing one step abstracted from "farmer" isn't insane.
What I mean by "define a data type" is what fields will there be associated with a farmer and what type of data will go into those fields (text, numeric, etc).