[messaging] RFC: async NaCl relay

[Max Skibinsky]

Mutlu, your questions imply "centralized" network (well-known nodes,
pre-registration of endpoints, gossip protocol between known nodes, etc).
It is a good architecture, and there are excellent existing projects, such
as Pond, implementing similar approach.

Our design constraints are different, so zax is build around different
architecture. When there is no gossip between nodes, no mutual discovery,
no pre-registration, no "central" relays - all this eliminates most of the
issues you mentioned and greatly simplifies the codebase. Relay becomes
very lightweight, can even be run even on Raspberry (one of the properties
we wanted). Address space is global between all relays: clients can leave
messages to anybody on any relay. Node discovery moves to the client layer.
Any device can prove "ownership" of HPK to a relay, and collect traffic (if
any) for itself from that relay: it's up to a device to make sure it
checked all relays it expects traffic at. Naturally, all that at the cost
of creating different tradeoffs: for example delivery becomes unreliable
with bigger task load for the client device.

As an example: when Alice does initial key exchange with Bob, she says
"here is my identity pk, and I'm aware of relay urls X,Y and Z to
bootstrap". Bob can respond with relays he knows. It is up to the app logic
to agree on specific subset (or a mutually-deterministic sequence) of
relays to establish comm session. Bob can even add his own relay on an RPi
in the closet and add it to the session: they all look the same to Alice.

Overall, apps using these relays should be agonistic about providers of the
relays: some of can be app vendors, some can be power users themselves. App
do not need to know all relays in the network, just large enough number to
have high degree of confidence that messages (duplicated across relays) do
reach their intended destination.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151219/1337713c/attachment.html>