This feature would be handy when agents making changes don't want to be notified about changes they just made. It should be an optional feature similar to state etc.
The client could ignore notifications if they always had ETag in response to the request making a change by comparing it to the state in the notification. In some approaches, this wouldn't suffice. For example, in my implementation of WebPushChannel (discussed in https://github.com/solid/notifications/issues/140#issuecomment-2064054278), the intermediate party receiving the webhook and forwarding it to webpush is different than the party performing the operation, resulting in change. Even more, WebPush requires notifications to be shown to the user which results in user seeing a push notification whenever they make a change to any resource they are subscribed to.
Assuming predicate notify:ignoreChangesBy (to be bikeshed). To advertise the feature, the subscription service would do the usual:
I'm also considering using user to allow client and possibly other options. It could be agent to match ACP's https://solidproject.org/TR/acp#matcher, but IMO, agent is too vague, and perhaps ACP should also consider changing it to user (going off-topic).
With the above, if http://alice.example makes the change, the notification would not be emitted to this channel.
This feature would be handy when agents making changes don't want to be notified about changes they just made. It should be an optional feature similar to
state
etc.The client could ignore notifications if they always had ETag in response to the request making a change by comparing it to the
state
in the notification. In some approaches, this wouldn't suffice. For example, in my implementation of WebPushChannel (discussed in https://github.com/solid/notifications/issues/140#issuecomment-2064054278), the intermediate party receiving the webhook and forwarding it to webpush is different than the party performing the operation, resulting in change. Even more, WebPush requires notifications to be shown to the user which results in user seeing a push notification whenever they make a change to any resource they are subscribed to.Assuming predicate
notify:ignoreChangesBy
(to be bikeshed). To advertise the feature, the subscription service would do the usual:The client would subscribe with the following:
I'm also considering using
user
to allowclient
and possibly other options. It could beagent
to match ACP's https://solidproject.org/TR/acp#matcher, but IMO,agent
is too vague, and perhaps ACP should also consider changing it touser
(going off-topic).With the above, if
http://alice.example
makes the change, the notification would not be emitted to this channel.I had a quick exchange about implementing it in CSS and I will be following up on that as we discuss it here.