Recently, there was a discussion about generic #ActivityPub servers.
-
Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.
I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:
FEP-fc48: Generic ActivityPub server
This kind of server:
- Can process any object type, and can process non-standard activities like
EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.
@silverpill @mariusor @trwnh In principle, I like the general idea, but I think it's misleading to call this an "ActivityPub" server FEP since it doesn't conform to the ActivityPub specifications. You also recommend (require?) using the `result` property to describe server side-effects, but you don't describe *how*. I don't know how you expect to "force clients to specify them".
-
@silverpill @mariusor @trwnh In principle, I like the general idea, but I think it's misleading to call this an "ActivityPub" server FEP since it doesn't conform to the ActivityPub specifications. You also recommend (require?) using the `result` property to describe server side-effects, but you don't describe *how*. I don't know how you expect to "force clients to specify them".
This FEP introduces new requirements to ActivityPub, and I will probably add more in the future. Does that make it non conformant?
In any case, I think calling it an ActivityPub server is appropriate.
Side-effects are activities, I will clarify that in the FEP. The value of
resultproperty can be an embedded activity, or an array of activities.Clients either specify them, or they don't get any side effects.
-
This FEP introduces new requirements to ActivityPub, and I will probably add more in the future. Does that make it non conformant?
In any case, I think calling it an ActivityPub server is appropriate.
Side-effects are activities, I will clarify that in the FEP. The value of
resultproperty can be an embedded activity, or an array of activities.Clients either specify them, or they don't get any side effects.
@silverpill @mariusor @trwnh
> This FEP introduces new requirements to ActivityPub, and I will probably add more in the future. Does that make it non conformant?Not at all. I was referring to the `Add` without an `object` to create a collection (instead of Create/Collection, I assume).
-
@silverpill @mariusor @trwnh
> This FEP introduces new requirements to ActivityPub, and I will probably add more in the future. Does that make it non conformant?Not at all. I was referring to the `Add` without an `object` to create a collection (instead of Create/Collection, I assume).
-
This FEP introduces new requirements to ActivityPub, and I will probably add more in the future. Does that make it non conformant?
In any case, I think calling it an ActivityPub server is appropriate.
Side-effects are activities, I will clarify that in the FEP. The value of
resultproperty can be an embedded activity, or an array of activities.Clients either specify them, or they don't get any side effects.
@silverpill @steve this actually raises an interesting question about "side effects" and where they live. in the AP spec it's rather muddled and i've talked before about the issue of "activities as content/notifications vs activities as procedure calls". i personally err toward having no side effects, which i think were kind of a mistake for the reason you bring up (generic servers can never be aware of extended side effects).
-
@silverpill @steve this actually raises an interesting question about "side effects" and where they live. in the AP spec it's rather muddled and i've talked before about the issue of "activities as content/notifications vs activities as procedure calls". i personally err toward having no side effects, which i think were kind of a mistake for the reason you bring up (generic servers can never be aware of extended side effects).
@silverpill @steve typically i've taken a view similar to IFTTT -- the activities describe things that happen, probably already happened. one or more listeners can do whatever they want with that information. CRUD is boring to me and i would rather do that with HTTP (POST/GET/PUT/DELETE); the more interesting activities are things like Listen (scrobbles) or Arrive (checkins) or Question (stackoverflow) or so on.
-
@silverpill @steve typically i've taken a view similar to IFTTT -- the activities describe things that happen, probably already happened. one or more listeners can do whatever they want with that information. CRUD is boring to me and i would rather do that with HTTP (POST/GET/PUT/DELETE); the more interesting activities are things like Listen (scrobbles) or Arrive (checkins) or Question (stackoverflow) or so on.
@silverpill @steve it sounds like you're describing an "AP server" whose primary functionality is not "publish activities" but rather "manage CRUD for objects and Add/Remove for collections", by taking the AP "side effects" for Create/Update/Delete/Add/Remove and and saying the outbox should also check as:result.
which is cool but should probably be disambiguated.
-
@silverpill @steve it sounds like you're describing an "AP server" whose primary functionality is not "publish activities" but rather "manage CRUD for objects and Add/Remove for collections", by taking the AP "side effects" for Create/Update/Delete/Add/Remove and and saying the outbox should also check as:result.
which is cool but should probably be disambiguated.
@silverpill @steve so maybe instead of "generic activitypub server" the FEP should be called something like "explicitly specifying side effects with the result property". it seems to me like the references to 2277 and fe34 are not strictly necessary to the core idea and a separate FEP could bundle them together into a profile, like "a profile for using outbox activities to manage objects and collections". not sure what the best name is because naming things is the hardest
-
@silverpill @steve so maybe instead of "generic activitypub server" the FEP should be called something like "explicitly specifying side effects with the result property". it seems to me like the references to 2277 and fe34 are not strictly necessary to the core idea and a separate FEP could bundle them together into a profile, like "a profile for using outbox activities to manage objects and collections". not sure what the best name is because naming things is the hardest
@trwnh @silverpill I agree about the name and the extraneous external FEP references. Even if focused on side-effects, a properly specified FEP on this topic would be a challenge.
-
@silverpill @steve so maybe instead of "generic activitypub server" the FEP should be called something like "explicitly specifying side effects with the result property". it seems to me like the references to 2277 and fe34 are not strictly necessary to the core idea and a separate FEP could bundle them together into a profile, like "a profile for using outbox activities to manage objects and collections". not sure what the best name is because naming things is the hardest
@trwnh @silverpill Another interesting "side effect" twist... some of the standard side effects are conditional (like only adding an actor to a following collection after an Accept is received). I think the FEP should also cover what happens with Undo of an activity with explicit side effects. Some secondary/side activities might have clear inverses and others not (some kinds of Update?).
-
@trwnh @silverpill Another interesting "side effect" twist... some of the standard side effects are conditional (like only adding an actor to a following collection after an Accept is received). I think the FEP should also cover what happens with Undo of an activity with explicit side effects. Some secondary/side activities might have clear inverses and others not (some kinds of Update?).
@steve @silverpill i assume the Undo would have a result that describes that? so Undo(Follow) might have a result of Remove from Follow.actor.following+Follow.object.followers in theory. for the other way around the Follow doesn't have a result but the Accept(Follow) has a result of Add to Follow.object.followers+Follow.actor.following
but i think Follow is a bad example because it really should be subscription record management instead, ideally.
-
@steve @silverpill i assume the Undo would have a result that describes that? so Undo(Follow) might have a result of Remove from Follow.actor.following+Follow.object.followers in theory. for the other way around the Follow doesn't have a result but the Accept(Follow) has a result of Add to Follow.object.followers+Follow.actor.following
but i think Follow is a bad example because it really should be subscription record management instead, ideally.
@steve @silverpill the other question is if this level of explicitness is useful. the answer AP spec gives is "no, just assume every server SHOULD do this".
and a tangent for follows: they are too stateful. you send Follow and Accept and someone knowing about those two might assume you are a follower now but not be aware of later removal or undoing (of either the Follow or Accept). this is broken in practice for years because Follow/Accept follow is not expressive enough
-
@steve @silverpill i assume the Undo would have a result that describes that? so Undo(Follow) might have a result of Remove from Follow.actor.following+Follow.object.followers in theory. for the other way around the Follow doesn't have a result but the Accept(Follow) has a result of Add to Follow.object.followers+Follow.actor.following
but i think Follow is a bad example because it really should be subscription record management instead, ideally.
@trwnh @silverpill Yeah, it's not the only bad example of side effects specified in AP. Most of the side effects are optional (SHOULD) and outbox delivery (federated or local) isn't described as a side effect. I think that's one of most significant side effects of posting an activity to the outbox.
-
@steve @silverpill the other question is if this level of explicitness is useful. the answer AP spec gives is "no, just assume every server SHOULD do this".
and a tangent for follows: they are too stateful. you send Follow and Accept and someone knowing about those two might assume you are a follower now but not be aware of later removal or undoing (of either the Follow or Accept). this is broken in practice for years because Follow/Accept follow is not expressive enough
@steve @silverpill it's why mastodon went with the concept of "stamps" as http resources that could be fetched to retrieve latest state (200 / 404). you no longer need a complete ordered history of activities and you don't need to calculate the current state from those activities.
subscription records would work the same way and could be extended to allow subscribing only to certain activities instead of an unfiltered everything
-
@trwnh @silverpill Yeah, it's not the only bad example of side effects specified in AP. Most of the side effects are optional (SHOULD) and outbox delivery (federated or local) isn't described as a side effect. I think that's one of most significant side effects of posting an activity to the outbox.
@steve @silverpill in theory POST to outbox should publish the activity, and should trigger the delivery algorithm based on audience (which is another thing handled poorly compared to even smtp which it tried to copy...)
imo that should be part of the protocol contract, and the idea of "side effects" unfortunately muddles that. the guarantee should be built into the outbox delivery algorithm and an outbox should signal this algorithm is in effect.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@steve @silverpill in theory POST to outbox should publish the activity, and should trigger the delivery algorithm based on audience (which is another thing handled poorly compared to even smtp which it tried to copy...)
imo that should be part of the protocol contract, and the idea of "side effects" unfortunately muddles that. the guarantee should be built into the outbox delivery algorithm and an outbox should signal this algorithm is in effect.
-
@steve @silverpill it's why mastodon went with the concept of "stamps" as http resources that could be fetched to retrieve latest state (200 / 404). you no longer need a complete ordered history of activities and you don't need to calculate the current state from those activities.
subscription records would work the same way and could be extended to allow subscribing only to certain activities instead of an unfiltered everything
-
@trwnh @silverpill Yeah, it's not the only bad example of side effects specified in AP. Most of the side effects are optional (SHOULD) and outbox delivery (federated or local) isn't described as a side effect. I think that's one of most significant side effects of posting an activity to the outbox.
-
@steve @silverpill the other question is if this level of explicitness is useful. the answer AP spec gives is "no, just assume every server SHOULD do this".
and a tangent for follows: they are too stateful. you send Follow and Accept and someone knowing about those two might assume you are a follower now but not be aware of later removal or undoing (of either the Follow or Accept). this is broken in practice for years because Follow/Accept follow is not expressive enough
-
@steve @silverpill i assume the Undo would have a result that describes that? so Undo(Follow) might have a result of Remove from Follow.actor.following+Follow.object.followers in theory. for the other way around the Follow doesn't have a result but the Accept(Follow) has a result of Add to Follow.object.followers+Follow.actor.following
but i think Follow is a bad example because it really should be subscription record management instead, ideally.
-
@trwnh @silverpill Another interesting "side effect" twist... some of the standard side effects are conditional (like only adding an actor to a following collection after an Accept is received). I think the FEP should also cover what happens with Undo of an activity with explicit side effects. Some secondary/side activities might have clear inverses and others not (some kinds of Update?).
-
@trwnh @silverpill I agree about the name and the extraneous external FEP references. Even if focused on side-effects, a properly specified FEP on this topic would be a challenge.
-
@silverpill @steve so maybe instead of "generic activitypub server" the FEP should be called something like "explicitly specifying side effects with the result property". it seems to me like the references to 2277 and fe34 are not strictly necessary to the core idea and a separate FEP could bundle them together into a profile, like "a profile for using outbox activities to manage objects and collections". not sure what the best name is because naming things is the hardest
