| ... | ... | @@ -54,6 +54,7 @@ This page is a place to collect speculative requirements for a potential public |
|
|
|
* Short-range communication via Bluetooth and/or wifi
|
|
|
|
* Maybe: Long-range communication via internet (with or without Tor)
|
|
|
|
* Maybe: Long-range communication via national intranet (without Tor)
|
|
|
|
* Worth mentioning: Alternative physical transport support (LoRa, Satellite via directional antenna, Wifi Halow, QR code/paper propagation etc)
|
|
|
|
|
|
|
|
### Peer discovery
|
|
|
|
|
| ... | ... | @@ -64,14 +65,14 @@ This page is a place to collect speculative requirements for a potential public |
|
|
|
|
|
|
|
* Direct P2P connections between users' personal devices
|
|
|
|
* Maybe: Peers that serve to improve connectivity between users' personal devices ("hubs")
|
|
|
|
* Maybe: Hubs are reachable via Bluetooth and/or wifi
|
|
|
|
* Maybe: Hubs are reachable via the internet or national intranet
|
|
|
|
* Issue: Exposure of users' IP addresses to hubs (without Tor)
|
|
|
|
* Issue: Hubs may concentrate power and access to metadata in the hands of techies
|
|
|
|
* Issue: Hubs may have dynamic IP addresses and be behind NAT/firewalls
|
|
|
|
* Maybe: Hubs publish encrypted and signed IP:port details, which are gossiped by peers and can be authenticated and decrypted by peers authorised to connect to the hub
|
|
|
|
* Maybe: Hubs provide a STUN-like service to enable other hubs to discover their current IP:ports
|
|
|
|
* Issue: Operating a hub may expose users to greater risk than participating in the mesh via a personal device
|
|
|
|
* Maybe: Hubs are reachable via Bluetooth and/or wifi
|
|
|
|
* Maybe: Hubs are reachable via the internet or national intranet
|
|
|
|
* Issue: Exposure of users' IP addresses to hubs (without Tor)
|
|
|
|
* Issue: Hubs may concentrate power and access to metadata in the hands of techies
|
|
|
|
* Issue: Hubs may have dynamic IP addresses and be behind NAT/firewalls
|
|
|
|
* Maybe: Hubs publish encrypted and signed IP:port details, which are gossiped by peers and can be authenticated and decrypted by peers authorised to connect to the hub
|
|
|
|
* Maybe: Hubs provide a STUN-like service to enable other hubs to discover their current IP:ports
|
|
|
|
* Issue: Operating a hub may expose users to greater risk than participating in the mesh via a personal device
|
|
|
|
|
|
|
|
### Message propagation
|
|
|
|
|
| ... | ... | @@ -79,44 +80,44 @@ This page is a place to collect speculative requirements for a potential public |
|
|
|
* Store-carry-forward (sneakernet)
|
|
|
|
* Maybe: Epidemic forwarding
|
|
|
|
* Maybe: Unicast messages
|
|
|
|
* End-to-end encryption with forward secrecy
|
|
|
|
* Maybe: U-ACKs or signed receipts to enable peers to stop propagating messages that have been delivered
|
|
|
|
* Maybe: Destination addresses or flow labels to enable peers to route unicast messages intelligently
|
|
|
|
* Maybe: Reverse-path routing of replies
|
|
|
|
* End-to-end encryption with forward secrecy
|
|
|
|
* Maybe: U-ACKs or signed receipts to enable peers to stop propagating messages that have been delivered
|
|
|
|
* Maybe: Destination addresses or flow labels to enable peers to route unicast messages intelligently
|
|
|
|
* Maybe: Reverse-path routing of replies
|
|
|
|
* Maybe: Labels for encrypted messages to enable recipients to recognise which decryption key should be used
|
|
|
|
* Issue: Labels may expose metadata about which peers are communicating with each other
|
|
|
|
* Maybe: Periodic rotation of labels to reduce metadata exposure
|
|
|
|
* Issue: Labels may expose metadata about which peers are communicating with each other
|
|
|
|
* Maybe: Periodic rotation of labels to reduce metadata exposure
|
|
|
|
* Maybe: Encourage users to take part in message propagation (eg by showing propagation stats to users)
|
|
|
|
|
|
|
|
### Scalability
|
|
|
|
|
|
|
|
* Issue: Epidemic forwarding may not scale to large networks or high traffic volumes
|
|
|
|
* Maybe: Distinct, invitation-based sync contexts ("swarms")
|
|
|
|
* Issue: A user's membership of a swarm may be sensitive information
|
|
|
|
* Maybe: Peer discovery is independent from swarm membership, so that swarm membership is not exposed via peer discovery
|
|
|
|
* Maybe: Peers can discover which swarms they have in common (if any) without revealing which other swarms they belong to (private set intersection)
|
|
|
|
* Maybe: Peers can discover other swarm members via DHT
|
|
|
|
* Issue: Exposure of swarm membership to DHT nodes
|
|
|
|
* Maybe: Peers can participate in syncing a swarm without being able to decrypt any content
|
|
|
|
* Issue: A user's membership of a swarm may be sensitive information
|
|
|
|
* Maybe: Peer discovery is independent from swarm membership, so that swarm membership is not exposed via peer discovery
|
|
|
|
* Maybe: Peers can discover which swarms they have in common (if any) without revealing which other swarms they belong to (private set intersection)
|
|
|
|
* Maybe: Peers can discover other swarm members via DHT
|
|
|
|
* Issue: Exposure of swarm membership to DHT nodes
|
|
|
|
* Maybe: Peers can participate in syncing a swarm without being able to decrypt any content
|
|
|
|
* Maybe: Prioritisation of traffic
|
|
|
|
* Maybe: Global prioritisation criteria (eg text messages take priority over file attachments)
|
|
|
|
* Maybe: Author of content chooses its priority (locally or globally)
|
|
|
|
* Maybe: Each user who forwards content chooses its priority (locally)
|
|
|
|
* Issue: User's prioritisation of content may reveal sensitive information
|
|
|
|
* Maybe: Prioritisation based on transport characteristics (eg don't send file attachments via expensive satellite uplink)
|
|
|
|
* Maybe: Global prioritisation criteria (eg text messages take priority over file attachments)
|
|
|
|
* Maybe: Author of content chooses its priority (locally or globally)
|
|
|
|
* Maybe: Each user who forwards content chooses its priority (locally)
|
|
|
|
* Issue: User's prioritisation of content may reveal sensitive information
|
|
|
|
* Maybe: Prioritisation based on transport characteristics (eg don't send file attachments via expensive satellite uplink)
|
|
|
|
* Maybe: Declare an area of relevance for content (eg a country or city) and choose which areas to sync
|
|
|
|
* Issue: A user's choice of areas may be sensitive information
|
|
|
|
* Issue: A user's choice of areas may be sensitive information
|
|
|
|
* Maybe: Limit the range of propagation (eg hop counters)
|
|
|
|
* Issue: Hop count may reveal which peer originated a message and thus reveal a user's ownership of an identity
|
|
|
|
* Issue: Hop count may reveal which peer originated a message and thus reveal a user's ownership of an identity
|
|
|
|
|
|
|
|
### Contacts and identities
|
|
|
|
|
|
|
|
* Maybe: Invite someone to join the mesh
|
|
|
|
* Maybe: Invite someone to join a swarm
|
|
|
|
* Maybe: Associate user identities with connected peers
|
|
|
|
* Issue: A user's ownership of an identity may be sensitive information
|
|
|
|
* Maybe: Start a conversation with the user of a connected peer
|
|
|
|
* Issue: A user's ownership of an identity may be sensitive information
|
|
|
|
* Maybe: Start a conversation with the user of a connected peer
|
|
|
|
* Maybe: Start a conversation with a user via a message they authored
|
|
|
|
* Maybe: Start a conversation with a user after learning their identity out of band (eg via their social media profile)
|
|
|
|
* Maybe: A user can have multiple identities
|
|
|
|
* Maybe: A user can have the same identity on multiple devices |
|
|
|
* Maybe: A user can have the same identity on multiple devices |
|
|
\ No newline at end of file |
