Can Announce notifications be created without a `target`?

[phochste]

Use case:

• Alice creates a new artefact on het pod (triggers an as:Create)
• Alice updates the artefact with an attached PDF file (triggers an as:Update)
• Alice changed metadata (triggers an as:Update)
• Alice want to let the world know the artefact is ready (triggers an as:Announce)
  • She doesn't have a specific target but only want to add to her Event Log : "Here is my artefact, folks"

[mielvds]

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? If the receiver is any other network actor, it is a good example of why notifications/activities and events need to be distinct. You can write whatever in your event log, including Artefact X was created even if there never was any notification (admitted, with announce it doesn't make sense to do this). Put differently: you leave it up to the collector to discover this information when it's relevant.

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.

[phochste]

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 as:Announce things even when no broadcasting features are implemented. She can just post to her Event Log: "Here is my artefact, folks". Bob can discover this event when he has an Orchestrator that is triggered by changes to Alice's Event Log.

[mielvds]

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).

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?

Alice can as:Announce things even when no broadcasting features are implemented. She can just post to her Event Log: "Here is my artefact, folks".

Why is posting to your event log tied up with LDN? The event log is not an inbox AFAIK You can reuse the Activity Types for the event log if that fits. In the context of the event log, properties wrt delivery (as:target, as:origin, as:actor ) are not essential anymore.

Bob can discover this event when he has an Orchestrator that is triggered by changes to Alice's Event Log.

Bob's orchestrator can only be triggered if Alice sends a notification to Bob, no? (with Bob as the target)

[phochste]

The only actor in the current network that uses the as:target is the Orchestrator of Alice: to forward a notification from Alice's dashboard to the correct Service Hub.

The current workflow:

1. Alice drafts a notification in her dashboard with target : Service Hub XYZ
2. Alice Dashboard sends this notification to her Alice orchestrator
3. Alice Orchestrator forwards this notification to the target of her notification (Service Hub XYZ)
4. Alice Orchestrator appends the notification to Alice Event Log

Now for Bob..Alice doesn't know Bob..he is just a silent admirer of her artefacts.

1. Bob has a policy for Bob orchestrator :

Watch Alice Event Log, when new Notifications arrive send a message to my inbox

2. Bob orchestrator polls the Event Log, sees a new notification and sends a message to Bob inbox

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.

[mielvds]

The only actor in the current network that uses the as:target is the Orchestrator of Alice: to forward a notification from Alice's dashboard to the correct Service Hub.

The current workflow:

1. **Alice** drafts a notification in her dashboard with target : **Service Hub XYZ**

2. **Alice Dashboard** sends this notification to her **Alice orchestrator**

3. **Alice Orchestrator** forwards this notification to the **target** of her notification (Service Hub XYZ)

Why doesn't the Dashboard send this notification directly?

4. **Alice Orchestrator** appends the notification to **Alice Event Log**

it should append an event, not a notification. It's not an outbox, but I think you are hinting that we need one?

Now for Bob..Alice doesn't know Bob..he is just a silent admirer of her artefacts.

With "doesn't know", I guess you mean Alice will never receive notifications from Bob automagically.

1. **Bob** has a policy for **Bob orchestrator** :

Watch Alice Event Log, when new Notifications arrive send a message to my inbox

1. **Bob orchestrator** polls the Event Log, sees a new notification and sends a message to **Bob inbox**

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. Basically trigger the orchestrator based on the collector output.

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.

Agreed!

[phochste]

Why doesn't the Dashboard send this notification directly?

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 require orchestrator. If your dashboard requires a more advanced orchestrator to do all kinds of communication and policies it sends notifications to a remote orchestrator.

it should append an event, not a notification. It's not an outbox, but I think you are hinting that we need one?

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.

With "doesn't know", I guess you mean Alice will never receive notifications from Bob automagically.

No, what I meant that Alice never instructed her Orchestrator or her dashboard to forward as:Announce-s to Bob. Bob just found out that Alice has an Event Log and adds a trigger to his Orchestrator. Nothing forbids Bob to do this, or demand that he uses a collector for this. The orchestrator spec says orchestrators should be able to watch for updates of a resource..which is this case is a remote public Event Log.

[mielvds]

Why doesn't the Dashboard send this notification directly?

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.

Right, ok, my bad! So some init script (perhaps the orchestrator) creates the initial event log then.

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 require orchestrator. If your dashboard requires a more advanced orchestrator to do all kinds of communication and policies it sends notifications to a remote orchestrator.

notifications or any other custom Web API, but agreed!

it should append an event, not a notification. It's not an outbox, but I think you are hinting that we need one?

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.

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. An outbox is also not artefact centric, which increases discovery complexity for the collector. If Alice has 10 notifications for 10 artefacts each, Bob's collector has to download 100 notifications while it needs 10. You could mitigate this by

• having a SPARQL endpoint on Alice's side
• defining the event log as a resource that allows artefact-centric search over the outbox (basically a restricted SPARQL endpoint)

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? (target would become to, etc.)

With "doesn't know", I guess you mean Alice will never receive notifications from Bob automagically.

No, what I meant that Alice never instructed her Orchestrator or her dashboard to forward as:Announce-s to Bob. Bob just found out that Alice has an Event Log and adds a trigger to his Orchestrator. Nothing forbids Bob to do this, or demand that he uses a collector for this. The orchestrator spec says orchestrators should be able to watch for updates of a resource..which is this case is a remote public Event Log.

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.