Skip to content

Instantly share code, notes, and snippets.

@Zatnosk
Last active November 22, 2017 10:29
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Zatnosk/511030352b5454045ef49d834220302d to your computer and use it in GitHub Desktop.
Save Zatnosk/511030352b5454045ef49d834220302d to your computer and use it in GitHub Desktop.
Thoughts on the properties of a decentral network

entity

  • singular
    • globally unique entity id
    • display name
      • (or collection of display names for different contexts)
  • per entity-node
    • username
      • for adressing purposes, e.g. @username@nodename
      • a nodename is either a DNS location or a custom identifier
        • a custom identifier nodename must start with a non-[letter/number/dash] symbol, to be determined. Possibly #, =, + or ?
        • an alternative scheme could be to require a .dns label after every DNS identifier, and use other labels for other naming schemes. E.g. .void to denote a fully custom scheme where collisions are expected and lookup is undefined.
    • public/private key
  • per action
    • entity-unique action id
    • signed with entity-node private key
    • federated to designated entity-nodes
      • receiving entity-node either:
        • re-sign the action before sharing further, and present it as originated here
        • forward the action as if it was a unrelated relay node
      • receiving entity-node keep a reference to originating entity-node
    • shared with audience-nodes

entity-node

  • refers to any node that serves a given entity ("every entity-node" === all nodes serving that entity)
  • entity-node identifiers must be mutually signed by every entity-node (1)
  • an entity-node MUST NOT disclose the identity or even the existence of other entity-nodes
    • unless that information is directly requested, showing previous knowledge of the other entity-node

audience-node

  • must deduplicate actions based on entity-id and action-id
  • should follow only one entity-node, but know of others in case of unavailabity
    • should ping followed entity-node after a given amount of time to check availability
    • if followed entity-node is unavailable and alternative entity-nodes known, pick one and upgrade that to followed entity-node
    • if a previously followed entity-node comes back online, so two followed entity-nodes are online, the audience-node should pick one to unfollow

what's missing?

  • what happens when an entity-node is compromised (or permanently offline) and must be disowned by the rest of the swarm?
  • what happens if a new entity-node is added, while one or more entity-nodes are offline?
    • (1) might be too strong a requirement

note

  • each node in the network should be both an entity-node and an audience-node
  • a non-audience entity-node could be a publishing platform or similar
  • a non-entity audience-node could be a indexing bot or similar
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment