Proposal: PGC and Offline Messaging via IPFS.

[hugbubby]

The offline messaging and persistent groupchat problem, is, fundamentally, one about decentralized/distributed data storage. Users need to be able to organize a hold wherein they can store messages for their friends to pick up later. Groupchats need have a stack where they can append past messages. In centralized services or protocols like Signal, Matrix, and Discord, this can be handled by the communications organizer. In distributed systems like Tox, however, the project must find a way to do this without trusting a third party to store them. This is a hard technical challenge in its own right, and has understandably been put on the backburner for the Tox project for a long time, despite it being by far its most wanted feature.

Yet, this challenge has already been met by other organizations. IPFS and Freenet are two examples of technologies that, right now, provide a byzantine-fault-tolerant network of computers to store such messages outlined above. The entire offline messaging functionality could be completed in a hundred lines of code using IPNS names. PGC would be nearly as simple. While this still leaves the problem of who to store these correspondences, that problem would be much more manageable if we were using an existing framework where seeding these holdsis a single API query, rather than attempting build our own patchwork of syncing and dedicated user servers.

For example, here is a high level overview of how to solve the user-user offline messaging problem in less than six IPFS api calls:

1. User creates an IPNS name (a pointer to distributed data store content) and shares it with their friend.
2. User attempts to message friend, and finds out friend is offline and cannot be reached.
3. User makes the ipfs add call and points his IPNS to the block of messages he just stored.
4. Friend wakes up, checks the IPNS address and sees their friend left them messages.
5. User, after friend tells him he got his messages points the name to blank space.

3-year-problem solved. Users can employ the same cryptographic techniques they use to hide their messages in transit to prevent eavesdropping. If they are worried about metadata, the same process can be done similarly with Freenet, which includes stronger anonymity, privacy and security guarantees.

Zoff99 created a proposal 10 days ago at this time of writing that included a list of many new features, and a link to a cloned repo that had already started on some of them. My understanding of his proposal is that he wanted to code these into toxcore purely from the ground up, rather than attempt to use an existing framework for doing so. I am not particularly against anything he suggested, but nearly everything he wrote save adding new information to messages (like timestamps) could be accomplished far more cleanly if we were willing to make IPFS a dependency.

I have brought up this solution before, and I have been shot down. I was told it was bloat or asking too much to require an IPFS installation in order to have access to these offline messaging features. I am astounded by this. Any solution this team comes up with to offline messaging will simply be reintroducing the features outlined above into the Toxcore codebase, probably making mistakes already navigated by the projects above. It is true that a full IPFS installation includes more features than we will likely need to use, and that we, theoretically, could spend a year to shave off a few klocs, but if a user is not willing to install a distributed data store client for fear of bloat, then they're not willing to install the basic requirement for this feature.

Reinventing the wheel has an opportunity cost. This project's team members are scarce compared to a similar FLOSS endeavour like IPFS or Signal that gets millions of dollars in funding and donations. We already have nearly two hundred open issues now. If the cost of saving potentially thousands of iphy hours that could be put towards fixing critical bugs is asking the user to optionally install another FLOSS tool, then that seems to me a forgone conclusion. I will try to be in the #toktok IRC for most of the rest of today and tomorrow, and my hope is that the rest of the project members and I can come to an agreement to build on Zoff's work with IPFS to accomplish this.

[tvladyslav]

As for me, this is the biggest problem of IPFS solution: ipfs-inactive/faq#9
Ideally, offline message must be destroyed from temporary storage as soon as it arrives to destination.
Does tox use quantum-safe cryptography?

[hugbubby]

Every single correspondence a tox user makes is being gobbled up as soon as it leaves its own computer, by probably more than 5 different spy agencies, and possible a few different ISPs.

Our threat model assumes possession of encrypted communications by advanced adversaries by default. We put our faith in the encryption, not the messenger. It should not matter if an IPFS node decides to hold onto the data because the data should be garbage to anyone that isn't the two people communicating.

[tvladyslav]

@hugbubby one of the rules of risk mitigation is to keep attack surface as small as possible. KeePass database also encrypted, but nobody makes it public on the internet.

[hugbubby]

@crypto-universe
The difference is that Tox communications are already "on the internet", in the hands of the entities that this community (in principle if not in practice) tries to guard them from. It's not extending the attack surface if the surface was already there.

[tvladyslav]

@hugbubby I was thinking about that. Probably, I'm afraid, that communication (encrypted, of course) will be available for everybody, not only the chosen ones. Right now Alice can traceroute to Bob's IP address and be aware who is able to collect her messages. If she has high paranoia level - she can make a VPN tunnel, use some techniques to conceal metainformation and so on.
If we go with IPFS, she can do... nothing. She can just prey that nobody:

1. find a bug in random generator;
2. find linear correlation between Sbox constants;
3. discover effective factorization algorithm;
4. create true quantum computer;
5. ???
   Then our messages may become a big data for somebody's bachelor degree diploma in 2030 :(

I just want to ask to make this IPFS feature optional if we implement it.

[hugbubby]

@crypto-universe Was the plan to make it optional from the beginning.

[iphydf]

This is not likely to be done by core devs. If you want to contribute this feature, PRs are welcome.