@ 2685c45c:8bc01bfd

## 1. Abstract A society is a group of individuals (members) who abide by common rules. A democracy is a society where members strive for rules defined with the maximum consciousness and consensus. To increase awareness, such a society must be completely transparent. The key challenge is to find the most consensual set of rules. Members could themselves decide: - Who to admit or exclude from membership - Which rules to submit for approval - How to approve proposed rules The proposed software does not: - Interpret the meaning of the rules - Prevent from having inconsistent sets of rules - Impose a governance structure Rather, it could be viewed as: - A framework for defining and running a society (a constitution) - A ledger which records all rules, votes and members in one place A client accessing the blockchain can, at any time, know: - The rights and duties of any member - The connections between members - The voting history of any member In summary, the software enables a web of trust on a blockchain used for voting. ## 2. A blockchain ### 2.1 Why using a blockchain The core of any society lies in maintaining an up-to-date registry of its members (1 member = 1 pubkey), along with their respective rights and duties. This information is recorded on a distributed blockchain. The advantages of using a distributed blockchain are: - No single central authority/server in charge of publishing society updates - Each block is a time unit to define anteriorities and thereby freeze the state of the society Unlike Bitcoin, there is no financial incentive to participate in the network. Instead, stakeholders may be motivated by their desire: - To support a society - To join a society - To remain part of a society ### 2.2 Structure of a block Members issue objects (as bitcoiners issue transactions) that are first stored in a mempool, prior to being 'blockchainized'. A Block has three parts: - Header - Hash of the signature of the preceding block - Object counter - Merkle root of the below objects - Content - All objects sorted - Footer - Signature of the block header (by the author of the block) Unlike Bitcoin: - There is no nonce - Objects must be arranged following an hard-coded sorting method - A block must have at least one object (no upper limit: no block size) - A block must be signed by its author - The hash of the signature constitutes the 'chain' connecting the 'blocks' > *@readers* > > We call 'block hash' the hash of the block's signature. > > In this paper, for clarity, the ideas of object's issuer and author are one. ### 2.3 Consensus mechanism Like in Bitcoin, the branch with the most leading zeros in its block hashes is the legitimate branch. To prevent spam, a block (at height n) will be relayed only if its hash is less than the one currently stored at height n. Block authors may choose to omit certain (available in mempool) objects from a block, as they would increase the block hash value. However, statistically, these excluded objects will contribute to lower a future block hash. Block time is agreed upon by members. Block authors should stick to this pace. Those who don't may be causing inconvenience for others, but won't compromise the consensus. Repeat offenders can be easily identified through their block signatures and could get banned. ### 2.4 Consensus attack An attack on the consensus can: - Censor a controversial object - Disrupt the chronology of the blockchainized objects A block author, attempting to manipulate the blockchain, can compute a malicious object solely designed to reduce his block hash. This tactic ensures that the maliciously created block will be accepted as part of the legitimate branch. This attack could be repeated on all future blocks. Some other attacks on the consensus are possible. A trustless blockchain requires POW. **But, the proposed blockchain is not trustless as it records a web of trust**. When needed, members will vote for the block they consider legitimate and it will contravene the default consensus rule. Actually, the real risk lies in members not trusting each other. ## 3. Objects ### 3.1 Common format Objects are JSONs. There are: - 5 different objects that can be recorded in the blockchain - 1 pseudo object that constitutes the blockchain The JSONs have standardized keys, known as 'attributes'. One of these is called 'core', which contains a further dictionary with its own standardized keys, known as 'fields'. > *@readers* > > - 'Pop' is abbreviated from 'population' > - 'Admin' is abbreviated from 'administration' ### 3.2 Link A link is created by 2 members signing their pubkeys. The web of trust comprises all these links. It serves as a civil registry. ### 3.3 Admin An admin: - Grants some members permission to issue some objects (even other admins) - Defines criteria for the issued objects approval (votes requirements) The set of approved admins defines the constitution of the society. Any core of an admin must have these fields: - Member: Pop of members allowed to issue objects - Boundary: Limitations on the issued objects - Approval: Vote requirements for the issued objects approval ### 3.4 Law A law is a human interpretable free text which applies to a defined pop of members. Any core of a law must have these fields: - Member: Pop of members on whom the law applies - Content: The content of the law ### 3.5 Vote A vote may concern any object (even another vote). Any core of a vote must have these fields: - Object: Pop of objects being voted - Side: The 'yes' or 'no' vote itself If a member votes twice on the same object, only the first one will count. To counteract this, the member would need to void his first vote. ### 3.6 Void A void is used to temporarily or permanently ignore objects (even other voids). Any core of a void must have these fields: - Object: Pop of objects to be ignored - Duration: Time period expressed in blocks, can be infinite Modifying an already blockchainized object requires to: 1. Void the object 2. Issue a newly created object with the wished modifications Once an admin is voided: - The children objects are unaffected - The voided admin cannot issue any further object The genesis admin, JSON object automatically created at system setup, grants full permissions to founding members. It allows them to create the first admins. Once this has been done, the genesis admin should be permanently voided. A member exists only by his links. Voiding all these means banning this member. > *@readers:* > > - 'Member pop' means 'pop of members' > - 'Object pop' means 'pop of objects' ### 3.7 Block A block is a pseudo object as it is not recorded in the blockchain but constitutes it. Like other objects: - An admin can grant some members permission to issue blocks - Issuing votes or voids concerning blocks can be allowed But unlike other objects: - Blocks do not possess explicit attributes like other JSON objects - The program implicitly assigns a 'type' attribute to blocks - Approved and voided blocks impact the default consensus rule Actually, the program identifies the legitimate branch according to the consensus rule (maximum cumulative heading 0), with these constraints: - All approved blocks must be part of this branch - This branch must not pass through any voided block In case of fork attack: - Block voters can vote for the right forking block - Block voiders could reconsider this decision voiding the approved forking block (trust crisis) > *@devs:* > > Approving/voiding blocks can lead to a rollback. Only genesis block is not approvable/voidable. ## 4. Attributes ### 4.1 Path Each object originates from the core of an admin which originates from the core of a parent admin. This continues until the genesis admin is reached. All objects and cores have an id. The path of an object A consists of all these ids: from the genesis admin till the id of A. Two blockchainized objects can't have the same path. In order to reduce conflicts, it can be advisable to choose large random numbers as ids. ### 4.2 Type An object can have only one type. A block always has the default type 'block'. A JSON object can't have this type. ### 4.3 Author This attribute stores the list of pubkeys of the members who wrote the object. Except for links, which must have exactly two authors, other objects can have from 1 to n authors. ### 4.4 Label This attribute allows members to tag objects. Members shall agree on standardized tags: tax, justice... They could even tag objects as belonging to an ideology or party. It would ease the work for voters who need guidance. ### 4.5 Context In addition to storing and relaying objects, servers can optionally store aside free texts and relay them as well. They provide explanations (such as contextual information) about the issued objects. This attribute enables linking a free text (through its hash) to an object. ### 4.6 Core All objects possess between 1 and n cores - though links which do not have one. They define the political essence of the objects. Practically, a core is a dictionary where allowed fields (keys) depend on the object type. ### 4.7 Signature Before object issuance, each member whose the pubkey is in the author list must sign all previously described attributes. This attribute stores the list of these signatures. ### 4.8 Digest | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 1 | path | list of ids | yes | yes | | 1 | type | 'link' or 'admin' or 'law' or 'vote' or 'void' | yes | yes | | 1 | author | list of pubkeys | yes | yes | | 1 | label | string of plain word(s) | yes | no | | 1 | context | string of an hash | yes | no | | 1 | core-n | dict of fields | no | yes, except for links | | 1 | signature | list of signatures | yes | yes | > *@devs:* > > In this paper, a list refers to a string where items are separated by commas without any blank space. > > Such lists are well suited for regex parsing. ### 4.9 Example The object below describes an admin with the id 29 originating from: - The core 3 of the admin 7 which originates from - The core 0 of the admin 0 (the genesis admin) This admin: - Is created by two members - Is tagged with the words 'trade' and 'justice' - Has a context file associated - Has two signatures ``` { 'path': '0-0,7-3,29', 'type': 'admin', 'author': '15a3b72c,b52d6e1a', 'label': 'trade justice', 'context': '5bc953e0', 'core-0': <This core allows to issue laws>, 'core-1': <This core allows to issue votes concerning the core-0 laws>, 'signature': '827d65b7,3c65da6b' } ``` ## 5. Member field ### 5.1 Applications The field member defines a member pop. It is used in: - Admin cores: Define who can issue objects - Law cores: Define who is concerned by the law ### 5.2 Composing pops Member pops can be composed using algebra of sets. Two keys are used: - Operand: A member pop - Operator: An operator (arity = 2) An operand is a dictionary that: - Defines a basic pop - Applies methods to this basic pop to adjust it Operators are either: - '+': Union: Merge two member pops - '-': Complement: Subtract from the first pop the members in the second pop - '&': Intersection: Keep only the members who are in both pops The simplest composition consists of just one operand. However, as shown in the following example, complex compositions (with priority rules) are also possible: - The operand-0 pop is the intersection of two other pops - The final pop is the operand-0 pop minus the operand-1 pop ``` 'core-0': |--'member': |--'operand-0': | |--'operand-10': ... | |--'operator-10': '&' | |--'operand-11': ... |--'operator-0': '-' |--'operand-1': ... ``` ### 5.3 Defining a basic pop These keys define a basic pop: - Base: Set a starting point to define the pop - Value: Define an argument to complete the base key - Future: Define whether the pop will evolve after object blockchainization The base key has these possible values: - Allmembers: - Includes all non banned members of the society - Useful for widespread rights/duties (i.e., the right to issue links) - Omits the value key - Nomember: - Doesn't include any member - Useful for giving rights/duties to few members or to members with specific locations in the graph - Supposed to be used with the method 'name' to add members to the pop - Omits the value key - Issuing: - Includes all members who have issued or co-issued objects belonging to a defined object pop - Useful for giving rights/duties to members according to their past actions - The value key must store an object pop - Pointing: - Points to an existing member pop - Useful for readability - The value key must store the path to an admin or law core The future key has these possible values: - Dynamic: The pop is recomputed at each new block by the program - Static: The pop is computed at the time of object blockchainization, only future voided links can still impact it ### 5.4 Adjusting a basic pop #### 5.4.1 Common format These keys define a method: - Method: The method's name - Arg: The argument passed to the method As several methods can be applied to the same basic pop, these keys are suffixed. These suffixes specify the methods order execution. #### 5.4.2 Name method It adds or removes the specified members from the basic pop. The arg must be a list of pubkeys prefixed by: - '+': Add member - '-': Remove member The program ignores added members who have been banned. Two keywords can be used instead of a pubkey: - @self: It denotes the pubkey(s) of the author(s) of the object - @center: It denotes the pubkey(s) of the member(s) located at the whole graph center > *@thinkers:* > > Does the center of the web of trust best reflect the values of the society? #### 5.4.3 Radius method It adds or removes members from the basic pop (which is a graph) based on how far they are from its center. The arg must be a positive or negative integer: - n: Radius + n links - -n: Radius - n links If given basic pop is a disconnected graph, the method is applied to each subgraph. > *@devs:* > > The distance between 2 members is the minimum number of links to join these 2 members. > > The center of a graph is composed of the members who have the smallest distance to all other members. > > The radius of a graph is this smallest distance. #### 5.4.4 Degree method It adds or removes members from the basic pop according to their number of links within it. This method can be used to exclude members not well integrated within the basic pop. The arg must be an integer which serves as a comparison: - n: n or more links - -n: n or less links > *@readers:* > > An integer which serves as a comparison is called a 'comparator'. ### 5.5 Digest | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | member | dict with below level-3 keys | yes | yes | | 3 | operand-n | dict with below level-4 keys | no | yes | | 4 | base | 'allmembers' or 'nomember' or 'issuing' or 'pointing' | yes | yes | | 4 | value | base='issuing', object pop <br> base='pointing', path to a core | yes | base='issuing'/'pointing', yes <br> base='allmembers'/'nomembers', no | | 4 | future | 'dynamic' or 'static' | yes | yes | | 4 | method-n | 'name' or 'radius' or 'degree' | no | no | | 4 | arg-n | method='name', list of +/- prefixed pubkeys <br> method='radius', integer (-inf,+inf) <br> method='degree', comparator (-inf,+inf)| no | any method requires an arg | | 3 | operator-n | '+' or '-' or '&' | no | no | ### 5.6 Examples The following example shows the union of two pops, forming the final member pop. The first pop is dynamic: it is re-computed at each new block. It includes: - All members within 20 hops radius around the graph's center - With at least 3 links within this 'extended central' pop The second pop references an existing member pop: the core-1 pop of the law or admin 2, itself originating from the core 0....until the genesis admin. The referenced pop could be dynamic. However, this second pop is static. ``` 'core-0': |--'member': | |--'operand-0': | | |--'core': 'nomember' | | |--'future': 'dynamic' | | |--'method-0': 'name' | | |--'arg-0': '+@center' | | |--'method-1': 'radius' | | |--'arg-1': 20 | | |--'method-2': 'degree' | | |--'arg-2': 3 | |--'operator': '+' | |--'operand-1': | | |--'core': 'pointing' | | |--'future': 'static' | | |--'value': '0-0,5-2,3-0,2-1' ``` The following example shows a pop comprising a single operand. It includes: - The object's author(s) - All his (their) current neighbors up to 5 hops away ``` 'core-0': |--'member': | |--'operand-0': | | |--'core': 'nomember' | | |--'future': 'dynamic' | | |--'method-0': 'name' | | |--'arg-0': '+@self' | | |--'method-1': 'radius' | | |--'arg-1': 5 ``` ## 6. Approval field ### 6.1 Application The approval field is used in the admin cores. It specifies voting requirements for issued objects approval. Approved objects have varying implications depending on their types: - Link: Only approved links comprise the graph (the web of trust) - Admin: Only approved admins can issue objects - Law: Once approved, a law applies to concerned members - Vote: Only approved votes counts to meet voting requirements - Void: Once approved, objects concerned by the void are ignored (voided) - Block: The legitimate branch must pass through the approved blocks > *@devs:* > > Except for laws, approved objects affect program behavior. ### 6.2 Defining approval requirements These keys define an approval field: - Quorum: Minimum percentage of voters required among eligible voters - Strength: Minimum percentage of 'yes' votes required among all votes The values of these keys are comparators between 0 and 100. If both values are equal to zero, it means that once blockchainized, the object is approved. The pop of eligible voters can be spread across multiple admin cores. It can also be dynamic, maintaining a perpetual approval uncertainty. > *@thinkers:* > > Should new eligible voters have the automatic right to challenge existing approved rules ? ### 6.3 Digest | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | approval | dict with below level-3 keys | yes | yes | | 3 | quorum | comparator [0,100] | yes | yes | | 3 | strength | comparator [0,100] | yes | yes | ### 6.4 Example In the following example, the approval requirements are: - At least 50% of the eligible voters must vote - At least 70% of the votes must be 'yes' votes ``` 'core-0': |--'approval': | |--'quorum': 50 | |--'strength': 70 ``` ## 7. Content field The content field is used in the law cores. It's a text open to human interpretation defining the content of a law. | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | content | free text | yes | yes | ## 8. Object field ### 8.1 Applications The object field defines an object pop. It is used for these objects: - Vote: Define the objects voted - Void: Define the objects to ignore Object pops can be composed in the same way as member pops (same operators). ### 8.2 Defining an object pop An object pop is a dictionary where key names mirror some attribute and field names. These keys act as filters (criteria) to select relevant objects. An object pop includes all objects that: - Satisfy criteria at attribute level - Have **at least one core** that satisfies all criteria at field level Meeting a criterion depends on its type: - Regex: Full match with mirrored attribute or field - Pop: Include mirrored pop Depending on the criteria, object pops can be static or dynamic. However, issuing votes or voids concerning a dynamic object pop means voting or voiding non yet issued objects! UX should prevent this risk. ### 8.3 Digest | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | object | dict with below level-3 keys | yes | yes | | 3 | operand-n | dict with below level-4 keys | no | yes | | 4 | path | regex | yes | no | | 4 | type | regex | yes | no | | 4 | author | member pop | yes | no | | 4 | label | regex | yes | no | | 4 | member | member pop | yes | no | | 4 | object | object pop | yes | no | | 4 | side | regex | yes | no | | 3 | operator-n | '+' or '-' or '&' | no | no | ### 8.4 Examples The following example shows an object pop, including objects: - Originating from the core 2 of the admin 9 (itself originating from the genesis admin) - With ids from 0 to 5 - That are voids or laws - That have the word 'CUSTO' in their labels ``` 'core-0': |--'object': | |--'path': '0-0,9-2,[0-5]' | |--'type': 'void|law' | |--'label': '.*CUSTO.*' ``` The following example shows an object pop which includes any object originating from the core 2 of the admin 9. It includes eventual admins and their children objects. This kind of dynamic object pops should be used carefully. ``` 'core-0': |--'object': | |--'path': '0-0,9-2,.*' ``` The following example could be an extract of a vote which concerns voids: - Originating from the core 5 of the admin 8 - Issued (or co-issued) by any member currently located within a 3-hop radius around the member 4f52da24 - Concerning laws originating from the cores 0 to 4 of the admin 8 ``` 'core-0': |--'object': | |--'operand': | | |--'path': '0-0,8-5,[0-9]*' | | |--'type': 'void' | | |--'author': | | | |--'operand': | | | | |--'base': 'nomember' | | | | |--'behavior': 'dynamic' | | | | |--'method-0': 'name' | | | | |--'arg-0': '+4f52da24' | | | | |--'method-1': 'radius' | | | | |--'arg-1': 3 | | |--'object': | | | |--'operand': | | | | |--'path': '0-0,8-[0-4]' | | | | |--'type': 'law' ``` > *@thinkers:* > > A vote concerning voids which concern laws. > > Getting the hang of it requires some mental effort! ## 9. Side field The side field is used in the vote cores. It tells whether it's a yes or no vote. | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | side | 'yes' or 'no' | yes | yes | ## 10. Duration field ### 10.1 Application The duration field is used in void cores. It specifies how long the program ignores the voided object. ### 10.2 Defining duration The duration field can have these values: - 0: Voided objects are forever ignored - n (with n>0): Voided objects are ignored during n blocks The timeframe starts after void approval. ### 10.3 Digest | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | duration | integer [0,+inf) | yes | yes | ## 11. Boundary field ### 11.1 Application The boundary field is used in admin cores. It limits the objects that can be issued. These keys define a boundary field: - Content: To restrict the content of the issued objects - Amount: To limit the amount of objects issued An object that does not fully respect the boundary field will be rejected by the network. ### 11.2 Restricting content The content key stores a dictionary where key names mirror some attribute and field names. These keys act as criteria to filter the objects that can be issued. These objects must: - Satisfy criteria at attribute level - Have **all their cores** satisfying criteria at field level Blocks possess only the type attribute. Therefore, a content restriction on blocks can only allow or forbid issuance. Meeting a criterion depends on its type: - Regex: Full match with mirrored attribute or field - Pop: Include mirrored pop - Comparator: Respect comparison logic - Boundary: - This criterion type is used to limit the boundary field of a meta-admin - A meta-admin is an admin that can generate child admins - It consists of the same data as a boundary field - All the restrictions of the mirrored boundary field must be more stringent > *@devs:* > > A regex can be more stringent than another one. For example, '[0-9]{2}' is more stringent than '[0-9]+'. Boundary criterion requires to code such a regex assessor. ### 11.3 Restricting amount These keys define the amount restriction: - Scope: - Meaning: The below restrictions can be either per member or for the whole member pop - Value: Either the string 'each' or the string 'all' - Maximum: - Meaning: Maximum number of issued objects (excluding issued objects voided) - Value: A negative non null comparator - Frequency: - Meaning: Required time gap (expressed in blocks) between object issuance - Value: A positive or null comparator ### 11.4 Digest | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | boundary | dict with below level-3 keys | yes | yes | | 3 | content | dict with below level-4 keys | yes | no | | 4 | path | regex | yes | no | | 4 | type | regex | yes | no | | 4 | author | member pop | yes | no | | 4 | label | regex | yes | no | | 4 | member | member pop | yes | no | | 4 | approval | dict with below level-4 keys | yes | no | | 5 | quorum | comparator [0,100] | yes | no | | 5 | strength | comparator [0,100] | yes | no | | 4 | object | object pop | yes | no | | 4 | duration | comparator (-inf,+inf) | yes | no | | 4 | boundary | boundary | yes | no | | 3 | amount | dict with below level-3 keys | no | no | | 4 | scope | 'all' or 'each' | yes | no | | 4 | maximum | comparator (-inf,-1] | yes | no | | 4 | frequency | comparator [0,+inf) | yes | no | > *@devs:* > > The comparator for duration has a quirk. Indeed, a zero duration means forever. ### 11.5 Examples The boundary field in the following example allows to issue laws: - That include the word 'medicine' in their labels - That concern all current and future members (or any sub-pop of this pop) ``` 'core-0': |--'boundary': | |--'content': | | |--'type': 'law' | | |--'label': '.*medicine.*' | | |--'member': | | | |--'operand-0': | | | | |--'base': 'allmembers' | | | | |--'future': 'dynamic' ``` The admin core described in the following example: - Allows all current and future members - To issue links - That are automatically approved The amount of issued links is limited: - Up to 8 links maximum per member (excluding issued links voided) - Each member must wait 1,095 blocks between two links ``` 'core-0': |--'member': | |--'operand-0': | | |--'base': 'allmembers' | | |--'future': 'dynamic' |--'boundary': | |--'content': | | |--'type': 'link' | |--'amount': | | |--'scope': 'each' | | |--'maximum': 8 | | |--'frequency': 1095 |--'approval': | |--'quorum': 0 | |--'strength': 0 ``` The admin core described in the following example: - Allows all current and future members - To issue voids - That are automatically approved These voids must: - Have the exact value 'unlink' as label - Concern links written by the void author and his direct neighbors This admin core allows each member to void his own links. Motivations might be: - The loss of confidence in a direct neighbor - The death of a direct neighbor - The wish to opt-out from the society ``` 'core-0': |--'member': | |--'operand-0': | | |--'base': 'allmembers' | | |--'future': 'dynamic' |--'boundary': | |--'content': | | |--'type': 'void' | | |--'label': 'unlink' | | |--'object': | | | |--'operand-0': | | | | |--'type': 'link' | | | | |--'author': | | | | | |--'operand-0': | | | | | | |--'base': 'nomember' | | | | | | |--'future': 'dynamic' | | | | | | |--'method-0': 'name' | | | | | | |--'arg-0': '+@self' | | | | | | |--'method-1': 'radius' | | | | | | |--'arg-1': 1 |--'approval': | |--'quorum': 0 | |--'strength': 0 ``` The meta-admin core described in the following example: - Allows 3 members - To issue admins - That require votes to be approved (80-30) These admins: - Allow some members (center + 50 hops and 6 or more links) - To issue laws - That require votes to be approved (60-50) These laws: - Must include the word 'newcomer' in their labels - Must concern all members with 3 or less links ``` 'core-0': |--'member': | |--'operand-0': | | |--'base': 'nomember' | | |--'future': 'static' | | |--'method-0': 'name' | | |--'arg-0': '+d15a4c8f,+4867ae22,+a1f8c7d4' |--'boundary': | |--'content': | | |--'type': 'admin' | | |--'member': | | | |--'operand-0': | | | | |--'base': 'nomember' | | | | |--'future': 'dynamic' | | | | |--'method-0': 'name' | | | | |--'arg-0': '+@center' | | | | |--'method-1': 'radius' | | | | |--'args-1': 50 | | | | |--'method-2': 'degree' | | | | |--'arg-2': 6 | | |--'boundary': | | | |--'content': | | | | |--'type': 'law' | | | | |--'label': '.*newcomer.*' | | | | |--'member': | | | | | |--'operand-0': | | | | | | |--'base': 'allmembers' | | | | | | |--'future': 'dynamic' | | | | | | |--'method-0': 'degree' | | | | | | |--'arg-0': '-3' | | |--'approval': | | | |--'quorum': 60 | | | |--'strength': 50 |--'aproval': | |--'quorum': 80 | |--'strength': 30 ``` > *@thinkers:* > > We don't recommend creating short-lived admins. > > A sturdy constitution (set of admins), is the hallmark of good governance. ## 12. Staying united ### 12.1 Membership feeling Using a web-of-trust to register members has several effects on social dynamics, including boosting the sense of community. Moreover, the more governance reflects members preferences, the greater this effect becomes. ### 12.2 Banning a member To prevent banned members from reappearing with new identities (new pubkeys), doxing them is essential. A highly adversarial environment would demand such caution: 1. Any member can denunciate a suspect to 'initiators' 2. 'Initiators' decide whether to issue a void concerning the links of the suspect 3. 'Neighbors' of the suspect should reveal his identity to the 'initiators' 4. 'Initiators' issue a report on the suspect to the 'judges' 5. 'Judges' vote for or against the void 6. If the void is approved, the suspect is banned and the initiators issue a law to dox him Ideally: - Communications in steps 1, 3 and 4 should be encrypted for the intended recipients - Neighbors should cooperate with initiators to avoid raising suspicions! - The report sent to judges should be anonymized Organizing the ban process in real life can be much more simple but it entails risks. Social enginery can mitigate these risks. ### 12.3 Sybill attack An attacker could assume several identities. To tackle this problem, above banning process applies with these exceptions: - Several suspects are involved - Reports can't be anonymized ### 12.4 Adversarial environment This chapter explores a high-risk use case: breaking free from an oppressive and centralized state. In this context, decentralization and anonymity are essential to survive. A society is as strong and attractive as its members being supportive of each other. This involves fostering an exclusive commercial environment. Businesses need to be encouraged while keeping members' privacy concerns paramount. In an extreme scenario, producers should trade only with their direct neighbours, who endorse the role of trader with their own direct neighbours, thus mirroring the graph's topology. Encrypting blockchain content to restrict access to members only is a misguided approach. It creates an air of mystery around the society's intentions, fuelling fear instead. To counter this, it's crucial to showcase the society's benevolent intentions, thereby undermining central state oppression and making the system as appealing as possible. The state might anyway hinder the development of such a society. In response, members could adopt this defensive strategy: 1. Dox on chain low-level managers overseeing state violence and their supports 2. Halt solidarity with doxed people until they give up doing evil 3. Update the list of doxed people 4. Attract operators of the resigned managers to enforce justice in their own society > *@thinkers:* > > We believe **total** social exclusion produces better outcomes than physical violence. We **never** encourage the latter. ## 13. Conclusion We have proposed a system for a decentralized and pseudonymous society where a built-in script language provides unparalleled flexibility in designing the constitution. Only hands-on use can demonstrate its value. The potential impact on human organizations is considerable and we urge careful consideration. All lives matter. ## 14. ANNEX 1: UX ### 14.1 A UX per use case Any political venture vulnerable to central powers could fall back on the proposed software: - Collaborative encyclopaedia - Sport association or committee - ... Devs could share customized plugins for each use case. A plugin comprises: - A set of pre-built objects - A UX Incorporating a plugin into the software would make a big difference in terms of usability: - Wizard for society setup (constitution) - Template objects to reuse/customize - Template pops and regex to reuse/customize - Simplified interface for voting - ... A draft, generic, by default, UX is detailed below. ### 14.2 Main view ``` +--------------------------------------------------------------------------+ | url: https://www.node_accepting_connections_from_some_trusted_members.io | +-------------------------+------------------------------------------------+ | Member focused | | | -------------- | o---------o---------o-------o-----o------o | | | \ /|\ / \ / /| | | | [Enter here a pubkey] | \ / | \ / \ / / | | | | | \ / | o / \ / / | o | | | States considered | \ / | \ / / / | / | | | ----------------- | o----|----o / \ / | / | | | | | / \ / \ / |/ | | | [ ] Mempool | | / \ / o------o------o | | [x] Blockchainized | | / \ / | | | | [x] Approved | |/ o-------o------o | | [ ] Voided | o | | | | +-------------------------+------------------------------------------------+ | Understand | Behave | Act | |--------------------------------------------------------------------------| | | | These 3 tabs are explained further | | | +--------------------------------------------------------------------------+ ``` The main view is divided into three sections: - Focus: Set global settings - Graph: Display the web of trust - Explorer: Explore and create objects Focus section affects both Graph and Explorer sections that: - Adopt the selected member's point of view - Show only objects with the desired states The explorer section is divided into three tabs. ### 14.3 Understand tab ``` +-------------------------+------------------------------------------+------------------------------------+ | Tree | Children | Content | +-------------------------+------------------------------------------+------------------------------------+ | v id 0 | Select | id | type | label | Status | v attributes | | |-v core 0 |------------------------------------------| |-> path: 0-0,1-0,0-0,2 | | | |-v id 0 | ( ) | 0 | law | cadaster | approved | |-> type: law | | | | |-> core 0 | ( ) | 1 | law | cadaster | approved | |-> ... | | | | |-> core 1 | (x) | 2 | law | cadaster | approved | |-v core 0 | | | |-v id 1 | ( ) | 3 | void | cadaster | approved | | |-v member | | | | |-v core 0 |------------------------------------------| | | |-v operand 0 | | | | | |-v id 0 | | | | | |-> base: allmembers | | | | | | |-> >>core 0<< | | | | | |-> future: dynamic | | | | | | |-> core 1 | | | | |-v content | | | | +--------------------------------+ | | | | | Upon approval of this law, | | | | | | a45br7h6 will become the owner | | | | | | of property 8394144 | | | | | +--------------------------------+ | +-------------------------+------------------------------------------+------------------------------------+ ``` The Understand tab serves as an object explorer. It is divided into three panels: - Tree: Tree of all admins - Children: Children objects of the selected item in the Tree panel: - An admin: A list of the cores of this admin - A core: A list of the objects originating from this core - Content: Content of the selected item in the Children panel: - A core: The JSON content of this core - An object: The JSON content of this object - No selection: The JSON content of the selected admin or core in the Tree panel ### 14.4 Behave tab ``` +---------------------------------------------------------+-------------------------------------------+ | Regulation | Content | +---------------------------------------------------------+-------------------------------------------+ | Label filter: [Add text to filter objects i.e. 'tax'] | v attributes | |---------------------------------------------------------| |-> path: 0-0,2-0,6 | | Select | path | label | status | |-> type: law | |---------------------------------------------------------| |-> issuer: 2dac829k, b7ff56ff | | ( ) | 0-0,1-2,3-4,5 | tax water | approved | |-> label: tax property | | (x) | 0-0,2-0,6 | tax property | blockchainized | |-> context: s7w7y89f | | ( ) | 0-0,3-4,0-2,5 | foreigner tax | mempool | | | |-v operand 0 | |---------------------------------------------------------| | | | |-> base: allmembers | | | | | | |-> future: dynamic | | | | | |-v content | | | +---------------------------------------+ | | | | Monthly payment expected: | | | | | - Amount: 500¥ per square meter owned | | | | | - Address: 3dsh4r44 | | | | | Well indicate your pubkey in the tx | | | | +---------------------------------------+ | |---------------------------------------------------------+-------------------------------------------+ ``` The Behave tab enables access to all laws concerning the selected member. It is divided into three panels: - Regulation: All laws concerning the selected member - Content: JSON content of the selected law ### 14.5 Act tab ``` +-------------------------+-----------------------------------+---------------------------------------+ | Tree | Content | Writer | +-------------------------+-----------------------------------+---------------------------------------+ | v id 0 | v core | v attributes | | |-v core 0 | |-v member | |-> path: 0-0,1-0,0-0,[Add id] | | | |-v id 0 | | |-v operand 0 | |-> type: vote | | | | |-> core 0 | | | |-> base: nomember | |-> pubkey: 78cq32hu, [Add cosigner] | | | | |-> core 1 | | | |-> future: dynamic | |-> label: [Add label] | | | |-v id 5 | | | |-> method 0: name | |-> context: [Add hash] | | | | |-v core 2 | | | |-> arg 0: +@center | |-v core 0 | | | | | |-v id 3 | |-v boundary | | |-v object | | | | | | |-> core 6 | | |-v content | | | |-v operand 0 | | | | | | |-> >>core 7<< | | | |-> type: vote | | | | |-> path: [Add regex] | | | | | |-v object | | |-> side: [Add 'yes' or 'no'] | | | | | | |-v operand 0 | | | | | | | | |-> path: 0-0,5-2,3-6,.+ | +----------+ | | | |-v approval | | Add core | | | | | |-> quorum: 0 | +----------+ | | | | |-> strength: 0 | +-----------------------+ | | | | | Sign and issue object | | | | | +-----------------------+ | +-------------------------+-----------------------------------+---------------------------------------+ ``` The Act tab enables to write and issue objects. It is divided into three panels: - Tree: Tree of the admins where the selected member has issuance rights - Content: JSON content of the core selected - Creator: Form to write an object (require privkey; the selected member = the visitor)