|
|
|
This page is a place to collect speculative requirements for a potential public mesh communication system. The ideas collected here may contradict each other and are meant to be raw material, alongside user research, for identifying a coherent set of requirements.
|
|
|
|
|
|
|
|
### Communication between peers
|
|
|
|
|
|
|
|
* 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)
|
|
|
|
|
|
|
|
### Peer discovery
|
|
|
|
|
|
|
|
* Discovery of nearby peers via Bluetooth and/or wifi
|
|
|
|
* Maybe: Gossip the details of nearby/recently connected peers
|
|
|
|
|
|
|
|
### Network structure
|
|
|
|
|
|
|
|
* 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 that are reachable via the internet or national intranet (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 using a personal device
|
|
|
|
|
|
|
|
### Message propagation
|
|
|
|
|
|
|
|
* Delay tolerant
|
|
|
|
* 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: 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
|
|
|
|
* 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 to non-members 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: Prioritisation by sender
|
|
|
|
* Maybe: Prioritisation by users who forward content
|
|
|
|
* 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
|
|
|
|
* 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
|
|
|
|
|
|
|
|
### 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
|
|
|
|
* 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 |
