No C2S `Announce`

[steve-bate]

The ActivityPub Recommendation describes side-effects for federated Announce activities (Section 7.11), but there is no normative description of how Announce should behave in the client-to-server protocol. Was this intentional? It's not difficult to guess how it should behave (e.g., similar to S2S), but it seems like a gap in the Recommendation.

[nightpool]

I don't think there's any need to call out Announce specifically in the C2S section of the spec? Are there any side effects specific to the *submission* of an Announce that you think the S2S section (what to do when you *receive* an Announce) doesn't handle?

…

On Sun, Jul 6, 2025 at 1:53 AM Steve Bate ***@***.***> wrote: *steve-bate* created an issue (w3c/activitypub#512) <#512> The ActivityPub Recommendation describes side-effects for federated Announce activities (Section 7.11), but there is no normative description of how Announce should behave in the client-to-server protocol. Was this intentional? It's not difficult to guess how it should behave (e.g., similar to S2S), but it seems like a gap in the Recommendation. — Reply to this email directly, view it on GitHub <#512>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZCV7CZRSEKAISBOROQWT3HDPYRAVCNFSM6AAAAACA37DWK2VHI2DSMVQWIX3LMV43ASLTON2WKOZTGIYDMMZRGI3TIOA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[steve-bate]

S2S is a different protocol. Developers implementing C2S shouldn't assume that any missing specifications mean they are the same as S2S (without that being explicitly stated).

[csarven]

As I see it, the C2S with respect to Announce encompasses what the message can be, where it can be sent, how it is sent, and with some expectations on how the client should behave/handle once the message is delivered or an error arises. Clients can consume Announces from outboxes or shares collections.

I'm not sure if I exactly understand the concern or shortcoming beyond that.

[steve-bate]

I'm not sure if I exactly understand the concern or shortcoming beyond that.

C2S has a client aspect and and server aspect (distinct from S2S server federation). The C2S server expectations for Announce are not specified.

[csarven]

Re, "C2S server expectations", do you mean client's expectations from the server?

Isn't the server's behaviour for Announce specified? Or is this all about providing additional requirements as to how servers should process or what they should once an Announce is received in an inbox?

[steve-bate]

There's a Client-to-Server (C2S/"API") part of the spec and a Server-to-Server (S2S/Federation) part of the spec.

Isn't the server's behaviour for Announce specified?

No, not in the C2S API/protocol part of the spec. That's the reason for this issue.

[csarven]

Then again, the C2S section doesn't mention all activity types. I'm not sure if there's more to how the server should behave beyond what's mentioned in Client Addressing and C2S Delivery with regard to receiving.

I think C2S Delivery serves as the general case for servers participating in federation, which is further detailed in S2S Announce Activity (sharing).

I suppose something like the following could be said in C2S (though perhaps already implied):

Upon receipt of an Announce activity in an outbox, servers participating in federation (see also delivery) SHOULD distribute the activity following client addressing.

Would something along those lines address your concern?

[tesaguri]

Then again, the C2S section doesn't mention all activity types.

Even the S2S protocol doesn't mention all AS2 activity types, so that shouldn't be the primary concern here.

I think the problem here is that the C2S protocol doesn't mention the side effect of an Announce activity on the object's shares collection, which isn't handled in the C2S sections you referenced. IIUC, it's not guaranteed in the current spec that the shares collection of an object gets updated when a local actor Announces the object.

[steve-bate]

I think the problem here is ...

Yes, that's it.

[evanp]

Great. Thanks @steve-bate for bringing this up. I think we should have a section in client-to-server and server-to-server for all of the AP-specified activity types (Create, Block, etc.). I don't see a good reason to make an exception for Announce activities in the API. So, I am going to mark this as "next version", but probably it would be worthwhile to add an erratum too. It could be relatively self-contained, about the same size as the other sections on the API.

[evanp]

I added a proposed erratum with the following text:

Section 6, "Client to Server Interactions", does not include a section on the Announce activity, although Section 7, "Server to Server Interactions", does. This leaves out side-effects of posting an Announce activity, including updating the shares property for objects hosted locally. One possible correction is to add the following paragraph in a sub-section of section 6 entitled "Announce Activity": The Announce activity is used to share activities and other ActivityPub objects with the addressees. The side effect of receiving this in an outbox is that the server SHOULD add the activity to the shares collection of the object if the shares collection is maintained by the server.

As usual, there is a bit of fuzz around the question of the relationship between an object and a "server". @trwnh noted that there's no requirement that the shares collection and the object are hosted/maintained on the same server, so even there we have some difference. However, I think within the fuzzy language of the AP spec, this is sufficient.