search

RubenVerborgh / solid-server-architecture

Proposed architecture for a Solid server
https://rubenverborgh.github.io/solid-server-architecture/solid-architecture-v1-3-0.pdf
13 stars 2 forks source link

Registering triggers for notifications #31

Closed kjetilk closed 4 years ago

kjetilk commented 5 years ago

And then, I'd like to see where and how we register triggers for notifications going out.

RubenVerborgh commented 5 years ago

Yes; would also be a diagram separate from LDP.

But do we actually have the necessary mechanisms figured out? So not architecturally, but spec-level?

kjetilk commented 5 years ago

Hmmm, good question. Intuitively, I guess, there is LDN, Websockets, WebSub, but perhaps it is not sufficiently clear. @csarven?

csarven commented 5 years ago

Can you expand? Is there some context that I should know of? What are the categories or boundaries?

Arbitrary examples:

(I presume that a config.activities.json can always allow one to pre-register triggers)

The closest mechanism that I can think of is along the lines of AP/AS2/LDN:

Sticking to HTTP for now, say we send a notification to an inbox with a particular shape about adding/removing/activating.. Server processes the inbox for these trigger "activities" in the notification.

I think we can draw some inspiration from ActivityPub and AS2, or better yet, reuse or extend if we need to. https://www.w3.org/TR/activitystreams-vocabulary/#activity-types gives plenty to work with or think about about expressing some sort of activities ("triggers"). See eg. subscribing with as:Follow: https://www.w3.org/TR/social-web-protocols/#subscribing-with-follow ), as well as https://www.w3.org/TR/activitypub/#client-to-server-interactions , https://www.w3.org/TR/activitypub/#server-to-server-interactions

Before going forward, can we clarify:

kjetilk commented 5 years ago

Can you expand?

No, you're much better at that than I am, @csarven :-)

It is just that Solid needs to notify other parties, and so, the question is how that should make it into the general architecture. Especially if it has important architectural consequences for the immediate issue we are discussing. So, I don't have much context, it is an open field we need to cover.

csarven commented 5 years ago

We need to agree on the kind of actor communication. Very generally, here is what's possible and what Solid addresses.

[x] server-client [ ] server-server [ ] client-client

So, for example, without the notion of server-server communication, a class of use cases can't be addressed. It is one of the reasons why https://github.com/solid/node-solid-server/issues/621 can't be tackled or need to be - putting time/resources aside.

If we want to "trigger" a server to do something (beyond common HTTP read/write and related stuff), we need to permit communication pairings in addition server-client.

Here, I don't care so much about what's a server or a client... so going only with what's been practiced in Solid, ie. "server-client" or server/pod-application.. I'm also not advocating for the kind of actor communication but that we first acknowledge Solid's current stance and where it could/should go.

RubenVerborgh commented 5 years ago

There's actually a third kind of actor, namely agents in the ecosystem.

I could have an agent monitoring my inbox and take actions. That agent might run on the client, server, or even somewhere else.

The only thing needed on the server would be a mechanism to ping the agent when something new arrives, but that can happen in a multitude of ways, some of which are even not notification-specific.

RubenVerborgh commented 4 years ago

Resolving this for now as the scope is LDP+ACL.