As a user I can apply to a jurisdiction / organization

[virgile-dev]

This is linked to #246 We could have 2 types of jurisdictions :

• open membership: anyone can join
• on approval membership: everyone can apply but only those who meet the criteria are approved.

We can reduce the criterias to essentially 2 types imo:

• based on proof of identity (as a starters, the organization creator(s) can provide a mean of communication (email, keybase, telegram etc.) where users can get instructions on what kind of info they should provide to meet criteria (ID scan, student ID number, adress etc.)
• based on cooptation: every membership has to be approved by a majority of members through a vote.

Both can be combined.

[santisiri]

So criteria would be:

• Dictatorial: jurisdiction owner decides with special admin rights.
• Democratic: members decide meeting a threshold of required votes.

I think that the first one can be configured meeting certain conditions with the latter. Just a hunch.

[santisiri]

Closed by mistake.

Also, jurisdictions = "jurisdiction.democracy.earth" & organizations = #hashtag ? food for thought.

[AlexJupiter]

@santisiri @virgile-dev I'm turning my attention to creating a mockup for this and the related issue https://github.com/DemocracyEarth/sovereign/issues/246. However, I have some questions:

1.) How would you encourage users to agree on a proof of identity? Hundreds of people could be joining an organisation and it definitely will not be an enjoyable task to prove their identities. There were some points in the white paper describing how this would "mine" the vote token, but I still cannot get my head around this.

2.) Related to the above question, I returned back to the white paper and on page 19, “Reputation” and “Singularity” scores are described for organisations. Is this something we should be concerning ourselves with at this stage? (I sort of think it is relevant, from what I can tell these are key features and are linked to the “mining” of the vote token.)

3.) By making a proof of identity "Dictatorial" this seems to go against the principles of a decentralised network, no?

4.) Could a solution be for users to "delegate" the proof of identity work to someone in the organisation. This way, if the "dictator" started doing things wrong, the community could elect a new "dictator". This idea does create more questions:

• what if the "elected dictator" wasn't actually a representative of the organisation?
• still, what is the motivation for that "elected dictator" to prove identities? However, I'm interested to hear your thoughts...

[santisiri]

@AlexJupiter I'll address these.

1.) How would you encourage users to agree on a proof of identity? Hundreds of people could be joining an organisation and it definitely will not be an enjoyable task to prove their identities. There were some points in the white paper describing how this would "mine" the vote token, but I still cannot get my head around this.

We are not addressing this at all on Sovereign right now. Just doing a standard user system (integrating with id providers like Facebook or Blockstack) and moving forward. In the meantime we'll implement a model of membership based on the very same liquid vote token logic we have in place.

2.) Related to the above question, I returned back to the white paper and on page 19, “Reputation” and “Singularity” scores are described for organisations. Is this something we should be concerning ourselves with at this stage? (I sort of think it is relevant, from what I can tell these are key features and are linked to the “mining” of the vote token.)

No.

3.) By making a proof of identity "Dictatorial" this seems to go against the principles of a decentralised network, no?

Yes.

4.) Could a solution be for users to "delegate" the proof of identity work to someone in the organisation. This way, if the "dictator" started doing things wrong, the community could elect a new "dictator". This idea does create more questions:

What @virgile-dev refers to is the idea of Cooptation: you get approved by other members simply voting you are legitimate. Given a certain threshold (51% of yes votes? a minimum of 25 votes?) then you get approved as member and get your vote subsidy (right now at 1000 votes per new member in the code).

[AlexJupiter]

Thanks for the clarification @santisiri, I'm excited to return to fleshing out some of these questions in the coming months.

51% of yes votes? a minimum of 25 votes?

This sounds like a good starting point, especially with the minimum of 25 votes. And it'll be good to test this out with the ambassadors.

[santisiri]

@AlexJupiter yes, contemplate though that it would be ideal to have those two variables (minimum percentage and quorum) to be configurable.

[AlexJupiter]

@santisiri @medied I was just testing out Aragon, and the minimum percentage and quorum are immutable once you have created an organisation. I just want to confirm that this is a limitation of Aragon, and not a limitation of the underlying blockchain technology.

[virgile-dev]

@AlexJupiter that's a good question to ask them. But basically from my understanding once you deploy an organization, the smart contract (a DAO one) is not that easy to edit afterwards. This is for technical reasons but also because the change of these rules would have to be decided in a democratic way. So I guess they made it immutable for simplicity because the product is still in early stages.

[santisiri]

I'd go for what meets the expectation of the human > the expectation of the machine. Blockchains do have issues with upgradeability so it makes sense they worked it out that way as @virgile-dev.

We removed vote duration for instance. And our goal here is membership criteria, which means if votes are no longer there, then there's expulsion. More gray areas. Food for thought.

[AlexJupiter]

expectation of the human > the expectation of the machine

Sure, of course. And we can always adjust the designs due to technical implementation timelines if it comes down to it.

[AlexJupiter]

@santisiri @virgile-dev, @agazima and I are moving onto researching more about the UX implementation of organisations and we have a couple of questions at this stage:

• Can vote tokens be restricted to organisations? In other words, if a user joins an organisation and they receive votes, either by a drip or by a fellow organisation member delegating them their votes, then can these votes be used in another organisation?
• Do ballots always have to be attached to an organisation? In other words, there will still be the option of posting public ballots like at the moment on Sovereign right?
• Inside an organisation, will a member ever be able to request votes?
• In terms of an organisation dripping votes to a member, we are operating under the assumption that if a member does not use their votes, these votes just keep adding up. For example, there isn't the condition that a member gets 10 votes every week, and if they don't use them that week the counter gets set to zero for the next week. Is this assumption correct?

[santisiri]

Can vote tokens be restricted to organisations? In other words, if a user joins an organisation and they receive votes, either by a drip or by a fellow organisation member delegating them their votes, then can these votes be used in another organisation?

We are viewing organisations operate just as any other user in the system (as in Twitter). So yes, they would get votes once coopted valid.

Do ballots always have to be attached to an organisation? In other words, there will still be the option of posting public ballots like at the moment on Sovereign right?

You mean ballots that are anonymous? I think should be a possibility, yes.

Inside an organisation, will a member ever be able to request votes? In terms of an organisation dripping votes to a member, we are operating under the assumption that if a member does not use their votes, these votes just keep adding up. For example, there isn't the condition that a member gets 10 votes every week, and if they don't use them that week the counter gets set to zero for the next week. Is this assumption correct?`

Organisations can get votes delegated (and hence delegate to others). But only users get votes dripped via their proof-of-identity right (which we haven't discussed yet.. we're just building primitives to address that).

So I guess that, if users == organisations, the only difference between them is if they have been effectively verified via proof of identity, which would make the account valid for vote dripping. Otherwise that entity can get votes if delegated by others.

[paula-berman]

@AlexJupiter to your first question - if an organization (just another user in the system) delegates to their users, there will be no restriction.

[santisiri]

For the current milestone we will focus on doing this in a manual way, so I'll put this feature in the Version 1.0.0 milestone.

[santisiri]

The way we are handling jurisdictions is now based on blockchains, nation-states and domain names as described in #246 also.