-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can Announce notifications be created without a target
?
#20
Comments
I think the question comes down to: do we want a broadcasting feature or not? Currently, this deliberately not written in the spec because it adds complexity to the network architecture (you need a routing system) and the scope of the project doesn't really require it. ActivityPub does have this and perhaps we can align more with that standard if this turns out a crucial feature. Now zooming in on the 'add to her Event Log : "Here is my artefact, folks"'. Is this notification between the Maintainer and the Orchestrator, or who is supposed to receive these? So to answer the question: no, not right now, and I don't think we should add this unless we really need to reach the entire network. |
It is not per se for me a discussion if it is in scope of the project or not, but currently we exclude this can ever be in scope by writing "Thus, an activity MUST contain a target using the as:target predicate." (Section 5.4 my emphasis). Alice can |
True, but the other way around is also true: if you allow notifications without a target, how should the network in the current scope handle them?
Why is posting to your event log tied up with LDN? The event log is not an inbox AFAIK
Bob's orchestrator can only be triggered if Alice sends a notification to Bob, no? (with Bob as the target) |
The only actor in the current network that uses the The current workflow:
Now for Bob..Alice doesn't know Bob..he is just a silent admirer of her artefacts.
From the Viewpoint of Bob orchestrator the Alice Event Log is just an RDF resource it can read (in the form of a LDN Container, or Container + LDES , or what it will be). Bob orchestrator can use whatever SPARQL to filter our the graphs that are of interest to it. Of course with extra tooling,e.g. WebSub, this type of polling can be optimized in larger networks. |
Why doesn't the Dashboard send this notification directly?
it should append an event, not a notification. It's not an outbox, but I think you are hinting that we need one?
With "doesn't know", I guess you mean Alice will never receive notifications from Bob automagically.
Ah, but this is not wat the orchestrator does; it only APPENDs event logs. This is the collector's job, who only READs event logs. But the question is broader: how to "follow" other actors in the network aka how to subscribe to someone's events.
Agreed! |
We arrived at this reasoning together a few weeks ago in our calls. The reasoning at that time: The dashboard triggers the Orchestrator with the notification to execute the policies. E.g. doing the Schol. Comm/Erfgoed communication with the network. Each dashboard doesn't need to know this how this communication happens and how the Event Logs get created or other policies. For the dashboard it is fire and forget: orchestrator do your thing. It is more of a discussion what you call the dashboard and what the orchestrator. In my opinion, there will be many implementations of dashboards, that changes for every use case in the world. No organisation has the exactly same dashboard for entering metadata (even within one subject domain)..but orchestrators can be more generic. Orchestrators do their thing, given policies. If your dashboard want to have a in-app orchestrator to do all communication it includes
Well, until now I have demonstrated that it can all be done with an outbox and notifications. Glad to discuss this why this wouldn't work. Or, why an outbox is a neat thing.
No, what I meant that Alice never instructed her Orchestrator or her dashboard to forward |
Right, ok, my bad! So some init script (perhaps the orchestrator) creates the initial event log then.
👍
notifications or any other custom Web API, but agreed!
Depends on what the scope of an outbox is. In ActivityPub, it's just for sending and there are no requirements regarding integrity or persistence.
But except for that, having an outbox would be neat. But then it raises again the question: why aren't we simply adopting ActivityPub or defining a subset? (
Sorry, I mixed the two, I meant to say Bob will never receive notifications from Alice... because she didn't instruct her orchestrator to forward, so we're on the same page. But you're right, the orchestrator spec currently allows this, but I'm not sure whether we should keep this, it's not that simple to convey in a spec. Also, I would argue that letting your orchestrator watch an event log is a communication anti-pattern and I wonder whether we should actually prevent this, because it's not transparent. In an incentive driven network, Bob makes himself known to Alice first and then Alice forwards because she has every reason to do so. But I guess I'm back in the WebSub. Anyway, to conclude: notifications without target are mostly needed (at least in this scenario) if we want to leverage notifications for the event log. My gut says we shouldn't mix the two (for demos it's fine of course), but I can't really come up with good arguments other than separating concerns and the fact that notification are for communicating, not for keeping logs. |
Use case:
as:Create
)as:Update
)as:Update
)as:Announce
)- She doesn't have a specific target but only want to add to her Event Log : "Here is my artefact, folks"
The text was updated successfully, but these errors were encountered: