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