FEP-34ec: Notification Collection Endpoint
ActivityPub Protocol
2
Posts
2
Posters
0
Views
-
This FEP defines a standardized notification collection for ActivityPub actors. A new notifications property under endpoints (ActivityPub §5.7) provides an OrderedCollection containing Notification objects that inform the actor about relevant activities.
Unlike the inbox, which receives raw activities, the notification collection holds server-generated notification objects. Notifications only exist within the collection — read notifications are removed. Batch removal is supported via FEP-db70 (RemoveAll) with optional FEP-34c1 filtering.
Full text: //codeberg.org/fediverse/fep/src/branch/main/fep/34ec/fep-34ec.md
-
This FEP defines a standardized notification collection for ActivityPub actors. A new notifications property under endpoints (ActivityPub §5.7) provides an OrderedCollection containing Notification objects that inform the actor about relevant activities.
Unlike the inbox, which receives raw activities, the notification collection holds server-generated notification objects. Notifications only exist within the collection — read notifications are removed. Batch removal is supported via FEP-db70 (RemoveAll) with optional FEP-34c1 filtering.
Full text: //codeberg.org/fediverse/fep/src/branch/main/fep/34ec/fep-34ec.md
What is a "notification object"?
Wouldn't this fall outside the scope of AP? Is this a C2S specific route?
Gli ultimi otto messaggi ricevuti dalla Federazione
-
What is a "notification object"?
Wouldn't this fall outside the scope of AP? Is this a C2S specific route?
-
This FEP defines a standardized notification collection for ActivityPub actors. A new notifications property under endpoints (ActivityPub §5.7) provides an OrderedCollection containing Notification objects that inform the actor about relevant activities.
Unlike the inbox, which receives raw activities, the notification collection holds server-generated notification objects. Notifications only exist within the collection — read notifications are removed. Batch removal is supported via FEP-db70 (RemoveAll) with optional FEP-34c1 filtering.
Full text: //codeberg.org/fediverse/fep/src/branch/main/fep/34ec/fep-34ec.md
-
Ugh, Discourse is not receiving the whole thread. Please take a look at @jonny@neuromatch.social's replies on ActivityPub.Space
-
See my reply in another thread:
https://socialhub.activitypub.rocks/t/fep-7628-move-actor/3583/33
-
@julian
Its also a bit of a political question: who should be in charge? I tend to favor decentering instances in favor of empowering actors. So yes instances exist and need to change domains, but imo that would be best served by decoupling actors from instances and thereby domain changes, so an instance changing domains works just as well as an actor moving domains.
-
@julian
This one: https://codeberg.org/fediverse/fep/src/branch/main/fep/1580/fep-1580.mdThis was basically exactly what I had in mind actually, it would work equally well for whole instance moves (whether the source instance is still active or not). Using redirects from the old domain for objects is not really feasible for a bunch of reasons that come into play in core cases in which a domain migration would be necessary. Being able to migrate arbitrary objects resolves actor, instance, and object moves with a single mechanism. Predetermining IDs would be incompatible many AP implementations with and constrain the form IDs take. Re: the privacy note at the bottom, you don't need to publish actor lists either if you put the move object on the actor - the instance only needs to know the actors that the instance already knows about
After drafting and discussing for awhile I came to the conclusion that migrations sort of have to be driven by the target instance, with the source instance's role just being issuing a signed migration object so the implementation can be as simple as possible for the source and it can be retired as quickly as possible. most of the time migrations are forced by some duress at the source, and also are likely to involve an old/out of date instances. Maintaining mappings from the source instance is fragile and inevitably prone to hijacking.
-
No, I have not seen it. I was actually trying to find an existing spec before starting this one. Is it one of the FEPs?
-
Have you looked into the migration spec that @jonny@neuromatch.social put together a couple months back?
It was regarding content migrations between servers, but one could adopt the same for switching domains (although I think Jonny's is scoped to the user level, not at the instance level like yours)
