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.

[tox-user]

If I understand correctly, you want a server to receive and store your offline messages. This might be a duplicate of: https://github.com/TokTok/c-toxcore/issues/695.

[nixmd]

@tox-user , No it's not the same thing. The feature @nurupo suggested in #695 is a IRC bouncer which in tox case will be GUI running on local machine but the toxcore the GUI communicates with is running on a remote server.

What I suggested above is like a voice mail on you phone. Whenever someone calls you, if they don't be able to reach you throught your phone, they will be connected to your voice mail. You will then be informed about a new message available on your voice mail.

[SkyzohKey]

What you ask for is centralization, which is against ALL the Tox principles. A better way to solve the offline issue is using a blockchain so that every peer on the network participate and so the integrity issue is solved by the same way...

[zoff99]

@nixmd good idea. now somebody just need to write it :-)

[nixmd]

@SkyzohKey this is not centralization and it's not going to be a public server. User must run this service on his own. Maybe each user can run such a service for himself and his family, a server per home. So it can keep record of ofline messages for more than one person privately;

@zoff99 =]

[nixmd]

@SkyzohKey I think blockchain would be the worst option to solve this problem. In blockchain, every person may receive a copy of the offline message (encrypted). Furthermore blockchain will dramatically increase traffic usage and thus this can make it not a good solution for users with expensive internet plans.

[SkyzohKey]

''Block chain are fat and slow'' is an outdated statement. Just take a look at the RaiBlocks/Nano blockchain and you'll understand how and why it's so powerful ;)

[tox-user]

The problem is: not everyone can run their own server. Only technical people with a stable internet connection can do it. We need a solution that will make offline messaging available to everyone.

[dvor]

IMO Tox should have distributed offline messages. We were discussing some ideas here https://github.com/anoadragon453/tox-offline-messaging-prop/pull/2

Also I was reading some articles about distributed file storage, this one looks promising. With some adaptation it should be good enough for offline messages.

[MrSorcus]

The problem is: not everyone can run their own server. Only technical people with a stable internet connection can do it. We need a solution that will make offline messaging available to everyone.

Tox nodes?

[toxtox]

@nixmd

I guess there is already a tool that might do what you are looking for: https://github.com/markwinter/MessageRelay But this tool is already some years old and I have not tried it yet.

[toxtox]

@nixmd But it would be much better if the offline messaging is possible for everyone in the network. Even real offline messaging should be possible with an decentralized instant messenger. This means even if sender and receiver is never online at the same time the message can be delivered via other clients that are acting as relay servers. Maybe this concept is already implemented in "Ensichat" https://f-droid.org/packages/com.nutomic.ensichat/ But I could not try this feature because I did not get a connection between two Ensichat clients at all. You could read the Conclusion of the bachelor thesis on page 30 for more informations: https://github.com/Nutomic/ensichat/blob/master/docs/bachelor-thesis.pdf

[toxtox]

@nixmd I looked around the last days if I can find a decentralized/distributed instant messenger that offers real offline messaging This is what I have found: https://f-droid.org/packages/cx.ring/ As long as I have understood the network design, "RING" -messenger uses OpenDHT as distributed hash table that is also used for storing/sending the text messages up to 4kilobyte in size. (source of image: https://tuleap.ring.cx/plugins/mediawiki/wiki/ring/index.php/Main_Page ) So the your text messages need not to go the direct way to your friends, the messages can also be transfered indirectly via other nodes/accounts if you and your friends are never online at the same time.

For limiting the size and bandwidth of the distributed hash table the size of each entry/message is limited to 4KB. This means the DHT cannot be used for real offline messaging with files. For file transfers a central server can be used :-( but if I disable this "TURN"-server the files can be transfered, too. (Maybe direct peer-to-peer file transfer like TOX?)

RING was already discussed here: https://github.com/qTox/qTox/issues/3435

[toxtox]

@nixmd After testing RING some days I found a very hard limitation concerning the real offlinie messaging.

1. The time-to-live of an offline message in the OpenDHT is only 600seconds (this makes real offline messaging quite useless :-( https://github.com/savoirfairelinux/opendht/search?utf8=%E2%9C%93&q=live&type=
2. There is no additional fake offline messaging like in Antox (sending message as soon as both sender and recipient are online [without time limitation]) :-(

@aberaud In my opinion and in the opinion of some other users a time-to-live of 3hours (10800seconds) to 6hours (21600seconds) would be enough for having a usable real offline messaging function. This would result in an 18 to 36times higher data storage in the OpenDHT but the current size of OpenDHT is quite small only "8MiB". Even 144MB or 288MB (8MBx36) for the OpenDHT seems not to much especially if you use a DHT-Proxy for mobile devices!?! https://tuleap.ring.cx/plugins/mediawiki/wiki/ring/index.php?title=Ring_distributed_network By the way the desire for having a longer "time-to-live" is not very new https://tuleap.ring.cx/plugins/tracker/?aid=765

[tox-user]

In my opinion and in the opinion of some other users a time-to-live of 3hours (10800seconds) to 6hours (21600seconds) would be enough for having a usable real offline messaging function

I don't think it's enough. Not everyone uses Tox every day and at the same time as others. Even if one person uses it every day and another only sometimes, it will be very rare for those two people to be online at the same time. They will often not be able to "meet" for days.

[zoff99]

well it would be a start. all-or-nothing opinions get us nowhere fast.

[dvor]

I agree with tox-user - messages should be stored for days, not hours. My guess is that messages should be stored for at least 2-4 weeks to make it usable.

To resolve issues with storage space whole storage system should be more flexible. I was thinking of following requirements:

• Friend A and friend B should have storage of limited size for offline messages.
• Both should have an ability to ask storage to remove delivered messages.
• Storing new messages should be possible only after removing old messages.

[toxtox]

Good discussion! The ideas for a usable "time-to-live" for real offline messages vary from some hours to some weeks. I give you an example just to think about a good compromise: Do you remember or still use the good old mobile phone text messages? Most cell phone providers store these text messages "only" 48hours. Have you ever felt unhappy with this limitation of 48hours? Maybe you did not even know this limitation ;-) For being honest, the users of "qTox" or a different PC-client might answer that they need a "time-to-live" for real offline messages of more then 24hours if they just want to check their messages every evening. => 48hours = right sized "time-to-live" for real offline messages? (But if this is really realizable with current distributed network protocols is another question, [6hours should be already realizable with OpenDHT])

[dvor]

Don't forget about mobile clients who might be unreachable for some time. Also not all users will check for new messages daily. Imaging someone going for vacation a week or two - they would expect to get all missed messages when they are back at their computer. Here I'm talking mainly about expectations of "average" non-technical user as I see them.

I haven't checked OpenDHT yet so I'm not sure why they have such short living storage. However in paper that I posted before describing PAST I don't see such strict time limitations. It should be doable to store messages for longer periods of time in similar DHT network.

[toxtox]

My personal expectation of an instant messenger is to get messages instantly or with a short delay. I would not expect it to work like an email system. I do not use "WhatsUp" or similar centralized instant messengers. How long do other commercial providers store the messages?, unlimited?

I haven't checked OpenDHT yet so I'm not sure why they have such short living storage.

As I know the RING messenger stores the OpenDHT in RAM-memory not on disk. https://tuleap.ring.cx/plugins/mediawiki/wiki/ring/index.php?title=Ring_distributed_network

[dvor]

Sure, all modern centralized messengers have unlimited storage for messages and files. To make tox competitive with those we should provide as much familiar and convenient user experience as possible.

Thanks, I'll take a look into Ring's wiki.

I'd consider an option to store offline messages on the disk. Desktop users should be able to provide some sane amount of storage (say 250 or 500 MB). Making offline storage configurable on client will add an option to create "storage" node as we do now with bootstrap nodes. Someone could rent a VPS and allocate 50 GB for offline messages - this will dramatically increase storage capacity of tox offline network.

edit: typos

[nurupo]

How do you combat people attacking or abusing the offline message storage? Say I write a bot that keeps storing messages non-stop on the DHT, potentially changing Tox Id / DHT keys / IPs, until no nodes on DHT can store any more messages, since I have filled them out, and my messages won't expire for weeks or even months to boot.

[toxtox]

Someone could rent a VPS and allocate 50 GB for offline messages

Technically this would work but this results in a more centralized network structure with a single point of failure and so on. The main idea behind TOX is that every client is (or can be) a server as well. Sure you could distinguish between online messages that are send directly with no server in between. And you could use a storage server as a fallback solution for older offline messages. But younger offline messages should be stored directly in the DHT for not being too dependent on this central server. But I worry that many TOX enthusiasts will not be very happy about storing their offline messages on a central server.

[nurupo]

@toxtox why are you writing Tox as "TOX"?

[Viral]

Someone could rent a VPS and allocate 50 GB for offline messages

the whole point of Tox is decentralization? I will not use any software that can be accessed by the same government that funds Al-Qaeda (fuck you America)

[dvor]

How do you combat people attacking or abusing the offline message storage?

That's a good question and I haven't thought much about it yet. One possible option would be to require some PoW for storing every message. It might appear that even with PoW it would be possible to attack network. Maybe in this case storage duration can be reduced to day/few days, but it would be nice to have an ability to prolongate storage period (say friend A sends offline message and "re-sends" it every day when he's online until friend B will get it).

I don't have an answer on how it should work, I'm just brainstorming. But I think that offline messages should be as much user friendly as possible, with as much storage duration as possible while still remaining distributed.

Technically this would work but this results in a more centralized network structure

Not really, offline message should be stored in the cluster of several random nodes. These will make storage more reliable and help to recover from cases when node goes down, is malicious, etc.

[dvor]

To make it more clear - I think that the only acceptable option for Tox's offline messages is a distributed storage.

Message should be saved to N nodes simultaneously. And these nodes could provide different amount of storage each - your message could be saved on one 50 GB node and 2 qTox clients with 250 MB of storage space.

[AmarOk1412]

But I think that offline messages should be as much user friendly as possible, with as much storage duration as possible while still remaining distributed.

Definitely :+1:

Sorry for the following comment, I'm a bit tired.

Hi, a RING dev here (but I don't speak for the project). This issue is indeed a major thing and clearly, it's what users want... I think it's as wanted as difficult to implement. On mobile clients it's a bit less complicated because users don't shut their devices down and devices are "always" (generally speaking) connected (but applications will be shut by Android/iOs...), so even if the node is not connected, there is other ways to inform the device a new message has arrived (push notifications for example). But still, offline messages is necessary.

A solution can be to change the ttl for messages on the DHT. But this solution is followed by a lot of issues. What's the perfect TTL for the current network? Performance? How about flooding the DHT? There is also issues about retrieving large amount of new messages when you rerun your node and get old messages from the DHT. Issues about synchronization, etc.

Another solution (for RING) can be to use proxy nodes (already implemented in OpenDHT since last year), with an improved version of the value cache introduced this year (still in OpenDHT) to locally store expired values somewhere for the user (like the distributed storage idea). This solution is like (more or less) the one used by the Briar project: https://code.briarproject.org/goapunk/briar-repeater/tree/master#briar-repeater

The second solution is my (perso) favorite for now, because if it's bad, it will just be bad for the proxy, not for the whole network.

[tox-user]

How do you combat people attacking or abusing the offline message storage? Say I write a bot that keeps storing messages non-stop on the DHT, potentially changing Tox Id / DHT keys / IPs, until no nodes on DHT can store any more messages, since I have filled them out, and my messages won't expire for weeks or even months to boot.

We need some way to detect and remove malicious nodes from the network.

Do you remember or still use the good old mobile phone text messages? Most cell phone providers store these text messages "only" 48hours. Have you ever felt unhappy with this limitation of 48hours? Maybe you did not even know this limitation ;-)

Most people who own a phone almost never turn it off. A lot of people use Tox on PC, so it's entirely possible for them to be offline for days.

Technically this would work but this results in a more centralized network structure with a single point of failure and so on. The main idea behind TOX is that every client is (or can be) a server as well.

@dvor meant that in addition to normal nodes that store only a few hundreds megabytes of messages, there could also be bigger servers hosted by volunteers that would host gigabytes of messages. It seems that those people would have the biggest influence over the network and failures of those servers would cost us the most.

[nurupo]

We need some way to detect and remove malicious nodes from the network.

That's what I have said.

[tox-user]

Here is how the Tor Project bans malicious relays:

One example of either misconfiguration or actual intended malicious behavior is exit nodes that do man in the middle attacks on outgoing https connections, do SSL stripping (i.e. replacing https:// links with http:// links), or do man in the middle attacks on other protocols like ssh. Whenever Directory Authority operators find such nodes, or somebody points them out to an operator, they are given the BadExit label. That will cause Tor clients to avoid them for exit connections. They are still useful and will get used for other positions in a circuit. The tor directory authority operators who vote on the 'BadExit' flag have the last say on what constitutes being a bad exit. In general we'll flag for the following...

• Tampering with exit traffic in any way. This is often accidental (for instance filtering by anti-virus).
• Only allowing plain-text traffic, for instance just allowing traffic through ports 80 and 143. This is because these relays are highly suspicious to be sniffing traffic. For the discussion on this see ​this thread.
• Numerous exits that collectively provide a high amount of bandwidth but are obviously related without setting the MyFamily entry.

More information: https://trac.torproject.org/projects/tor/wiki/doc/badRelays https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays https://www.cs.kau.se/philwint/spoiled_onions/

[nurupo]

@tox-user I bet Tor doesn't have its relays change identities every run, does it? There is no means of identifying a node on Tox DHT, the DHT keypair changes every run (and it might even change during a single run in the future). You could use IPs, but IPs are not really identifiers and can be changed, especially on mobile or when a node is malicious.

[tox-user]

I bet Tor doesn't have its relays change identities every run, does it?

It does not.

[nurupo]

It also sounds like there is a centralized database of bad relays, I think I heard a few people being opposed to centralization in here.

[toxtox]

Let me summarize the ideas in a more-level fallback strategy in a few words:

1. level instant: sender and recipient are online --> direct peer-to-peer transfer without DHT-storage
2. level short-term (fall-back): recipient is offline --> store message in DHT some hours/days and addionally store it in client for later "fake" offline messaging
3. level medium-term (fall-back): recipient stays offline longer than DHT-TTL --> store message on distributed servers some weeks
4. level infinite-term: sender and recipient are online again --> direct peer-to-peer transfer because of "fake" offline messaging like "Antox"

Even if the 2. and the 3. level fails because the DHT is full and the storage servers fail, the network remains usable because of independend 1. and 4. level.

[tox-user]

It also sounds like there is a centralized database of bad relays, I think I heard a few people being opposed to centralization in here.

I think they were opposed to storing their messages in a centralized way. Maybe nodes could automatically detect other malicious nodes whenever they communicate with them and report them to other nodes as untrusted. The public key of a node doesn't change, but it's easy to generate a new one. Trust of each node could be measured by the amount of data it stored. Ones that have been running for a long time and stored a lot of messages should be more trusted than recently created nodes.

[aberaud]

For robust persistent distributed storage IPFS and Maidsafe could be investigated.

[Nutomic]

If you are worried about abuse, you could require clients to spend cryptocurrency to send offline messages. Eg you have to spend one cent worth of Ethereum to the storage provider.

[toxtox]

If you are worried about abuse, you could require clients to spend cryptocurrency to send offline messages. Eg you have to spend one cent worth of Ethereum to the storage provider.

Good idea. I would like to spend one cent in crypto coins per offline message if this helps to

• protect the network
• cover the expenses of the storage providers
• push the development of a new offline messaging solution

But the disadvantage is that not everyone has crypto coins or wants to have crypto coins. This will limit the marked share of this instant messenger.

[nurupo]

If you are worried about abuse, you could require clients to spend cryptocurrency to send offline messages.

Cool, so you are saying that if I create many DHT nodes that will just pretend to store offline messages, I can "mine" Ethereum for free.

Eg you have to spend one cent worth of Ethereum

One cent is not enough, but some other value might work. You need to make it too expensive for any state government to attack, as well as make it expensive enough for people not to use it as a cheap file storage alternative e.g. for storing their encrypted disk backups on Tox DHT.

the storage provider.

Also, there is no single storage provider, it's a DHT, the message is replicated on many nodes and those nodes keep replicating it among other nodes too, keeping the message alive, as nodes keep going offline and online and the message could be lost if not replicated. If only the first node gets the one cent, it means that other nodes would store the message for free, so someone will inevitably patch their node to store only paid messages, so there would be no message replication and offline messages will become very unreliable.

[aberaud]

People can send hundreds of messages per day, paying for each message even one cent is not an option, also the global volume of messages is just too high for each message or message trace to be recorded in a blockchain IMO.

[toxtox]

How do you combat people attacking or abusing the offline message storage?

Maybe the risk and the consequences of an attack is a little bit overestimated as long as the online peer-to-peer messaging including "fake" offline messaging is not affected. And additionally the risk could be lowered by

• limiting the number of messages per time and per IP-address (maybe max. 1 message per second)
• right-sized limit of the max. allowed message or file size

For example RING messenger has a max. message size of 64KB. https://blog.savoirfairelinux.com/en-ca/2015/ring-opendht-a-distributed-hash-table/ This means you could put the text of a newspaper-page into one message. So 64KB is a "little bit" oversized for simple text messages. You might think that the size is so big because you can send small files and VGA-size pictures or thumbnails via OpenDHT but unfortunately this is not supported yet.

A higher risk could be the unexpected success of such a messenger due to limited scalability. Imagine if suddenly 1million, 10 million or even more than 100million users want to use it. ;-) (for comparison WhatsApp or WeChat have round about 1000million users each)

[zoff99]

100million (Tox-)users :-)

[nurupo]

Maybe the risk and the consequences of an attack is a little bit overestimated as long as the online peer-to-peer messaging including "fake" offline messaging is not affected.

The consequences of an attack is that the offline messages you have sent will not be delivered with high probability and that someone might be using the entire Tox DHT as a free file storage service for themselves. What's good in having a feature -- real offline messaging -- that you can't rely on working? Doesn't a feature that doesn't work mean that it's bugged? Why would you write a bugged feature? Are you suggesting to just ignore the issue of it being attacked and simply rely on peers being benign and well-behaved? It's a free file storage, even though you can't simply HTTP GET it, pretty sure there would still be people who would jump on it, especially if you allow storing things for long periods of time. Not to mention your everyday script kiddies or hackers trying to pwn everything they can for fun and fame, or potentially even a government state trying to disrupt the operation of a messenger (though they are a lot more likely to disrupt the more essential functionality like the peer discovery rather than the optional offline message storage functionality).

limiting the number of messages per time and per IP-address (maybe max. 1 message per second)

It's not possible to impose such restrictions without some kind of centralization. Peers have no ability to know the message rate of any given peer, they also can't trust any peer to report the message rate accurately as there is nothing preventing them from lying.

right-sized limit of the max. allowed message or file size

There is no issue with imposing a message size restriction, however.

A higher risk could be the unexpected success of such a messenger due to limited scalability. Imagine if suddenly 1million, 10 million or even more than 100million users want to use it. ;-)

Scalability should be addressed properly indeed. Both attacks and scalability should be considerate, you can't really ignore one or the other.

[SkyzohKey]

All your concerns are solved with one concept. Blockchain

[dvor]

@SkyzohKey can you give a more verbose description of the blockchain idea? Maybe you have some examples of offline messages or something similar suitable for Tox implemented using blockchain? Because now it is completely unclear how it should work. I don't want to be rude, but for me it sounds like one of those:

All your converns are solved with one concept. DHT

All your converns are solved with one concept. TCP/IP

All your converns are solved with one concept. Offline messages

[toxtox]

A blockchain could be an option because there are already some blockchain-based (or partly blockchain-based) messengers out there:

• some crypto coin wallets allow sending text messages (comments) for the price of the transaction fee https://github.com/philosopherstonecoin/philosopherstone/releases
• "ADAMANT" is a blockchain based messenger (only for text messages!?!) https://adamant.im/
• "RING"-messenger uses Ethereum-blockchain as nameserver https://tuleap.ring.cx/plugins/mediawiki/wiki/ring/index.php/Main_Page

But I could not find a messenger that could store files/pictures in a blockchain yet. I guess storing big files in the blockchain would be very critical because of the required storage. Therefore old messages have to be deleted automatically from the blockchain after a time limitation (TTL).

[Nutomic]

Storing actual data in the blockchain is a bad idea, because it is very expensive. It would be better to store the data on ipfs, and just store the ipfs hash on the blockchain.

[tox-user]

Doesn't using blockchain mean that certain people (miners) have to spend a huge amount of computing power and in exchange they get currency, which might not actually be worth anything? Why would they do that?

[toxtox]

@tox-user Mining is not needed for using a blockchain as storage. All the "100%-proof-of-stake" (POS only [without POW]) crypto coins run without mining. For example the "Philosopherstones": https://github.com/philosopherstonecoin/philosopherstone/releases