There's quite a bit you can do using just account public data and public "edge" data. The common theme is that you only need to define an interpretation based on your knowledge of each key's write access. The blockchain/DAC only enforces where you can write and not what or under what conditions - but this is sufficient for a lot of things!
- This is an off-chain feature and that will be more obvious as alternative clients emerge
* Simple Anti-Sybil
- Identity verifier is a KeyID that people believe only signs off on keys that it can link to a unique identity.
* Basic Voting
- Once you filter a group by ID verifiers and legibility verifiers, you can filter out people who make "invalid" votes according to whatever interpretation of the out-edges (users to candidates) as you want.
* Basic Reputation
- Reputation is always a function of two individuals. "Do I trust him? Well, how do I trust anything? Who do I know and trust personally? Why do they know/trust/defer to?" etc. I can't think of anything that needs dependent transaction validation for simple schemes.
- with a few concessions, you can make a canonizer tree for a particular topic, hosting most of the content off-chain
Now with very basic on-chain validation rules:
* Linked Keys
- an edge signed by both keys could enable treating cliques of keys as an identity and supporting "send to clique"
* Shares on edges
- a balance can sign an edge to give that edge weight for "devotion" or other validation based on edge CDD. You can restrict share movement based on edge rules (overstock!)
Here is a basic edge:
What: Is A Unique Human
Here are some "special" edges with validation:
The DAC (shareholders using their delegates) are responsible for determining the most valuable things to bring on-chain.
The next KeyID test network (before vegas) will have this feature for developers to experiment with.