S2S Add/Remove language implies doing nothing

[trwnh]

The following language is contained in both C2S and S2S Add/Remove:

• the target is not owned by the receiving server, and thus they can't update it.
• the object is not allowed to be added/removed to the target collection for some other reason, at the receiver's discretion.

This language makes sense for C2S, where the "receiving server" / "receiver" are authoritative owners of the collection. It prevents situations where you Add or Remove to someone else's collection. However, for S2S, you may receive an Add/Remove that notifies you of a change from the authoritative server, and this Add/Remove necessarily will not be owned by you -- it is owned by the sender instead. ActivityPub results in delivery for all addressed actors in to/cc/audience.

Example:

• I Add an object to my collection via C2S. The receiving server (my server) validates it.
• My server then sends the Add to my followers (on other servers).
• The other servers receive an Add targeting a collection they do not own, and thus "do nothing" with it, since the first bullet point prevents them from doing anything if taken at face value.

Should there be expanded language describing such cases and what to do in these cases? Instead, the language for S2S Create is more appropriate:

the activity should appear in the actor's inbox and it is likely that the server will want to locally store a representation of this activity and its accompanying object. However, this mostly happens in general with processing activities delivered to an inbox anyway.

Just replace "object" with "target", as the local representation will most likely end up cached anyway.

Summary of proposed errata / guidance

Current language:

Upon receipt of an Add activity into the inbox, the server SHOULD add the object to the collection specified in the target property, unless:

• the target is not owned by the receiving server, and thus they can't update it.
• the object is not allowed to be added to the target collection for some other reason, at the receiver's discretion.

Proposed language:

Upon receipt of an Add activity into the inbox, it is likely that the server will want to locally store a representation of the activity's object within the local representation of the activity's target. The server SHOULD do this unless:

• the target is not owned by the sending server, and thus they can't update it.
• the object is not allowed to be added to the target collection for some other reason, at the receiver's discretion.

Ditto for Remove.

[evanp]

This is an important discussion. I added the following two pages to the primer to document better how to handle Add and Remove:

• https://www.w3.org/wiki/ActivityPub/Primer/Remove_activity
• https://www.w3.org/wiki/ActivityPub/Primer/Add_activity

I agree that noting that Add and Remove are largely noops would be helpful, but I am not convinced that the text of the specification is incorrect or misleading.

[trwnh]

As discussed during issue triage, the collection being managed may in fact be on a different server than the actor of the activity. This leads to three possible cases:

• Actor on sending server, Collection on sending server
  • C2S has side effects, S2S is noop
• Actor on sending server, Collection on receiving server
  • C2S is noop, S2S has side effects
• Actor on sending server, Collection on third-party server
  • C2S is noop, S2S is noop

Modifying a local representation (cache) is something that could be mentioned as in S2S Create, but if it doesn't rise to the level of errata then that's fine with me. I'm fine with closing this issue as resolved for the most part.

The interesting thing, I think, is the idea that delivery happens on the C2S side anyway, despite it being a noop. That is, if the C2S receiving server receives an activity targeting a collection on another server, then it should still handle delivery.

[nightpool]

I think this issue is pretty similar to #366 where implementors focus on the server to server section but are confused when that section doesn't include any guidance for same-server inbox delivery. I agree with Evan that this isn't exactly a spec problem per se but I think it would be smart to address with a non normative note in an editors draft

…

On Wed, Jan 3, 2024, 10:07 AM a ***@***.***> wrote: As discussed during issue triage, the collection being managed may in fact be on a different server than the actor of the activity. This leads to three possible cases: - Actor on sending server, Collection on sending server - C2S has side effects, S2S is noop - Actor on sending server, Collection on receiving server - C2S is noop, S2S has side effects - Actor on sending server, Collection on third-party server - C2S is noop, S2S is noop Modifying a local representation (cache) is something that could be mentioned as in S2S Create, but if it doesn't rise to the level of errata then that's fine with me. I'm fine with closing this issue as resolved for the most part. — Reply to this email directly, view it on GitHub <#407 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZCV73JJUMIQ3ONNFSLX3YMWM4NAVCNFSM6AAAAABBJB4CFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVG43DKNRRGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[evanp]

So, revisiting this topic, we seem to have a consensus to make an erratum to clarify the text. We don't have exact wording now, but we are going to tag this with "Needs erratum" and come back to it.

[evanp]

It's also worth considering that we might want to make synching collections easier in a future version. Re-fetching a large collection is a big cost in the network, and using Add/Remove/Update/... as a means to synch collections would really lower that cost.

[github-actions]

This issue has been labelled as potentially needing a FEP, and contributors are welcome to submit a FEP on the topic.
Note that issues may be closed without the FEP being created; that does not mean that the FEP is no longer needed.