Cannot create transient activities in ActivityPub API

[evanp]

@ThisIsMissEm notes on the mailing list:

if the a server is receiving via client to server an object that is an activity (because activities all extend from Object), and that activity has no object ID, then this language is saying one will be allocated, which would mean via C2S you could not send transient activities.

This is true. Do we need a way to say, I want this activity to have no ID, through the API?

[trwnh]

I am inclined to say "no", as the point of the outbox is to publish activities more than it is to deliver them. When you POST to an outbox, the main responsibility of the outbox is to assign a URI and return that as the Location header in an HTTP 201 Created response. (This really puts the "Pub" in "ActivityPub".)

If you don't assign a URI to an activity, then what is the outbox supposed to do? We might assume the payload should be delivered to recipients but not persisted in the outbox collection. But then, is a 201 Created response still appropriate, or should we expect a 200 OK instead? It doesn't make sense to persist the activity but not assign it a URI.

I think the main place where a transient activity could make sense is in POST to inbox instead of outbox, as might be more common with Linked Data Notifications. Alternatively, with proposals like using Server-Sent Events to stream activities from some event source, a client might be interested in directly published activities (e.g. a Like activity as received in the inbox) or indirect transient activities (e.g. an Add activity describing the Like being added to an as:likes collection).

So, rephrased or reframed, the question of "creating transient activities" is more like "delivering activities without creating them in the outbox". If you weren't using HTTP Message Signatures or if you controlled your own private keys, you could POST to inbox directly from a client without ever passing through an outbox. But for cases where signed HTTP messages are required and the outbox holds custodial keys, you would probably need some kind of "passthrough mode" or "proxy delivery endpoint" similar to as:proxyUrl but for delivering instead of fetching.

[silverpill]

Any mention of "transient" should be removed from the specification.

1. The concept of transient activity is not defined. There is only this vague sentence in section 3.1 Object Identifiers:

(short lived activities that are not intended to be able to be looked up, such as some kinds of chat messages or game notifications).

2. It conflicts with another concept, anonymous objects, which does have a precise definition:

An ID explicitly specified as the JSON null object, which implies an anonymous object (a part of its parent context)

3. Transient objects can't be authenticated, because fetching object by its id is the primary authentication method in ActivityPub.

4. There is no practical benefit in having this feature. The cost of generating an identifier is nearly zero.

5. Transient objects are not used by implementers. I know only one implementation that uses them, and the usage is limited to a single operation, so that is probably not intentional.

[evanp]

@silverpill I think Mastodon uses a lot of non-dereferenceable non-null activity IDs, for likes and follows and so on, which is the worst of both worlds, honestly.

[ThisIsMissEm]

@evanp yes, correct, it should really use dereferenceable IDs if it uses IDs at all

[silverpill]

I don't find non-dereferenceable IDs problematic. Maybe the object doesn't exist anymore, or maybe you're not allowed to view it -- there could be many reasons to return an error.

Mastodon uses fragment IDs for some activities, that's more annoying, but better than having no id because you can still reference these activities in Undo, Accept and Reject.

[TallTed]

Given that the IDs being minted are within the control of the minter, such that the minter can guarantee that these IDs will only ever be used to reference one and only one entity, it doesn't matter whether or not they are dereferenceable.

Linked Data best practices do strongly suggest that dereferencing an ID should lead to useful information about the entity identified by that ID, but the information provided by the server is (as always) at its discretion.