Feature request: Receiving offline messages

[nixmd]

I was thinking it could be so good if there was a way to send a message for the peer even whenever they are offline. Currently sending messages requests both peers to be online. So may not be a convient way to keep a computer 24hrs of the day running. But if there was a small application somewhere else which could receive and keep my messages untill I become online and read them all, that could be a good solution to this problem.

Here is my idea: A small application running on a always online device (e.g. a raspberry pi). This app must have a unique identifier address in the network so anyone can be connected to that just like any other peer. Now, the primary peer connects to this small app and requests that app to receive its messages whenever is offline. The primary peer must also inform the secondary peer about the address and availablity of such service as an alternative address.

Now, whenever the secondary peer sends a message to the primary peer, at first it tries to find the primary device. If it finds out that the primary device is offline or unreachable, then it can route the message to the alternative address which is the small service running on the always online device.

[toxtox]

I have found another example for a blockchain based instant messenger: "e-Chat" https://echat.io/ According to the white paper https://investors.echat.io/static/doc-pdf/en/e-Chat_Whitepaper.pdf offline messages and files are stored 30 days on IPFS-nodes (page 12 and 13). But the website does not look very serious and this messenger is closed source :-(

[SkyzohKey]

@toxtox You can read about Steemit blockchain, that's the kind of blockchain that allows what we need for Tox.

[Diadlo]

@SkyzohKey If tox will use blockchain it probably will finally dead for mobiles

[fcore117]

I think more important feature than offline messages still would be reducing data usage and in same time making network connectivity more robust(optimize) with when chat is in progress. This would be one of biggest features to boost world Tox adoption.

[SkyzohKey]

Blockchain doesn't means no mobile. Did you guys even looked at RaiBlocks/Nano white papers to understand how Block lattice works? È.é

@Diadlo http://dataconomy.com/2018/03/nano-coin-is-block-lattice-better-than-blockchain/

[toxtox]

@SkyzohKey @nixmd I looked around to find some solutions for the "real offline messaging" problem again but I could not find any usable messenger that is based on a distributed network yet

Maybe the "conversations"-messenger based on the XMPP network is close to the feature set I would like to have. https://f-droid.org/packages/eu.siacs.conversations/ But this solution has two main disadvantages:

1. XMPP is only decentral not distributed (If the server you have choosen fails then you are offline)
2. the public XMPP-servers offer very different features/extensions and configuration parameters (very different time-to-live for offline messages, some support file transfers and some not ...) So the features you can use, always depend on the features offered by the server and the client of your friend, too.

But nevertheless the "conversations"-messenger seems to be a very remarkable messenger:

• real offline messaging for text and files (if supported by choosen server)
• file size compression for pictures
• automatically accept files options
• out-of-the-box OMEMO-encryption for text and files/pictures
• sending audio and video messages

[bit4bit]

hello, here a proposal

i think tox protocol must not store any kind of data it's a protocol, the important thing it's who would store the data, the solution must be done between a client using tox and a provider for storing data.

it would be great if additional to name, a tox user can have a box-toxid and a mechanism in protocol that allow to store and retrieve messages, so a client could store/retrieve messages from this third party box-toxid, so we can choose who would store the data.

[zoff99]

@bit4bit if you attend this years ToxCon you may find a solution is already in the prototype stage ...

[asakura42]

I know it may be unrelated to Tox network structure but Bitmessage supports offline messages with high TTL about a week. Maybe not use Tox itself but think about additional relay software which will store offline messages until "friend" opens his Tox? Yes, it doesn't mean that "friend" will get offline message in that second when he logs in but in around of 15 minutes I think. And this is more than nothing.

[zoff99]

this solution is already on github:

https://github.com/zoff99/ToxProxy

[asakura42]

@zoff99 so what if I want to set up such relay for a whole Tox community? Is it possible? I think no. So it's like personal server for offline messages that is cool but not so altruistic, am I right?

[CrazyBoyFeng]

ToxProxy is actually synchronizing the messages of the same account on different devices. Well, this can also provide offline messages, as long as your ToxProxy is always online.

Why not consider Message cache servers? There are TCP relay servers in Tox's network structure. Message cache servers are just equivalent to storing the data of TCP relay servers on the hard disk, temporarily.

If you are worried about abuse, @Nutomic's idea of paying is great. Or you can limit the storage amount of the same IP.
TCP relay servers also have the problem of abuse, and you can also consider paying or restricting solutions.

Yes, this is centralized. But this is not the core function, the user can choose.

[zoff99]

@asakura42 not like it is now. what is your definition of "Tox community" ? a chat group? i guess we could try to make something work. can you help out?

[asakura42]

@zoff99

what is your definition of "Tox community" ?

A whole Tox community of course. For every who want to send offline messages. I mean if it's possibly to make your Tox Proxy code somehow available for using not in only personal use, it will be great. Like a global (maybe decentralised but btw) relay for offline messages.

[zoff99]

@asakura42 do you have programming knowledge in C ?

[asakura42]

@zoff99

Minimal. I can read code, but never learned it.

[zoff99]

if one wants to store messages for a longer period of time for more than 1 person, you need new crytpo (because of PFS). thats always a complex process and needs a lot of review.

[CrazyBoyFeng]

if one wants to store messages for a longer period of time for more than 1 person, you need new crytpo (because of PFS).

Why is new crytpo needed? Isn't the message encrypted by the receiver's public key?

All we need to do are:

1. When the sender finds that the receiver is not online, forwards the message to a message cache server.
2. The message cache server stores the message in a database and broadcasts the receiver’s ID in a DHT network. Set a timer to clean up expired offline messages.
3. The receiver queries the DHT network for its ID when is online, gets the message cache server node where the message is stored, and receive the message.
4. The message cache server deletes the message and cancels the broadcast.

[zoff99]

Isn't the message encrypted by the receiver's public key? --> no because of PFS its encrypted with a session key, that key changes when the session ends.

[CrazyBoyFeng]

Offline messaging cannot provide the instant security of online messaging. Static encryption is not very secure. Maybe we still need to use another session to implement it, but the session does not expire until the receiver replies.

[zoff99]

@CrazyBoyFeng can you write a specification for it?

[CrazyBoyFeng]

This will take some time and may not be fast.

I need to figure out the current time-based session first, and then try to insert a interaction-based session into the current messaging protocol.

[CrazyBoyFeng]

Is this Tox Reference still valid?

In this document, session is a concept that exists only when the client communicates with the TCP (relay) server. The message transfer between nodes does not use time-based session, but nonce-based encryption. If this nonce does not expire, so it can be used to encrypt and decrypt offline messages. It's just that there is an order, and if the receiver receives the message in a different order, it cannot be decrypted.

cookie response packet (161 bytes):

[uint8_t 25] [Random nonce (24 bytes)] [Encrypted message containing: [Cookie] [uint64_t echo id (that was sent in the request)] ]

Encrypted message is encrypted with the exact same symmetric key as the cookie request packet it responds to but with a different nonce.

[zoff99]

@CrazyBoyFeng this is the current spec: https://toktok.ltd/spec.html

[zoff99]

@nixmd someone wrote it:

https://github.com/zoff99/ToxAndroidRefImpl/blob/zoff99/dev003/OFFLINE_MESSAGES.md

and:

https://github.com/zoff99/ToxAndroidRefImpl/blob/zoff99/dev003/PUSH_NOTIFICATION.md