Speculative-requirements.md

@@ -8,7 +8,7 @@ This page is a place to collect speculative requirements for a potential public
 
 ### Peer discovery
 
-* Discovery of nearby peers via Bluetooth and/or wifi
+* Discover nearby peers via Bluetooth and/or wifi
 * Maybe: Gossip the details of nearby/recently connected peers
 
 ### Network structure
@@ -17,12 +17,12 @@ This page is a place to collect speculative requirements for a potential public
 * 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: 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 using a personal device
+    * Issue: Operating a hub may expose users to greater risk than participating in the mesh via a personal device
 
 ### Message propagation
 
@@ -33,6 +33,7 @@ This page is a place to collect speculative requirements for a potential public
     * 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
@@ -43,7 +44,7 @@ This page is a place to collect speculative requirements for a potential public
 * 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: 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