Message passing

[brolund]

We do want to keep F#Un a distributed application, preferably without any dependencies on a central server. This would make it more robust in case of "problems".

In order to be able to find friends, or see what happens, a message passing function should be implemented.

Example: I add someone a few steps away in the network. I put a message in my outbox for that person:

{to:person@storage.org, TTL:5, expires: 2012-12-24 message: encrypt(personspublickey, {username:"brolund@5apps.com", added:"person@storage.org"})}

My nearest friends poll my outbox, see that it is not for them, decreases TTL, puts it in their outbox. After a while the message (hopefully) reaches the intended recipient.

The messages could be anything, this is one example.

The TTL should limit flooding. The expires deletes old messages.

Any user could limit their outbox size to their liking.

The encryption is to avoid tapping or network mining (tin foil hats on).

[johlrogge]

I think what we talked about is that the message should be a reference to a key in the senders public store where the message is stored, encrypted or unencrypted.

[jancborchardt]

This is great! With Libre Docs we just used WebSockets because they were in Etherpad Lite – but it’s very interesting how to actually be able to pass messages completely without central server.

Only one thing about the proposal: I’d cut the expires part, because that might result in the message being lost. Could there instead be something which will automatically be broadcast by the recipient upon receiving the message, causing all people they are in contact with to delete the message – including the sender, and all people they are in contact with.

[brolund]

Removing expires is a possibility.

One problem with a delete message is that it could potentially need to travel farther than the original message did to reach everyone that needs to delete it, and we always face the risk of not reaching everyone. Hence, eventually we need to prune the outbox anyway, and expires is probably a good way. :-)

And messages will be lost, we just have to figure out how to live with that. ;-)

[johlrogge]

Yes, expires is just a way to prune the outbox. The will live in the outbox as long as there is space. When pruning messages will be removed in expirationorder.

End messages will be lost. Some will not have a possibility to reach the intended recipient but the possibilities will increase as the network grows.

[jancborchardt]

Hm, I would say making sure as much as possible that messages will not be lost is one of the most important things of the whole thing. If user data gets lost in any way then we screwed up.

Expires set to a reasonably long time, like a month or later after the send date is probably good though.

[johlrogge]

The data will not be lost, the message(event) will. If it is not confirmed by the recipient within the expiration time the sender can resend it. (confirmation can be as simple as adding the message id under a received key in the recipients store)

It is important to avoid overflowing peoples outboxes as well and keep the "event-data" from becoming humongous.

[jancborchardt]

As long as the sender info and a key to the message is there, the whole message doesn’t even have to be handed down. Or is that better to make sending and receiving faster?

[johlrogge]

@jancborchardt Yes, see my first comment in the thread

[jancborchardt]

@johlrogge ah, sorry. :)

[johlrogge]

@jancborchardt No reason :) It was a different way of saying +1 :)

[johlrogge]

Just braindumping a bit that has been said and thought offlline of this feature

• It has been implied but not stated that a sender can acknowledge receiving a message. The mechanincs of this is that the sender (who knows that the receiver exists) sends the message and polls the senders acknowledged receives. When the sender receives the message the sender writes an ack in a standard ack key.
• I remember from reading the 0mq-manual that they were using routing envelopes for routing. What that means is that a message can be wrapped in any number of routing envelopes. An envelope can contain another envelope or a message. When a receiver gets an envelope containging a message (reference to a message in a users store) it is what we have discussed before. When a reciever recieves an envelope containing an envelope for another address the sender acks receiving the envelope and puts the contained envelope in the outbox.
  • the above is useful if part of the whole or part of the path is known or becomes known at some point along the way by one of the routers. Then the message can be wrapped and readressed to skip a few hops.
  • it can also be used for probing. For instance, we may not want to have high TTL's, routers may refuse to forward messages with a larger TTLthan X in order to limit "message explosions". Then one can try sending the message from people we know follow us and get a fresh lower TTL from there.
  • It is a very simple, easy to implement that allows for many clever, advanced hard to implement optimizations. That is, the concept is easy to have early, potential is huge later.
  • limiting message explosions is important.
• traceroutes. When a routpoint finds a message it doesn't just decrease the TTL, it also adds itself to the list of hops taken. That way, when (if) the message finds the receiver the route taken can be added to the acc. Since it is possible (likely) that a message finds a receiver many routes can be subsequently added to the ack.
  • traceroutes can be used in combination with the envelope feature to skip focus a messages path to the receiver. Especially if an envelope can have several receivers broad to narrow paths can be encoded when the message is sent or along the way when passing along a message.
• limited expected message time. If a sender sends you one message he is likely to send you another. Within some timeframe you can check the senders outbox and hence establish a temporary fast route.
• look ahead. If a receiver has acked a message, routers can prune it from their outboxes or just discard it before putting it there.

While some of the above sounds complicated, the implementation of the needed datastructures are simple but the algorithms can be more or less complicated..

[johlrogge]

It also seems like message passing should be a separate project (that has also been talked about offline). Everyone will benefit from as different apps as possible using this feature reliability grows with the number of route points.