manbytesgnu_site

Source files for manbytesgnu.org
git clone git://holbrook.no/manbytesgnu_site.git
Info | Log | Files | Refs

20210516_village_protocol.rst (10894B)


      1 A village network protocol
      2 ##########################
      3 
      4 :date: 2021-05-19 10:40
      5 :category: Hygiene
      6 :author: Louis Holbrook
      7 :tags: p2p,protocol,network,crm,privacy,f2f,community
      8 :slug: village-network-protocol
      9 :summary: What would truly peer-to-peer CRM backend look like?
     10 :lang: en
     11 :status: published
     12 
     13 
     14 What would truly peer-to-peer CRM backend look like? And at that, once that respected the right of the "customer" to choose how it wants to represent itself in the context?
     15 
     16 Perhaps by Modeling the network on how villages treat strangers and their own, and how you would go about interacting with them.
     17 
     18 Here's an initial stab at describing what such a meta-protocol could look like.
     19 
     20 .. There is no truth. There is only perspective and predictability.
     21 
     22 Terms
     23 =====
     24 
     25 Individual
     26         A subjective structure where the thing being described is the thing that described it.
     27 
     28 User
     29         A particular perception of an individual by an entity in the network.
     30 
     31 Userspec
     32         Data structure containing details about a user. May or may not be public.
     33 
     34 Locals
     35         A group of individuals acknowledging each other as part of a group, and who share views on users.
     36 
     37 Local
     38         A member of a group of locals, from the shared perspective of an individual and another local.
     39 
     40 Localslist
     41         The individuals making up a group of locals, from the perspective of a local.
     42 
     43 Stranger
     44         A user as percieved by a group of locals.
     45 
     46 Strangerlist
     47         All users that may speak to the locals, from the perspective of a local. To be shared among locals.
     48 
     49 Strangerspec
     50         Userspec created by a local describing a user. To be shared among locals.
     51 
     52 Entity
     53         An individual or any derived representation of it (user, stranger, local).
     54 
     55 Peer
     56         An entity coupled with connection information        
     57 
     58 Content address
     59         SHA256 sum of arbitrary content
     60 
     61 Key setup
     62         May be an individual key, or a specification describing how to generate keys for a particular relation.
     63 
     64 
     65 Roles
     66 =====
     67 
     68 
     69 The individuals
     70 ---------------
     71 
     72 Are free to have their own opinion of what they are.
     73 
     74 When interacting with others, they are free to choose what they say about what they are.
     75 
     76 An individual initially *defines itself* in the network.
     77 
     78 
     79 The users
     80 ---------
     81 
     82 A user is a view of an individual as defined by one or more other individuals.
     83 
     84 It may be how an individual presents itself to an particular individual or a group.
     85 
     86 It may also be how an individual or a group presents another individual to itself.
     87 
     88 
     89 The locals
     90 ----------
     91 
     92 Locals are a group of individuals who wish to share a view of themselves and prejudice about others.
     93 
     94 An individual will not be treated as a local unless it and its local counterpart considers it a local.
     95 
     96 Locals may acknowledge strangers with or without proof.
     97 
     98 If one local changes opinion about a stranger, all locals should change their opinon to the same.
     99 
    100 If one local excludes a stranger, all locals should exclude the stranger.
    101 
    102 You can't keep secrets in a village. If someone says something to another local, it must assume all locals will get to know what was said.
    103 
    104 
    105 The strangers
    106 -------------
    107 
    108 A stranger is a user that's not considered local by a group of locals.
    109 
    110 A stranger may not speak to a local until the local has decided it can.
    111 
    112 If a stranger may speak to one local, it may speak all locals.
    113 
    114 
    115 Identifiers
    116 ===========
    117 
    118 The :code:`individual_id` is the identifier of an individual consists of the content address of some basic public data about the entity registering itself. The :code:`individual_id` is immutable.
    119 
    120 Any local will refer to another local by its :code:`individual_id`.
    121 
    122 A :code:`user_id` is the content address of an :code:`individual_id` together with the content address of some basic data describing the perception of the individual. 
    123 
    124 Locals describe stranger by a pair of :code:`individual_id` and :code:`user_id`. Let us call this :code:`stranger_id`. The :code:`stranger_id` is immutable.
    125 
    126 The data represented by the :code:`user_id` in a :code:`stranger_id` is visible to locals, and may or may not be public.
    127 
    128 
    129 State description
    130 =================
    131 
    132 A user keeps a state towards other entities consisting of the following content-addresses, in the given order:
    133 
    134 1. Previous state
    135 2. Userspec
    136 
    137 A local keeps a state towards its locals consisting of the following content-addresses, in the given order.
    138 
    139 1. Previous state
    140 2. Userspec
    141 3. Localslist
    142 4. Locals state
    143 5. Strangerslist
    144 6. Strangers state
    145 
    146 The state is represented by the content address of the concatenation of these content-addresses, in the given order.
    147 
    148 Any state change will be signed by the key resolvable through the :code:`individual_id`.
    149 
    150 
    151 Previous state
    152 --------------
    153 
    154 The content address of the previous state. Will be :code:`0` in the first state.
    155 
    156 
    157 Userspec
    158 --------
    159 
    160 The individual as it wants to be perceived in the current context. There is no guarantee that the individual will be viewed in this way by others.
    161 
    162 
    163 Localslist
    164 ----------
    165 
    166 A lexiographically ordered array of :code:`individual_id` that define the individuals in a group of locals.
    167 
    168 All locals must keep this list in the same state.
    169 
    170 
    171 Locals state
    172 ------------
    173 
    174 A local's last recorded state of each of the locals, in the same order as :code:`Localslist`.
    175 
    176 The recorded state is the same content address as in the state description section above.
    177 
    178 All locals must strive to keep this in the same state.
    179 
    180 
    181 Strangerslist
    182 -------------
    183 
    184 A lexiographically ordered pointer array representing a local's opinion of which users that can communicate with locals. [1]_
    185 
    186 Combination of :code:`stranger_id` and a *vote* on the specific user.
    187 
    188 The vote can be in one of three states:
    189 
    190 - Value :code:`0`, meaning local has acknowledged the user, explicitly or by following other locals. We call this state "deferred."
    191 - Value :code:`-1`, meaning a local has vetoed the user. We call this state "vetoed."
    192 - Any other value, which is the content-address of the proof accepted by the local. [2]_  We call this state "accepted."
    193 
    194 Typically, the initial vote value is :code:`0`. The value may change at any time, but may never change back to :code:`0` once set to another value.
    195 
    196 A user that is part of the list, but not vetoed, is referred to as "acknowledged."
    197 
    198 The Strangerslist state may be differ between locals, but they should strive to keep it the same.
    199 
    200 
    201 Strangers state
    202 ---------------
    203 
    204 The local's version of the current user state of the strangers, in the same order as the :code:`Strangerlist`.
    205 
    206 The Strangers state may differ between locals, but they should strive to keep it the same.
    207 
    208 
    209 Behavior of locals
    210 ==================
    211 
    212 A local may announce itself as *active* or *passive*. This should be part of the :code:`Userspec` in the locals context.
    213 
    214 
    215 Specifically, this affects the way it "votes" on strangers. A passive local:
    216 
    217 - Will always *veto* a user if *at least one active local* has vetoed it.
    218 - Will always *accept* a user if *all active locals* have accepted it. [3]_
    219 
    220 Typically, a passive local will be a bot, for example an always-online node that guarantees availability of the locals so users can request state changes.
    221 
    222 There must be at least two active locals in any group of locals.
    223 
    224 
    225 Veto dissent
    226 ------------
    227 
    228 If a local vetoes a stranger, then all locals should cut communication with that stranger.
    229 
    230 Vetoes should be adopted by all locals.
    231 
    232 If, however, other locals consider the veto to be issued in error, there are two possible outcomes:
    233 
    234 1. The vetoing local(s) abandon(s) the veto. [4]_
    235 2. The vetoing individual(s) is/are excluded by the locals.
    236 
    237 
    238 Network
    239 =======
    240 
    241 Any entity needs to define and announce itself as a :code:`peer` in order to be available on the network.
    242 
    243 A "peer" is the coupling of network connection information to an :code:`individual_id`.
    244 
    245 
    246 Discoverability
    247 ---------------
    248 
    249 Peers are kept in a `DHT <https://en.wikipedia.org/wiki/Distributed_hash_table>`_.
    250 
    251 Peers must be discoverable by their locals affiliation. [5]_
    252 
    253 
    254 Users
    255 -----
    256 
    257 Users open single-request connections to other users to annonunce, look up and prune peers. 
    258 
    259 Users may request state changes for themselves, or relay such requests for other users.
    260 
    261 
    262 Locals
    263 ------
    264 
    265 Locals keep open connections (streams) with each other.
    266 
    267 Locals continually exchange state changes.
    268 
    269 Locals should be able to audit the chain of state changes of other locals.
    270 
    271 
    272 Between locals and users
    273 ------------------------
    274 
    275 Strangers *acknowledged* by locals open single-request connections to a local to announce state changes.
    276 
    277 Locals may open single-request connections to a user to announce a change to the state of the :code:`Userspec` of a stranger. [6]_
    278 
    279 Individuals are free to deny connections from non-locals, for example if the entity has been sending garbage requests. The implementation of such sanctions is deferred to the application layer.
    280 
    281 
    282 Encryption
    283 ==========
    284 
    285 An individual may keep content totally private on the network.
    286 
    287 A user may keep different encryption keys for different contexts.
    288 
    289 If a stranger shares a key setup with a local, that setup will be shared among all locals. A local will expect to be able to communicate with a strangerr using this key setup.
    290 
    291 The stranger must be able to change the key setup towards locals.
    292 
    293 The locals may be able to change the key setup towards a stranger.
    294 
    295 The protocol should allow anything from simple symmetric key exchanges to complex forward/backward secrecy schemes.
    296 
    297 ..
    298 
    299         .. [1] Insert in this sorted list will face scaling issues when locals need to acknowledge a lot of users. The lists can be split into `buckets <https://en.wikipedia.org/wiki/Bucket_%28computing%29>`_, either statically (for example two-byte prefixes) or dynamically after crossing a certain threshold. It should not be necessary to store empty buckets.
    300 
    301 ..
    302 
    303         .. [2] This proof may map to what's commonly known as *kyc information*.
    304 
    305 
    306 ..
    307 
    308         .. [3] Perhaps with the further limitation that all active users must have accepted with the *same* proof. Otherwise, how will the passive local choose which proof to accept.
    309 
    310 ..
    311 
    312         .. [4] Observe that since the vote state cannot change back to :code:`0`, "cancelling" the veto can only be done by adding proof.
    313 
    314 ..
    315 
    316         .. [5] What exactly uniquely identifies a group of locals on the network in such a way that it cannot be hi-jacked or spoofed still needs to be thought through. Perhaps it can be a combination of a specific name with a signature from the "founders;" the first (two or more) locals in it.
    317 
    318 ..
    319 
    320         .. [6] A use-case here would be where the locals make a change for the user due to an out-of-band request from the user. This is *not*  the :code:`Strangerspec`; it is the user's current :code:`Userspec` for the given context. Of course, it's up to the user to accept the change. It may in turn request a new state change to the locals to revert it. 
    321 
    322