search

w3c / activitypub

http://w3c.github.io/activitypub/
Other
1.16k stars 71 forks source link

S2S Add/Remove language implies doing nothing #407

Open trwnh opened 6 months ago

trwnh commented 6 months ago

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:

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 commented 6 months ago

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

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 commented 6 months ago

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:

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 commented 6 months ago

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 https://github.com/w3c/activitypub/issues/407#issuecomment-1875765613, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCV73JJUMIQ3ONNFSLX3YMWM4NAVCNFSM6AAAAABBJB4CFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVG43DKNRRGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>