Following and notification levels

Motivating use case

In Vervis, when you comment on a ticket, you address the ticket followers, and they all get notified. This includes the ticket author and previous commenters (unless they opted out) and anyone who manually clicked Follow on the ticket.

Today I’m adding another detail: When you comment on a ticket, you also address the project followers. This may be expected, but, it’s not the only possible situation. For example, in GitLab CE (I checked on Framagit) you can either “Watch” a project, which is described as “receive notifications of any activity”, or you can set a “Custom” level, which means you can hand-pick which events to be notified on. Not all project followers necessarily want to be notified on new ticket/MR/diff comments (new “Notes” in GitLab terminology). How do we model this in ForgeFed?

Question 1: Addressing

First I’d like to ask, which recipients should be listed in the activity? Suppose a user writes a new ticket comment, on a remote ticket. The server needs to somehow address the project followers, but only those who wish to receive ticket comments (maybe some project followers care only about MRs and MR comments? Or only about new releases? Or only about new tickets, but not about comments?).

One kind of idea is to have separate collections for each situation. Instead of a single central “followers” collection, have a “followers-of-new-comments” collection, and a “followers-of-new-merge-requests” collection, and so on. Or some other setup with multiple collections. I’m not sure this is a good idea, just mentioning it for the record, and in case someone has ideas about it or wants to expand it.

My current proposal and approach is, to use the regular “followers” collection, and the recipient server will filter it based on the kind of activity.

For example, if I wrote a new ticket comment, and the ticket on which I commented on is hosted by a (hypothetically federated) GitLab CE server, that server will check which project followers want to receive new Notes, and only deliver to those who do.

The AP spec, and correct me if I’m wrong, only requires to deliver to all recipients that are owned by the actor. And inbox forwarding (which is my currently proposed mechanism for delivering to collections) explicitly allows to filter recipients by server-specific rules. So, unless I missed some detail, filtering the followers like that doesn’t contradict the AP spec.

Question 2: Activity

Which activities to use for this multiple-notification-level following mechanism?


  • To follow, use the standard Follow activity
  • To unfollow, use the Undo activity (which is the common Fediverse way)
  • To change the notification level… hmm that’s where I see 2 options and I’d like to ask you:

Option 1: Send an Update activity to update the Follow

Option 2: Send a new Follow activity

I guess both would work? It’s just that the concept of updating a past activity is a bit weird, it’s like rewriting the past. The Update should change the database record of the follow, and there’s no need really to “rewrite the past” by modifying the Follow activity in someone’s outbox. But in AP we don’t have a representation of the “follow record”, we just have a Follow activity.

Practically, I don’t mind Update{Follow}, so both options would be okay, but I’m curious about people’s thoughts on this, both the concept and how things are done in AP implementations.

Question 3: Properties

Which properties to use for describing the notification level? When you send a Follow and you want to follow only Tickets and MRs on a project, how do you specify that in the Follow activity?

A good answer may require going over a variety of existing forges and checking which notification levels and filters they have, and coming up with something reasonably general and detailed.

However, even if some client or server don’t support all the notification settings, it doesn’t harm federation: You can just “Watch” a project, be notified on all activity, and do client-side filtering. Also, this feature of custom notification levels doesn’t exist in Vervis right now (and not on Gitea and Gogs either, as far as I can see), so it’s not critical right now, but if someone has ideas about this, please share :slight_smile:

Feedback and thoughts highly appreciated!!! :slight_smile:

I (too?) would implement notifications levels on the client/receiving server (only).
Just federate all events and then decide on the receiving side what to notify the user about.

With that assumption:

  • RE Q1: Send all updates to all followers.
  • RE Q2: Standard follow activity.
  • RE Q3: I think there is no value in exposing the notification level in a standardized way beyond descriptive strings (i.e. description of the notification level targeted to humans not machines)