Request: Store And Forward

[joebush]

The ability of the client to 'store and forward' messages would be a great feature. If a contact is offline, common contacts (contacts the sender and recipient share) that are online at the time can receive the message until the original contact is online again. Since the message is encrypted with the first contacts public key, messages can't be read by others. This would require clients to confirm common contacts (which could be sent in hashed form so contact information isn't given away) and also causes more traffic, but has some clear advantages, especially for those who are often not online or have varying internet quality. Users would, of course, need to opt in to such a function.
 

This is undoubtedly a big order, and not a necessity, but it would be a good effort at mimicking server-side message caching.

[Tiger]

I agree to this thought, it's not good to be waiting for appearance the friend I want to write something. 'store and forward'  is a very useful feature

[marcel5432]

http://goldbug.sf.net messenger can do that, sending messages to offline friends in email, maybe it is worth to be hybrid in bleep with this messaging protocol ?

[joebush]

http://goldbug.sf.net messenger can do that, sending messages to offline friends in email, maybe it is worth to be hybrid in bleep with this messaging protocol ?

I entered a feature request for Bleep. Why in the world would it be relevant to mention that a different application has that feature?

Please spare us for product spams. This is about Bleep.

[Jaehee]

Thanks for trying out Bleep.

There are many features on our current roadmap.  Stay tuned for future releases as you may be happy with some of our future features.

[Guest arvid]

Offline messages is on the roadmap. We may store them in the DHT and ask friends to help keep them alive. The fundamental challenge with offline messages (or asynchronous communication) is the forward secrecy.

 

You will necessarily have to compromise something. One reasonable approach is to exchange temporary keys up-front (when being online at the same time) and then use those for offline messages later. The window of compromise will be much wider than for synchronous communication, but at least it won't be open forever.

 

When communicating with a contact right now, every message ratchets the encryption key, limiting any compromise to going back just a single packet.

[Clust]

Yes, this is a big feature. Especially trying to send messages to people in other timezones.

I haven't been able to test out the program yet, so not 100% how it works. But from the write ups online and my experience with BTSync... Maybe a solution to store & forward could be a message "hold" folder in association with BTSync or it's own Bleep-hold program.

 

If I have a VPS running BTSync and I try to send a message to a friend who is offline, Bleep then sends my message to my own holding folder on my VPS. The message is encrypted, and held until the person I'm sending the message to comes online.

 

Not fully sure how to explain it clearly, but just thinking of the ability to have a private Bleep node to relay and temporally hold messages, or even help to deliver the message. This could be installed on a home computer, VPS, or something like a raspberry pi.

 

Thinking far down the road when hopefully Bleep is developed for mobile. A private relay ability might help in delivering message.