Peer messaging API

[caolan]

Each application instance (see #21) will have an inbox to receive messages from other peers. Messages should be confirmed as received. Messages should be guaranteed to arrive in order (or not at all). It should be possible to send messages to offline peers (they enter a queue and sending is retried until successful or a message delivery failure is returned to the sending app instances' inbox).

The API should provide the following operations to an app instance:

invite(peer_id)

Allow remote peer to send messages to this local app instance. This will also notify the remote peer of this app instance's existence and the app name+version from the manifest.

send(peer_id, app_instance_uuid, message)

Send a message from the local peer + app instance to a remote peer + app instance. The message is queued in a mutinyd outbox until it is confirmed delivered.

read()

Reads the top message from the inbox for the current app instance without removing it.

next()

Deletes the top message from the inbox for the current app instance. This is a separate operation to read() so applications can ensure the message is fully handled before it is dropped (if the app is closed before processing is complete, for example, the message should be retried next time the app is opened).

[caolan]

I'm going to redesign this around channels. Channels can be created with a protocol (free text field) and peers can be added to the channel (this is like an invite). The benefit of this is it can still do 1:1 communication, but can also better support group messages as other peers on the channel can potentially relay or replay messages. The protocol field allows us to separate the protocol from the app ID (and support multiple clients for the same protocol, or even multiple supported protocols in a single app).

[caolan]

For some inspiration I recommend checking out some of the XMPP specifications, e.g. XEP-0045 Multi-User Chat. In particular, I see app addressing working something like device/client addressing in XMPP - a peer + app/channel id combination to address messages to a particular app/channel and a bare peer id to address messages to the peer. This doesn't translate exactly to our use case but helps illustrate the problem we're trying to solve with multi-peer-multi-app messaging.

[caolan]

You'll notice that XMPP multi-user chat rooms are just addresses that reflect messages to all occupants - we could potentially push this onto the app layer for now and have the runtime only provide direct peer-to-peer messaging.

[caolan]

I'm going to hold off on protocols and stick with app-to-app messaging for now. The planned Announce API (#29) will help with advertising supported protocols - after that it's up to the app developer to handle expected message formats for now.,

This is pretty much implemented - the permissions system to be removed and replaced with peer-level filtering (e.g. allow from local network option, allow from friends list option, etc.) and filtering at the app level (e.g. perhaps rejecting messages from peers you've not explicitly shared data with in the app). And the message invite mechanism will be superseded by announcements (#29).