Inbox Proposal

[nikgraf]

Introduction

We want to allow accounts to send information to a specific space without being a member as well as to other accounts.

Use Cases

• Job applications
• Contact form submission
• Sign up for an event
• Direct messages from one account to another
• Direct messages from an account to a space

Proposal

We propose to solve this via an Inbox concept. Each account or space can have multiple Inboxes with a different permissions and visibility.

Creating an inbox for a space

Creating an inbox for a space mean first I need to create private/public encryption keypair. The private key is stored in the private space data so everyone who has access to the space can see it.

When creating the space I can choose if the inbox is publicly visible or not. This ensures that certain inboxes can only be known to others if I actively share their ID with someone e.g. a link.
In addition you can choose to only accept it from members of certain spaces or choose specific accounts (probably not in the first iteration)

In addition an inbox can define an expected schema for the message (this is optional).

Creating an inbox for an account

It's basically the same except the public encryption key of the inbox is always the account public encryption key.

Sending a message to an Inbox

When I have the Inbox ID, I can retrieve the encryption public key for it via an endpoint. Then I can encrypt the message and send it to the Inbox. The message must be signed. The message must inbox ID, space ID, author accountID, ciphertext & nonce. The signature must include all of them.

Listing spaces

There should be an endpoint that allows me to list all publicly visible inboxes for a specific space or account.

Retrieving an inbox

I can list all Inboxes for my account or a space I'm part of.

I can retrieve a list of messages for a specific inbox and with the private encryption key for the inbox I can decrypt each message. There should be a way to mark messages as seen so they don't show up anymore. Applications then can decide what to do with the message e.g. apply it as entities to the space.

Notfications

We think they are a different concept. Notifications can be triggered by a space changing or because a new inbox message was received.

[yanivtal]

Amazing. Question: Is there a reason that an inbox can only receive "messages" with defined schemas? Or could these Inboxes receive arbitrary knowledge / ops?

Marking the messages as seen is very interesting. This has some relation to the concept of personalized feeds which also need this ability. A standardized way of handling cursors for lists of things would be good. I'd be curious the similarities / differences between the ordering for messages in an inbox, and items in a personalized feed. The personalized feed would be created by a backend server whereas the messages here would be accepted by the sync server. But maybe the data model can be similar.

[nikgraf]

We considered the schema to be optional. I updated the description to make this explicit.

Agreed, pagination using cursors as well as ordering and even filtering are interesting topics we haven't touched on. The sync server doesn't have access to the content, but sorting and filtering could be done on

• seen
• createdAt
• createdBy

Are there any resources/drafts/implementations of personalized feeds we can explore to if there is an overlap?

Another question: Do we only support encrypted content for inboxes or also unencrypted? Unencrypted content could be validated by the sync server and filtering/ordering could be more powerful. I was thinking we could start with encrypted and if there is a need for unencrypted we can add them later. Step by step

[nikgraf]

Is implemented here: #151