Receiving messages when offline/online

[Adabi-zz]

hi I try my best to introduce TOX to my friends. So they know early enough that one day it will be time to say goodbye to skype. :) We noticed a very annoying problem. After sending a message to an offline account, the message won't arrive to the account when the offline one is online again and there is no notice to the sending account wether the message arrived or not. We are all using the venom client on Win7. I am sorry but I have no idea, where else than here to post this problem. If this is wrong I would be glad if someone could direct me to the right place. Thank you very much.

[irungentoo]

Tox doesn't support offline messages right now.

We might implement them in the future though.

[aviau]

This could be partly solved on the client side too. Venom could tell you your friend is offline and keep the message in a queue unil your friend comes back online.

[ghost]

I don't think so. What if your friend comes back online and you're offline? I think the only reliable solution is to add a database functionality to the Tox protocol. This way stand alone servers can be realized which store the encrypted messages (maybe files too), a bit like bootstrap nodes. Both clients should agree about one server they use if one of them goes offline. So the Tox API has to be extended with functions like askForFfflineMessages() or setOfflineServer(). This should be an optional feature in any case, if you want to implement an top-secure client you can turn it off, otherwise you turn it on. But this decision should be taken by the user.

[Adabi-zz]

Thanks for the replies.

This might from the view of an average user difficult to accept. Because of different times online. Especially that an older message will not delivered when both online at the same time. So you can't set off a quick routine message like "Buy some milk" to someone in expection the one will read it when he's back online.

[tarekziade]

I am also interested in offline messages, we are working on a proof of concept at https://github.com/tarekziade/toxmail/issues/1

with the recent addition of tox_keys(), a simple way to do this is to store the encrypted message on a 3rd party node. We're thinking about extending the DNS discovery service so it also used to store encrypted messages on behalf of a user - as long as they register as a friend of that node.

@irungentoo would it make sense to make that part of the Tox protocol ? e.g. a specific message that's composed of:

• the target tox id or user@domain
• a timestamp that defines how long the message is kept
• the encrypted message

the server would then accept or reject the request by sending back a code (0/1)

On the other side we'd need a specific request/response protocol ala POP3 to retrieve the messages.

That's what I am currently implementing in toxmail but if you're interested in having specific APIs to deal with this, that'd be imho an awesome addition.

[tarekziade]

I don't really make a difference between a server and a node as the server is also in my case a Tox node. I guess the biggest difference is that a given user has to know where to get back their messages when he comes back online - if stored messages are distributed across several nodes, we'd need a way to retrieve an index of those nodes. I guess that's what @ollieh has been working on ?

Looking forward to hear on this!

[Jookia]

If friend requests only work when both clients are online, this also seems to be a trend that needs work.

[raichu]

Retroshare distributes the encrypted message to friends in the network, the first one who sees the target then delivers the message. So you don't even need to be online at the same time as your friend.

[dubslow]

What if your target friend has no friends in common with you? Doesn't that require mutual friends to be online at the same time as your target?

[raichu]

Yes, at some point.

To send the message, only the target address needs to be known, right? The sender information is (or can be) embedded inside the encrypted message or header (I don't know toxcore's details either, sorry).

I'm not sure about the implementation details of Retroshare's serverless email (p3msgservice, Retroshare is open-source though, anyone familiar with the code around, maybe?). It is well possible that non-friends are also OK too, but again, I'm not sure.

I vaguely remember sending offline email to another person with whom I share no common friends with Retroshare though.

But distributed stuff aside, I think this can be implemented straightforwardly: If the recipient is offline, store the message locally and deliver when he/she comes online (this seems be to be mentioned already).

[Scratch-net]

There is already an implementation of offline messages called BitMessage. I think it can be merged into tox as an offline messages engine. It does not need any standalone servers and the sender to be online

[suhr]

There is already an implementation of offline messages called BitMessage

PoW uses too much CPU.

[Scratch-net]

Otherwise it will be easy to flood all offline message engines and difficult to protect users/servers from abuse

[bitcard]

DHT store extension can support the offline message, it support put/get data limit size 1k, please visit http://libtorrent.org/dht_store.html

[aaannndddyyy]

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, cf. 2) 10) no need for a dedicated machine running 24/7 at your home in order to fetch your offline msgs

[EmPeWe]

Maybe it would make sense to take a look on some other secure message tools, namly bleep and textsecure, which are both capable of PFS offline messages

Bleep from BitTorrent Inc. also uses DHT and uses PFS async msgs a short time ago: http://engineering.bittorrent.com/2015/08/06/forward-secrecy-for-offline-messages-in-bleep/

TextSecure from WhisperSystems can also send PFS offline msgs with ProtocolV2 based on Axolotl: https://whispersystems.org/blog/asynchronous-security/ https://whispersystems.org/blog/advanced-ratcheting/ https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2 https://github.com/trevp/axolotl/wiki

[DanielFallon]

FWIW skype is fully p2p doesn't have offline messages. (and yet all of the messages are sent to microsoft anyway... http://www.zdnet.com/article/is-microsoft-reading-your-skype-instant-messages/ )

[eyedeekay]

OK so maybe this is a little out of line, I don't have much experience in these matters and I've only observed the discussion thusfar, and I only fairly recently even got around to reading and understanding the axolotl protocol, but would it be possible to exchange the prekeys in advance between peers when they add eachother, and then maybe refresh some or all of them when they meet again online?

[aaannndddyyy]

@TheElf Skype fully p2p? Long time ago. And yes, they do have offline messages.

@cmotc Yes, that would be possible. In fact, I think even desirable. Thus you can only receive offline messages from friends you have contacted already.

[aaannndddyyy]

I think in general, there's some decisions to be made about how damaging a machine being compromised is. if you pre-key 100 keys like textsecure, you will burn all of those keys if a machine is compromised. any messages that are sent to you between the time that your machine was compromised and the time you burned that identity will be readable. So we have to figure out what we're trying to protect against exactly, and how important that protection is.

@TheElf You are getting this wrong, nothing will be readable, even if those machines were compromised.

Only if your machine was also comprosmised or the machine of your friend.

[aaannndddyyy]

@TheElf Oh, it seems I read your comment wrong. Yes, if your machine is compromised your messages that were sent with the latest keys can be read by the one with access to your private keys.

This only affects offline messages. But that's still an improvement over signing and encrypting to pubkey, as there ALL messages would be readable, and not just the last 100. So you have a certain protection of the past.

[redfacedquark]

I've started developing for tox and I'm interested in something like this feature. I'm on a train of thought where a client could nominate an ID of a tox client that was always online that would receive and save messages but not be able to read them. When the user comes online the client would fetch its messages and decrypt and display them locally.

I've not really dug into the protocol enough to know if this is fundamentally a bad idea or even fundamentally possible. I would much rather go with toxcore development and features that will be developed in a wide range of clients rather than only via the web or via a special tox client. For some background, my aim is to explore using the tox protocol to:

1. build more traditional web apps using tox for fetaures like auth, profiles, DM, offline messages, group chat, and forums.
2. build web apps that make use of and integrate disruptive technologies (e.g. OpenBazaar, DAOs).
3. replacing message queues with the tox network and and replacing api services using tox bots in group chats.
4. allow us to not care about VPNs, DC limits or strict architecture.
5. improve the health of the tox network by encouraging always on nodes and a dependence on the security of the protocol.

I'm aware the 1 will present some counterparty risk with the website operator but I don't expect users to use their most prized tox identities, nor for site operators to hold any accessible user data. If anyone is working on 3 then I'd love to hear your thoughts. Obviously groupchats would work but maybe there's something else in the project than I've not seen so far along these lines.

Without wanting to go completely O/T another thing I need to get round to thinking about is scaling such bots and I realize I know nothing about tox routing. I'm thinking of some load-balancing presence using similar forwarding to the idea I described above. If anyone wants to weigh in on whether I should do any or all of this rather than if I could, that would be welcome too.

[aaannndddyyy]

@redfacedquark wrt offline messages I had the idea of forming circles of peers. you then would not nominate just one and depnd on it, but have redundancy. At the same time it would help agains spamming the network. But unfortunatelly I cannot code this stuff. :( I could explain my idea in more detail, if you want we might tox about it in order to brainstorm a bit so I don't spam this thread too much.

[redfacedquark]

@aaannndddyyy I can't see a DM feature here on GH so here you go: CB043DCB5CFC1ED4084146CDFD9A1C3B54D4A62F73F45CE64A03232A61EB2C55F490FD18EB3C

[DanielFallon]

@aaannndddyyy many parts of skype are still p2p-esque (yes often they are routed through another node, if you don't use a mobile device, then offline messages do not occur. see this support documentation: https://support.skype.com/en/faq/FA10646/will-my-instant-message-be-delivered-if-the-recipient-is-not-signed-in-to-skype

and yea that was my point. I still think a system like that is an improvement, we just have to decide how important any single message being compromised is. it's a balance between convenience and security as always.

[aaannndddyyy]

Yes, that is something you cannot avoid at all with offline messages. The question is only, whether you mkae them ALL vulberable, or only last 100 or last 50 or 1. I think if you can only send one offline message to a peer, it would be quite a nuissance and not very useful. Mabye 100 are a bit high. also varies between users. Some may have many friends, low uptimes, much conversation and favor conveninece over protecting against the case when their own device gets compromised and some may need less and are more paranoid. I could well live with 50. Maybe have it configurable between a hardmax and 0, 0 meaning not accepting any offline messages. But I don't think it is a big issue, after all, anyone who has (encrypted) chat history logging enabled does obviously not care about this anyway, or does not know that chat history is 'dangerous' in this sense leaving all messages readable since last deletion.

[zen2]

@aaannndddyyy: why not generate a pre-key by contact (renewed when we exchange message) and kept it to encrypt offline message or simply crypt the offline message with private key and contact public key ?

Offline message can be really important for not ephemeral group chat: if there is 5 people chatting in a group regularly, you want to see old chat from others people in group when you log.

[aaannndddyyy]

@zen2 :

crypt with the private key

You'd never do that. You could encrypt it using the contact's public key, but that is obviously less secure. In groupchats you could simply sync history with the other group members.

[ghost]

What do you think about the following way to implement offline messages :

-node A wants to send a offline message to node B

• Every node in the DHT should have an additional attribute which describes its availability in percent or seconds, let's call it "availability"
• Every peer is looking for at least 3 (the exact number has to be figured out) or more nodes with a very high availability
• this way mobile clients are treated as unreliable and don't store offline messages as well as other clients which are often offline
• A and B do agree about the 3 clients with a high availability which was managed when both are online at the same time, so both know where the offline messages are going to be stored.
• A copies its message 3 times so this way every of the 3 nodes receive a copy of the message
• From that point A could be offline, too.
• When B comes back online, it asks each of the 3 clients if there are offline messages for B and eventually receives them.
• B notifies the 2 other clients that the offline message could be deleted.

Key parts:

• One offline message is stored in more than one client to minimize the message loss when a client suddenly disappears
• The Tox DHT is able to decide which Nodes are more reliable than others

Points to figure out:

• Protection against Spam, maybe each offline message contains the address of all clients on which it is stored so the clients can verify spam whith each other
• If a client knows that it will go offline soon it could redirect the message to a other client, than B eventually has to search the whole DHT for its offline message(is this going to work or too much oberhead ?)
• There should be a time at which unreceived messages should be deleted, for example 30 days.
• Every Node/client can have a different size of storage space and A should be able to ask the node if there is enough space for the 500 MB Video to store, for example.

What will it look like ? I think this way there will be a few nodes which become "supernodes" managing all the offline messages. This could be seen as centralization. However, everyone can easily make his own client store the messages so it is up to every single user if he wants simple offline messaging or a trusted server. Anyway the reliability should be close to 100% dependimg on the number of storage servers involved.

[aaannndddyyy]

Not entirely bad, but:

An attacker would advertize highest availability for his nodes. Availability should be remotely monitored.

If A and B have not communicated for a lobg time, their common three nodes might longe be gone, which then means that A cannot send an offline message to B andymore.

The storer now knows exactly who sends offline messages to whom (privacy loss)

If one storing node can deliberatelly make the other two delete the messages, it can DoS

Maybe a redundancy of 3 is too low. What about 8? (reliability)

No way of preventing a node from spamming the network

Crymes notifications@github.com hat geschrieben:

What do you think about the following way to implement offline messages :

-node A wants to send a offline message to node B

Every node in the DHT should have an additional attribute which describes its availability in percent or seconds, let's call it "availability"

Every peer is looking for at least 3 (the exact number has to be figured out) or more nodes with a very high availability

this way mobile clients are treated as unreliable and don't store offline messages as well as other clients which are often offline

A and B do agree about the 3 clients with a high availability which was managed when both are online at the same time, so both know where the offline messages are going to be stored.

A copies its message 3 times so this way every of the 3 nodes receive a copy of the message

From that point A could be offline, too.

When B comes back online, it asks each of the 3 clients if there are offline messages for B and eventually receives them.

B notifies the 2 other clients that the offline message could be deleted.

Key parts:

One offline message is stored in more than one client to minimize the message loss when a client suddenly disappears

The Tox DHT is able to decide which Nodes are more reliable than others

Points to figure out:

Protection against Spam, maybe each offline message contains the address of all clients on which it is stored so the clients can verify spam whith each other If a client knows that it will go offline soon it could redirect the message to a other client, than B eventually has to search the whole DHT for its offline message(is this going to work or too much oberhead ?)

There should be a time at which unreceived messages should be deleted, for example 30 days.

Every Node/client can have a different size of storage space and A should be able to ask the node if there is enough space for the 500 MB Video to store, for example.

What will it look like ? I think this way there will be a few nodes which become "supernodes" managing all the offline messages. This could be seen as centralization. However, everyone can easily make his own client store the messages so it is up to every single user if he wants simple offline messaging or a trusted server. Anyway the reliability should be close to 100% dependimg on the number of storage servers involved.

— Reply to this email directly or view it on GitHub.

[GrayHatter]

dub of #186