Multiple inboxes

[Dexagod]

A recurring question in the discussions around Mellon and Solid is the need for multiple inboxes.

Challenges:

• Security
  • Should different applications be able to read each others notifications?
    • e.g. should an application be able to read a notification that a new email has been received from a colleague if it has access to your inbox?
    • Maybe inbox read access should be restricted for applications (save for processing applications), and internal communication for applications should use application specific inboxes (e.g. the email applications specifies an /email/inbox folder as the inbox for internal communication using notifications, and notifications to the user are sent to the /inbox folder).
  • How do we do resource-based WAC on top of individual LDNs
    • Notifications are primarily aimed at the user or a specific (type of) running application. If they land in a shared readable inbox, there is a need to specify who is able to read a notification.
    • e.g. the email application posts a notification that a new email has been received. The notification is flagged to be only readable by the user. Other applications retrieving all emails from the inbox do not have permission to read this notification and cannot retrieve it.
    • Potential issue: applications with permissions to read the inbox can see notifications added to the inbox even though they cannot read them (this is an issue if for example you have only 2 applications using the pod and one of them is tracking your notifications).
• Flexibility
  • If internal communication for an application is done using an application specific inbox, this will mean other applications cannot use these notifications (unless this inbox can be found using shape trees, and permissions have been given).
• Scalability / performance
  • In case all applications write updates to the same inbox, filtering is a must (as there is no limit to notifications, and spam or IOT sensor notifications might clutter up the inbox).
    • In this case it should be clear that the inbox cannot be used to send notifications for internal communication, as they may be removed before being processed),

[RubenVerborgh]

A recurring question in the discussions around Mellon and Solid is the need for multiple inboxes.

For me, the key is that the sender does not know how the recipient wants to organize their things.
Hence, they should look for the most specific inbox they can find, as a general principle;
the recipient is free to assign one inbox to all, one inbox to each, or anything in between.

• Should different applications be able to read each others notifications?

Depends on the recipient.
If not desired, set up a routing rule to have app-specific inboxes.

• Maybe inbox read access should be restricted for applications (save for processing applications), and internal communication for applications should use application specific inboxes

I would expect this to be a common configuration indeed.

That said, if it's a configuration, there are several options.

How do we do resource-based WAC on top of individual LDNs

We do not.

The closest thing we have are:

• inboxes that are the target of a certain rule (so we can route specific LDNs to specific places)
• virtual inboxes/folders (where a folder is server-defined by a SPARQL query on another folder)

• Notifications are primarily aimed at the user or a specific (type of) running application.

Actually, that's only one kind of notifications; user-targeted notifications.
I expect those to be a minority, actually.

They're still important, just not primary target.

• e.g. the email application posts a notification that a new email has been received. The notification is flagged to be only readable by the user. Other applications retrieving all emails from the inbox do not have permission to read this notification and cannot retrieve it.

It makes sense to have a "GUI" inbox that is only user-readable.
All GUI notifications can arrive there.

I could have multiple such inboxes. One for specific apps (you've got mail), but perhaps also one for a general "status bar" app that just shows me all notifications (you've got mail and a Tinder match, also your mom called).

• Potential issue: applications with permissions to read the inbox can see notifications added to the inbox even though they cannot read them (this is an issue if for example you have only 2 applications using the pod and one of them is tracking your notifications).

Then you just adjust your rules and/or permissions.

Not up to us to decide; just to enable.

• Flexibility

• If internal communication for an application is done using an application specific inbox,

Hence rules to route them to as many as we want.

Scalability / performance

• In case all applications write updates to the same inbox, filtering is a must

Yeah, let's not 😄

The way I see it: every notification should only be read once. You read it, you process it.
If you're reading something that wasn't for you, either you or the message are in the wrong inbox; both are rule errors.