The system is a decentralized peer-to-peer message exchange platform which is carefully tailored to the interests of the individual user (rather than a corporation or board).
- zero-config self-hosted infrastructure
- strong cryptographic primitives for security and privacy
- inaccessible to centralized power structures
- data is private by default
- data is resilient and safe
- Users install decentralized agents on their phone, PC, router, etc.
- Individuals meet in person to establish connectivity and identities.
- Users broadcast messages to and receive messages from those they have connected with.
- Messages can be simple communication, or follow more complex rules for particular purposes such as debate, discussion, announcement, invitation, etc.
- A rich set of consensus methods aids organization of information and mutual goal-seeking.
Nodes consist of all computing devices controlled by a user.
An agent is installed on the device, and it establishes bidirectional connections with all other nodes controlled by the user, as well as connections with devices of one’s trusted friends.
Because a user and their friends control a multitude of devices, it’s possible for each user’s data to be replicated safely, and messages can be retrieved real time by routing across online nodes.
- Archive relay - has public keys to encrypt what it receives
- Access device - has private keys to decrypt what’s received from relays
A node can be both types, and in small clusters it is a requirement.
Node discovery requires at least one node in the cluster (including the connecting device) to be available at its last IP. If two people have home internet connections, it’s likely that one or the other will always be available at its previous IP.
During a typical network randomly timed “heartbeat”, the node will attempt to send a ping to a node. This node will see that the apparent IP of the node it was expecting to connect has changed, and will tell the other nodes when it heartbeats to them about the change.
When an IP changes, it will immediately attempt to connect to all nodes
- nodes establish public IP of other nodes
- IPs are shared with other nodes controlled by the user and their friends
A functioning cluster requires all nodes to communicate with enough other nodes to maintain connectivity.
Most nodes change public IP address periodically, so nodes must frequently reconnect in order to ensure address changes are noticed.
It’s not safe to leave ports open to the public, so ports will only be open at random times for small intervals to allow the new public IP of other nodes to reestablish connectivity. This requires clocks to be synchronized between nodes in a cluster with a low margin of error relative to the duration of each port opening.
the shape of the network is like so, and messages travel along it like this, and why that’s better than current system
In order to be legitimately secure, one’s historical data must not be accessible if only a single node is compromised.
Any data saved on archive relays is encrypted with the keys of at least two systems.
Current conversations with individuals are encrypted with first your public key, and then with (your friend’s node) relay’s key. Active conversations are a small fraction of all data, and are the most likely to be retrieved in-demand, so these are encrypted by a key you choose as well as a key you or one of your friends devices choose. In order to open an current conversation (perhaps to resume it, share some part of it, or simply read):
- your device attempts to connect to each node where archives of the conversation is stored.
- if it finds one, you ask the two nodes for the list of active
conversations that they have access to.
- node decrypts the latest list of active conversations, and sends it to the requesting (your) node.
- your node decrypts the payload and shows you the list.
- you select a topic, and a hash of it to the node.
- the node decrypts the latest state of the conversation with their key, and sends it to you (encrypted with your private key).
Historical data is encrypted with keys from two of your devices, and stored on you or your most trusted friends devices. Historical data is much larger in volume and not as in-demand, so a more inconvenient but more secure key selection is used. In order to view a historical (archived) conversation:
- your device joins the cluster by attempting to connect to each last known IP of other nodes.
- your device requests an index of historical texts signed with the keys corresponding to what will be used to decrypt.
- index is sent, encrypted with both public keys.
- look up title of archive, and send identifying hash to other node.
- node sends doubly-encrypted transcript of prior conversation.
Content is referenced but the details are not accessible
Deterministic key derivation allows a simple set of words (seed phrase) to generate a root key which is on an absolute minimum number of machines, and can be used to add new nodes and regain control of lost nodes.
Friends are people you know in real life, and are the only entities that you directly interact with.
Initial in-person contact is required to exchange cryptographic keys and initial IP addresses.
Someone’s set of friends are a very powerful asset. Reach and depth of knowledge increase by large factors with a useful set of friends to rely on.
Data integrity is a fundamental requirement for a useful information sharing system, leading to some basic requirements:
- at least two copies of all data on devices we choose
- all data at rest is encrypted
- loss of any machine will not result in losing any data
As the number of nodes in a cluster increases, it becomes easier to maintain functionality for its participants. Bandwidth increases, storage increases, etc.
We define the base case as being three devices in a cluster, such as two friends with only a mobile phone. where all of each participants data will be mirrored
Messages are exchanged directly between a user’s nodes and their friends.
Nodes can act as relays for messages their owner can’t read.
When users want to interact, they choose which consensus type will be used in order to define the “rules” of the interaction.
Conversations occur between groups of users, and satisfy the rules of the consensus type selected for the conversation.
Each conversation has a topic, a message pattern, and a consensus method:
Message pattern description
When something has consensus, it’s collected as an output of the process, and the exchange ends.
The consensus method is written as a simple function that is satisfied if and only if it evaluates to true.
Updated: 11 July, 2022
Created: 1 July, 2022