Inter-Planetary Mailing System

Can IPFS support an Inter-Planetary Mailing System?

Hello FIFs(Fellow IPFS Fans)! IPNS is a many-to-one thing where only the owner peer-id of an IPNS key can publish mutable CIDs under it, for others to access. Can’t we do the reverse too? A system, let’s call it IPMS, where anybody can publish content for their desired peer-id only.

A sketch: The average Joe can’t run an IPFS node that is always online; if he could, he would just listen to a pub-sub channel specific to him so that his friends could publish to that channel messages encrypted with his public key. So, let’s imagine a 3rd-party, always online service that acts as an agent for Joe (like Pinata, but the reverse of it). It subscribes to the pub-sub channel: #<Joe’s peer-id>.

Sending: As long as I know Joe’s peer-id, I should be able to simply do (in Go-IPFS): ipfs mail "Joe's-peer-id" < "path-to-file-containing-message" to send him my message. IPFS will query the network for Joe’s pub-key, encrypt the message with it, sign it with my private key and publish it (or its CID) to the pub-sub channel specific to Joe’s peer-id. Joe’s agent service(s) will receive it, verify the signature, and cache it for Joe until he comes online and queries.

Retrieval: To retrieve, Joe would simply do ipfs mail with the 3rd party service multiaddress preconfigured in his local config file. When his IPFS client connects to this 3rd-party node and authenticates using his signature, the node gives him all the cached posts under his peer-id and garbage collects after it. It’s up to Joe now what he would do with his downloaded mails that he can decrypt and filter. He can either save them in their original encrypted form by pinning to Pinata e.g., or burn them…his data his decision.

DHT instead of Pub-Sub: Perhaps, this whole thing can be implemented using DHT alone. Whichever node wants to cache Joe’s encrypted mails, can put a key-value pair with ipms/Joe's-peer-id as key and its own multiaddress as value. When Joe’s buddy connects to this node, it caches his encrypted mail to Joe iff his mail is signed.

Anti-Spam: The caching nodes may accept a post for caching only if it contains a HashCash-like PoW.

Anti-Spoof: Every mail is signed with the sender’s IPFS private key that is verifiable with the unique public key whose hash, in turn, is the peer-id (a.k.a IPMS mail id) of the sender - i.e. a self-signed/certified peer-id is self-consistent. So, to spoof, the bad actor needs to steal the private key - not a piece of cake.

Safety beyond encryption: Anybody may be allowed to cache Joe’s encrypted mails without any immediate harm. But it can defect in the long-term if someone hoards Joe’s mails with the hope to hack his private key one day. The network can ensure more security for Joe by mandating that the nodes wanting to cache/collect his mails must have their peer-id/multiaddress signed by Joe’s private key, when PUTting to the DHT. Other peers that host the DHT, would only entertain the PUT request if Joe’s sign can be verified on the value-file. Same goes for pub-sub routing.

Fun: a) Mars (a company) can have a few nodes to cache all the posts from Earth (outsiders) destined for the Martians (employees), and serve them over Mars-LAN whenever a Martian comes online and queries it! b) A group of friends rent server(s)/reverse-Pinata-like-services that cache their encrypted IPFS mails which they can retrieve whenever they come online. c) When a peer is online, it can receive its own IPFS mails directly. So P2P mail seamlessly meshes with P2P chat. d) Mobile clients can subscribe to SSE from their 3rd party caching agents for real-time notifications. e) Offline first; so helps intermittent connectivity on a Navy ship too. f) IoT devices with intermittent connectivity

@stebalien @adin thoughts?

You should take a look at orbit db. It allows this kind of stuff : example :

1 Like

FYI:

1 Like