Thoughts about implementing IPFS over a wireless mesh network

IPFS-mesh.md

IPFS over mesh network

• Mesh networks can't use DHTs because of multi-hop performance issues
  • Traverse the network when fetching data, and publishing changes
• Provide same API as IPFS for Graph / File / Pubsub
• Use search algorithm to traverse the network until a node that has your data responds
  • Get data using content-adressible hashing
  • Send search request for the data to a local peer
    • Include list of all the peers that you can see locally
    • Peer will respond back if they have the data
    • If not, they will search for the data on all peers that you don't have in your area
    • If a searh couldn't be successful, a message will be sent back with an error
  • Multiple searches can be done in parallel
    • search peers based on distance between them (calculated by shared peers)
  • When getting a chunk of data from a search result, put it in the LRU.
    • Popular content will be available on more nodes in the network, thus faster to query
    • Unpopulr content will eventually be purged
    • Users should pin any data that they want for later
  • Participation is optional, users can leech off the network by not advertizing themselves to it and just querying when they want something
• All participants must have an LRU cache for pieces of data that they've encountered in queries that passed through them
  • Caching could be porbabilisitc so that not every node caches every chunk of data (too big)
• Pubsub using flooding through the mesh
  • Publish to all adjacent peers, use same algo for relaying the data as search, but don't expect a result
  • Event should have a topic + payload
    • Event ID is hash of topic+payload
  • If a peer has seen an event ID in the past (some amount of time), they should ignore it
  • TODO: Think about authentication, look into what IPFS pubsub is doing
  • Peers relay events regardless of whether they are subscribed or not
  • If a peer receives a publish for an event that they are subscribed on, they handle it, otherwise they relay it onward
  • Pubsub participation should be optional
• IPNS-like support for addressing data that should change over time
  • In addition to storing file chunks, nodes will also need to store NS records
  • NS records use a public key hash + a content hash + a timestamp + signature of the hash+timestamp
  • Use pubsub "ipns:/publickey" topics with the record to propogate changes
  • When a node recieves an IPNS event, they must check their local cache and update the record for that public key signature
    • If the timestamp recieved is older than the one stored, ignore it
  • When looking up an IPNS url, see if you have the local hash cached, use it, else do a search similar to the content search
• Mesh should use WIFI-direct and alternatives
  • Android Wifi p2p
  • iOS MultipeerConnectivity
  • iOS example without Multipeer WiTap
  • On nodejs Windows, use windows.devices.wifidirect
  • Figure out linux? maybe this
• Consider using BLE for interop between iOS and Android
• Look up peers on local networks to improve performance if people are on the same wifi network
• Interoperate with existing IPFS infrastructure when necessary
  • If possible run a regular IPFS node on the same client
  • When searching for data, search the mesh first, and use IPFS as a fallback
  • For pubsub and files / graph, perform operation on mesh first, then on IPFS, this ensures that pubsub can propogate to IPFS, and files will be available on IPFS
• Security
  • Investigate how peers advertise themselves on Android and iOS's frameworks
    • Try to tie any ID they have to the hash of a public key
  • Peers should publish their public keys to the mesh as soon as it's available so peers can look up their public key by their ID
  • Encrypt all packets between two peers using their public keys
    • Initial public key exchange will of course need to be unencrypted
  • Peers can discover each other by publishing their IDs on known channels
  • Use QR codes of hashes of public keys for sharing between users
  • Provide API for applications to generate new keys, and sign / encrypt data to be used for whatever purposes
  • If making an app to be used as an SDK from other apps, require user authorization in order to allow apps to access certain keys
  • Easy way for users to choose which keys to use for interacting with the mesh to allow them to switch aliases
• Privacy
  • If nodes are broadcasting their ID as they walk around, then they could potentially be tracked by passive devices
  • Searches don't have the ID of who started the search, so nodes receiving a search request don't know if they're getting the node initiating the request is the one that wants the content, or if it's on behalf of another node somewhere down the chain
  • For pubsub, since nodes propogate events throughout the network regardless of whether they are subscribed, one can't know which nodes are listening for something
  • If one has a lot of malicious nodes in the network, they could potentially locate the original node to do a publish of an event
  • It should be easy enough to add encryption and signing to payloads as applications require
• Long distance
  • Use long distance antennas that support wifi in order to bridge between communities
  • Ubiquiti airGrid M2HP