Bleep: The First Step Toward Offline Messages

When our team started developing Bleep, we had to reshape the way online communications take place to make them more secure. As a result, we had to forgo the convenience of offline messaging – without a server to store the messages, we needed a little more time to iron out the details of sending and receiving messages to offline users with the security we can guarantee during real-time chats.

Today, we’re proud to bring basic Offline Messaging support to Bleep. Now, a user can send messages to an offline user, and the message will be sent once both users are online again.

Bleep doesn’t rely on servers to send communications, so these messages live on the device of the sender until a connection is made. This ensures that offline messaging remains secure and away from unauthorized viewers.

It’s important to understand that this update doesn’t fully support offline messaging. Two parties must be online at the same time for previous messages to transfer. In the future, we will have support for asynchronous offline messaging.

Once completed, two parties won’t need to be online at the same time for messages to be delivered. We will use our Distributed Hash Table (DHT) to store offline messages temporarily until they are received. Given the ephemeral nature of the data that is stored on the DHT, we are adding some mechanisms to keep this data alive until they are retrieved by the receiver.

We will explain this in detail when we release the feature in the future.

In addition, this new release includes stability improvements, and will enable users to see more of their friends online. We have also made improvements to reduce data usage, but Bleep is still not ideal for mobile environments on cellular data. We also listened to your feedback about our UI: Bleep is now easier to use than ever.

Offline messaging is just one of the many ways we’re working hard to bring new features to Bleep, as we work towards a beta release. We’re looking forward to your feedback on this and other updates, and thanks for supporting Bleep.

Farid Fadaie
Written by: Farid Fadaie

Farid is the head of product for BitTorrent Bleep.

 Related Posts:
  • Joey Famiglietti

    This sounds interesting…but at the risk of sounding like a bit of an @$$, what does Bleep bring to the table that Retroshare doesn’t? I mean, Retroshare’s strength and weakness are both that it generally involves an isolated ‘mesh’ of users to communicate (said mesh not being reliant on outside participants if undesired, but also not taking advantage of outside data, either). Bleep seems to be a bit different in that message content gets stored in the DHT, but genuine question: will DHT scale well enough to handle it? I remember reading that Sync has, er, synced, over 100 Petabytes of data to date. The reason this works so well is because the DHT is just matching peers, rather than actually transferring data. Messages are clearly smaller than binaries, and I don’t for a moment argue that, but if even a thousandth of a percent of the e-mails that are transferred on a daily basis turn into messages using Bleep, won’t that cause DHT to balloon in size? Moreover, how will applications other than Bleep that use the DHT handle the data they can’t use?

    I’m asking because I’m genuinely curious as to how Bleep and the DHT can ensure that one doesn’t limit the utility of the other.

    • http://bittorrent.com/ Farid Fadaie

      DHT is technically an ephemeral key/value storage. I am not sure what you mean by using to “transfer data”. It’s not going to do that. We are just using it to store undelivered message for a limited time (i.e. still ephemeral but with a longer lifespan).

      There are also mechanisms in our DHT implementation to avoid using peers’ resources more than a certain amount. We also treat mobile nodes differently to optimize for low data usage and battery impact.

      Our DHT has millions of nodes that can easily handle this (or at least this is what we think will happen).