App message delivery workflow

Apps
#1

Following is a description of a workflow I am thinking about for sending messages from one user to another for a particular app. I would love to know what you think about this :slight_smile:

Consider 2 users Alice and Bob, who are users of an app someawesome.app

  • Alice’s app wants to securely send Bob’s app a message.
  • Alice and Bob have a URL for their preferred messaging server at a well known location in their gaia bucket for this app. The app allows a user to configure this URL in settings.
  • Alice and Bob’s app public keys are available at a well known location on their Gaia buckets for this app.

Workflow

  1. Alice’s app constructs a message with a message ID, encrypts the message with Bob’s public key, and stores it on Gaia.

  2. It then sends Bob’s message server
    – The message ID, encrypted with Bob’s app public key.
    – A bearer JWT token that contains info such as the sender’s blockstack name, the reciever’s blockstack name

  3. The Bob’s preferred message server receives the message , authenticates the message by verifying Bob’s public key which is at a well known location for this app.
    The message server then adds bob’s message to a database

  4. Bob’s app queries the server for a list of unread messages. The app authenticates bob’s request using a bearer JWT that is sent with the request.
    The message server returns all the encrypted message IDs that are intended for Bob.

  5. Bob’s app decrypts the message IDs, and retrieves each message from the appropriate users’s gaia bucket for this app.

Advantages
A couple of advantages I think this would have are:

  1. It doesn’t disclose any valuable information about the message to the server. All the server knows is that Bob has received a message from alice.
  2. The message ID is encrypted and then sent to the server. This would ensure that the server doesnt even know the location of the message on the user’s gaia bucket for this app.
  3. Allowing users to specify their own messaging server to store their incoming messages, would allow messging service providers offer competitive prices security features, provided they all use the same protocol.
#2

@jude any thoughts on this :slight_smile: ?

#3

Sounds reasonable to me, given the tech stack as it is right now (your preferred messaging server could easily be a Radiks server, for example). Only downside is that the app’s messaging capabilities are now subject to the message servers’ availability, which may or may not be under the user’s control. To address this on our end, we’re trying to make it so that Alice’s and Bob’s Gaia hubs themselves can simply act as the users’ preferred message servers (per the Gaia inbox proposal).

1 Like
#4

Thanks @jude! From my reading, it seemed like Radiks allows one to subscribe to updates to instances of a specific Model from all the app’s users. Eg. Get all updates about a ‘Tweet’ model. Not sure if it would send me updates that are only relevant to me.

I suppose it would need to send me updates of instances of a particular model which have group ID of one of my UserGroups … @hank can probably correct me :slight_smile:

#5

Right now the real-time notifications method will send you updates for all models, not just one model. This adds efficiency, because you only ever have one websocket open. However, it’s really easy to just add logic in your callback to only update your view if the model is related to the view you’re looking at.

The streamCallback function can do whatever you want - it doesn’t have to be the specific attribute in the example.

1 Like
#6

The flow you described is very similar to what OI Calendar does for sending invites to private events (currently hard-coded with matrix as messaging server but abstracted away)

The downside @jude mentioned should be covered by the API of blockstack.js. App developers just use “send message to Bob” and the message will arrive at Bob’s matrix client, gaia inbox or his preferred messaging service thanks to blockstack.js

1 Like