@rockhoward
An excellent starting point. Here are a few random thoughts:
Restrict the voting systems to those that make sense for the given type of election. A 'one voting system per group' cannot work for a legitimate organization unless the organization restricts themselves to one type of election.
An excellent point. That could be added to the voting rules in group specifications: which voting system is used under which circumstances.
Avoid inferior voting systems to the degree possible. (I know that all voting systems are flawed, but some are seriously broken. It pains me to see anyone suggest that instant runoff or plurality voting makes sense for any election much less for the all the types of elections that might arise.)
I agree that some voting systems cause major problems and should be avoided. That being said, I want the protocol itself to be as open ended as possible.
I think you have to design the system to support liquid democracy from the start if that is the ultimate objective. If you don't, I fear that you will never get there. Furthermore you need to provide a compelling reason for people to use this protocol over other similar protocols that are under development. You might as well bake in your very best aspirations.
Absolutely.
Furthermore you need to provide a compelling reason for people to use this protocol over other similar protocols that are under development.
My highest priority is to have a protocol out there that allows people to easily create and run blockchain based organizations. If there are other protocols already out there that do that, then I would love to hear about them.
The thing that most compels me to work on this is that I personally want to be able to easily start or join and participate in organizations that offer more transparency and accountability and more of a voice to their members. If other people want the same and find this a useful tool to do that, so much the better.
A templating system should be built in that can capture common organization structures. Think in terms of 'make simple things simple and complicated things possible'.
That would be a good thing to include in a client.
The issuance model (like every issuance model I have seen in the bitcoin 2.0 world), is naive. There needs to be support for tiered ownership (shares vs. preferred shares and such) as well as for shelf registration which is the issuance of shares that are not to be actualized and distributed until they are unlocked by certain conditions (typically a vote of the Board of Directors.)
Shares vs. preferred shares could be done with multiple tokens.
Shelf registration could be done with a shelf share token that can be burned to create active shares, when the conditions are met. A provision for that would have to be included in issuance rules for shares.
Speaking of which, most organizations will need a Board of Directors baked in. If you can get that group pinned down in gory detail, you should have a group definition that can work for most other situations where a group might make sense.
This comes back to the templates.
Finally there is the question of 'who issues the tokens'? If it is an individual, then the organization cannot survive the demise of that individual. That may be fine for some situations, but not many.
That would differ on a token by token basis. When a token is created the creator includes issuance rules. They can also specify initial balances that certain individuals and/or groups get.
Here are some example rules:
- No new token units are issued
- Anyone who sends 1 BTC to a certain address gets 1000 tokens
- Holders of the token get a 1% dividend once every 30 days
- Any member of GroupX gets 50 tokens/per week
This is a fundamental question that begats others like 'can an organization restructure itself and, if so, how?'
Some organizations need the flexibility to restructure themselves. Others may need to be unchangeable to be trusted, much like Bitcoin gains trust from the fact that the issuance schedule is unchangeable.
I think the way to go is that when a group is created a set of rules can be included specifying the conditions under which the group can be changed.
For example BobCorp_Board should not be able to restructure itself, but BobCorp, i.e. the shareholders, may be able to restructure both BobCorp and BobCorp_Board.
Note that an organization can consist of many groups, but the protocol itself doesn't have any concept of an organization, just groups and how they interact.
I am following you on github. If you like I can recast some of the above as issues and/or send you pull requests.
I would happily welcome pull requests.
