Offline Messaging

[rodneyrod]

This is a needed feature that needs a placeholder issue tag, any potential designs should be put forward here for analysis and discussion.

[markwinter]

AFAIK, offline messaging will work by nodes closest to the receiver storing the messages. When a node comes online, it will then receive these messages and check if any are meant for them.

I may be wrong though.

[codyharrington]

what's the problem with just encrypting messages for the recipient locally using PGP?

You'd use your friend's public key to encrypt them, and just keep them stored somewhere until it's time to send them. Once they're sent, you can delete them. The only downside here is that you wouldn't be able to read what messages you'd sent your friend, because they'd be encrypted with their public key.

Another option is OTR. You could initiate an OTR session with your friend while they're offline. They then accept it when they come online, allowing them to view the messages. The OTR session is ended once they've read the messages. This OTR session would be in addition to the standard Tox session (however that works).

But then, that would kinda make the point of using the Tox protocol redundant.

[ananace]

The problem with offline messaging is not that it's unsafe to store the messages in your client. The problem comes when your client goes offline before your friend can come online and recieve the messages, for that case to work in a secure manner you have to somehow store the messages in the DHT without actually attaching any identifying data to the stored message - yet still be able to guarantee delivery to the proper recipient.

[im-grey]

This has probably already been shot down, but could they be put in the DHT? Or a separate DHT? Encrypted with the friends public key? I think that is what i2p-bote does, message are stored in the DHT for like 100 days or something and are deleted after that.

[ProMcTagonist]

someone keeps shilling tahoe-lafs in groupchat for this but I don't know enough about it to make up pros/cons

[ananace]

The problem with storing them in the DHT is that you would have to attach identifying marks to them, since the network would have to know whom to deliver the message to. And that's not a good thing when it comes to a security standpoint, anyone with a malicious DHT node could dump messages and suddenly you can't guarantee privacy anymore.

[LittleVulpix]

I believe there is a GSOC assigned to this. ( https://www.google-melange.com/gsoc/project/details/google/gsoc2015/drakefish/5707702298738688 )

[ProMcTagonist]

@LittleVulpix That project just uses supernodes if I'm not mistaken. And "supernodes" right now are hardcoded servers listed on the wiki. That's all we get for bootstrapping (the first time), TCP, and now offline messages... Normal clients should really be participating as much as possible or we're merely vaguely decentralized.

[LittleVulpix]

@ProMcTagonist Well there is no other way of doing this - reliably and securely - is there?

[codedust]

@ProMcTagonist There are more "supernodes" than those listed in the wiki. Clients get to know these other nodes when they connect to the DHT for the first time.

[jf99]

I don't know any details about this GSoC approach. But I would be dissappointed if offline messages were not stored in a decentralized fashion, which means not only on some specially chosen nodes. Potentially, every tox client should be able to contribute. Obviously, a mobile device is not a good choice as storage server for offline messages, as this might cause a lot of traffic. So tox clients should let the user choose whether he wants to allow buffering messages on his computer.

I know there are many people running a raspberry pi 24/7 or similar low-end computer. There should be a possibility for them to offer storage for offline messages. But don't expect them to have fixed ip addresses.

Also, is there any prevention from meta-data collection? I think a storage node should never know the sender of the message. This information can be kept encrypted inside the message, so that only the receiver can decrypt it. Consequently, the sender should not connect to the storage node directly but over onion-routing.

[aaannndddyyy]

I posted this on #870 already, dunno if here is more appropriate:

offline messages system should ideally have the following properties:

1) otr-like end-to-end encryption (the storer must not be able to read the content, pfs, deniability) 2) no linking between sender and receiver (the storer should not be able to learn who communicates with whom) - that's hard 3) be rather reliable 4) be fast 5) not include a central server 6) not depend on a single random node's uptime (redundance) 7) be freely accessible for all (no paying for it) 8) not pose a security risk to normal mode tox 9) no need to have many friends (nor friends find out whom i communicate with, cd. 2) 10) no need for a dedicated machine running 24/7 at your home in order to fetch your offline msgs

[reyaz006]

In my opinion, if we rely on every tox client to participate in keeping potential offline messages, ultimately there can be a point where this feature stops functioning - not enough reliable online nodes etc.

I suggest the following key points:

1. Sender and recipient both should acknowledge/agree that their offline messages are outside of responsibility of tox protocol. Thus, tox client should discourage sending important information with offline messages.
2. A recipient who wants to be able to receive offline messages should do an additional registration at some 3rd party server specifically for that.
3. A recipient should specifically grant sender with ability to send offline messages (should share his id on 3rd party server).
4. Each offline message should be properly encrypted. Only a real recipient should possess the data needed to decrypt each offline message. Sender's tox id should not be included - a recipient's client should guess it automatically. (For example, for each contact on his list a recipient should have a special data key that is only shared between the two and he should try all of his keys to decrypt each offline message - if by the time he receives the offline message the sender is not on his contact list, the decryption will fail.)

Now, as example, if we integrate simple pop3/smtp clients (offline message = email message), we get the following:

• Both sender and recipient can choose any capable email servers they trust. Probably a good idea to create a separate email account for this.
• If a recipient needs to change his email, he can do so any time, and would need to share it again with his trusted contacts.
• It may be possible to identify tox id of sender from the email address, but for this the attacker should also be on his list of trusted contacts.
• Will not work if smtp/pop3 are blocked.

Then, comparing to the mentioned chart: 1) it will work like PGP. 2) linking between sender and receiver - tox ids are not included anywhere in messages. 3) email seems reliable. 4) it's also fast. 5) any email server can keep the messages - too many to attack. 6) check. 7) many free email services are available. 8) check. 9) check. 10) check.

[aaannndddyyy]

I don't think e-mail is tge way to go.

E-mail is not new. Everypne knows it, so everyone could exchange e-mail addresses and write e-mails. That's not offline messages for tox, that's e-mail. But users want to send offline messages.  Do you think Whatsapp would be as successful as it is, if its messages only arrived if both parties are online? Skype initially did not have offline messages - now it has - and tgerefore never took off as a messenger, only its call feature made it successful.

Also, having to set up an e-mail account for tox is against tox's aim of ease for the user. Start and run. 

Furthermore, e-mail is not distributed. As mich as possible shouls be distributed in the tox ecosphere.

I don't see why a quasi unlimited number of tox nodes cannot reliably store small offline messages.

[TheNain38]

I'm with @aaannndddyyy's opinion here... I don't see why someone should use e-mails to send offline messages. And like said @aaannndddyyy e-mails aren't distributed and leave too much metadata.

[reyaz006]

I'm not saying that email is the way to go. Although it being not new is not a good argument, I think. I'm not an expert so it was only my assumption that under certain conditions the network may not have enough reliable nodes. The final amount of nodes is always limited. If you want to send the data to a certain amount of nodes and expect some of them to stay online for a certain period of time, it may not always be successful.

ICQ had offline messages many years before Skype was released. It, and every other service that allows real offline messages have to rely on centralized servers.

Email is just the most simple example of integration of such a service. It can work through a different protocol, but fundamentally it may very well be outside of tox. Perhaps it could even be a feature of a tox client, not a protocol.

tox's aim of ease for the user. Start and run.

We all understand the importance of convenience, yet it's already easy for us to accept some inconveniences, like having to copy-paste a long hex id to add anyone.

[aaannndddyyy]

I said it is not new, in order to show that despite people knowing e-mail and having it, they still want integrated offline messages.

It might well be done outside of toxcore but should be compatible between clients.

If you rely on a server, you may as well rely on a bunch of nodes. Servers are npt necessary.

[louy2]

The only absolutely reliable way of sending P2P offline messages I've seen so far is BitMessage. It basically broadcasts everything encrypted. That's the only way to deliver a message without knowing the recipient.

Or I think we can just find ways to keep the clients online. IMO it would be less a problem for mobile, at least mine is always on unless out of battery. How fast does Tox client drain battery if it just listens in the background of Android? For iOS there is a VoIP background mode available for listening to a socket as well. Then it's changed into the inter-device profile sharing problem.

Any other kind of relay isn't really free.

[LuccoJ]

@louy2 the Android client drains the battery really fast, and that's a toxcore issue, which you can read about at https://github.com/irungentoo/toxcore/issues/1501 and https://github.com/irungentoo/toxcore/issues/1251 A limited number of offline messages could also be stored directly in the DHT, at least potentially.

[TheNain38]

@louy2 There is also I2P-Bote which permits sending offline messages

[strixaluco]

I've just came across the info about OMEMO protocol, which is used in Conversations application. It's claimed that

The OMEMO encryption /oˈmiːmoʊ/ (OMEMO Multi-End Message and Object Encryption) gives you all the advantages you would expect from a modern-day encryption protocol like Future and Forward Secrecy and deniability while allowing you to keep the benefits of message synchronization and offline delivery.

Has anybody heard about this protocol? Can it be useful for Tox project?

Further reading: XEP-xxxx: OMEMO Encryption XEP-xxxx: OMEMO Encrypted Jingle File Transfer

[aaannndddyyy]

Same applies to axolotl. But toxcore is not using any of those protocols so far.

The crhpto part is only part of the solution. The other part being the actual storing and relaying. You would want it to be spam-resistant and that nobody can flood the nodes storing the messages. And also preventing the storage nodes to learn who communicates with whom. But this is doable, complying with the 10 criteria I have outlined above. (At least those are the criteria that matter to me).

The problem is therefore this: it was not coded yet and there is no consensus about whether to use such a protocol at all. So political and implementation, not so much concept and design

[Randl]

You would want it to be spam-resistant and that nobody can flood the nodes storing the messages.

What if each used defines the storage he dedicates to storing other people's offline messages, then he get a storage for his own offline messages, based on storage he provides and his availability, like 0.1 * S * A. So even if someone spams, he is forced to store much higher amount of messages. Availability is recalculated, say, once a day, and if the new storage is not enough, the oldest messages are deleted.

I just came up with this idea, so it's not 100% worked out and probably has its problems, but I think it might work in some form.

[GrayHatter]

@Randl that idea isn't bad, there's actually a few other project that implement something like that. But then you need police to make sure no one is cheating, pretending to accept messages, and instead just deleting them, just to get the storage space.

[Randl]

@GrayHatter We can request to send a hash of the message stored + some random salt from time to time.

[GrayHatter]

@Randl right, that'd prove they still have a copy of the message, but who makes that check? Then, how does the check that 'client' makes matter to anyone else?

[Randl]

@GrayHatter For example, the nodes storing the same message (there should be couple of them) should check each other. If the check failed, they send a request to delete the information to the nodes storing cheater's messages together with the message itself. Nodes perform their own check and if it's failed - delete the information of cheater.

[GrayHatter]

@Randl how do these nodes know others are storing messages on the same node?

[Randl]

@GrayHatter We can have a list of hashes of all the messages and nodes these messages are stored on.

Another problem is that if we want to delete stored messages then we need a mechanism to recognize specific sender's messages which allows to link between sender and receiver. Maybe storer should actually know the sender, and some different node who knows receiver but not sender would forward the message to receiver.

[ywecur]

https://reddit.com/r/projecttox/comments/2rvmlf/offline_messaging_in_tox/cnk1v6u?context=3

[Nutomic]

I have implemented offline messaging for my app Ensichat recently. I wrote my bachelor thesis about this, which describes in details how it works (link).

I'm not a C programmer, so it's not something I want to contribute myself. But feel free to ask if you have any questions.

[niXman]

404: Not Found

[Nutomic]

Sorry, fixed.

[ghost]

How about first up an outbound queue is implemented in each client. That would take care of .... sending messages whilst offline and would take care of some if not most of message deliveries as long as there is some overlap between the peers online time. When a "ping" or my proposed idea of status sending - "hello I'm up" is received from a contact this queue is checked for pending messages which are encrypted with the senders usual public/session key. The remaining entries having spent some time in the queue, say 1 day, would then be ripe for some dht or other mechanism/solution. I bet this would be a much smaller number and thus reducing any dht proxy's storage burdens.

So this way a couple of issues are dealth with and an offline feature is added as well. Much apreciated in the mobile space.

[ricary37]

without offline messages Tox will lose the battle to Riot/Matrix and Jabber+OMEMO and stay marginal messenger.

[zoff99]

have a look at:

https://github.com/zoff99/ToxBlinkenwall_raspi_lite_image/blob/toxproxy_01/README.md

for offline messaging support in Tox.