Minutes from 6 June 2024 WG Meeting

a

stevebate:

supporting Follow doesn’t require the followed object to have an outbox (primarily a C2S concept in AP) or an AP/LDN inbox

https://socialhub.activitypub.rocks/t/unresolved-issues-surrounding-follow-activities/114 explores this from years ago, but basically: if you don't give an object an inbox, it's not clear where to send the Follow or if the Follow is even supported. It's not enough to say "just send it to the attributedTo actor's inbox", because the attributedTo actor might not understand or support sending you updates about any given object. It's just architecturally cleaner to give it its own inbox property. And also a followers collection, even if it's private, to indicate that it can be followed.

Steve Bate

trwnh:

It’s just architecturally cleaner to give it its own inbox property. And also a followers collection, even if it’s private, to indicate that it can be followed.

Sounds reasonable to me, but my point was that inbox property doesn’t necessarily make the object an “actor”. It could just be identifying an HTTP endpoint for sending Follow requests. Those Follow requests might be acted upon (Accepted or Rejected) by some separate actor (the attributedTo actor, a collection manager of some kind, the “instance actor”, etc.).

[email protected]

I might have been too quick to suggest outbox, but it can be some other collection associated with an actor.

My main point is, actors and collections are different beasts. Actors, activities and objects are representations of things that actually exist: people, their interactions, posts. Collections are more like REST API endpoints.

Steve Bate

silverpill:

My main point is, actors and collections are different beasts. Actors, activities and objects are representations of things that actually exist: people, their interactions, posts. Collections are more like REST API endpoints.

I don't agree with that view of Collections. A Collection can also represent something that actually exists. However, the AS2 collection paging approach does seem to be more of a presentation-oriented API than a domain abstraction, so that muddies the topic a bit.

[email protected]

Yes, Collection can represent a conversation or a photo album, but I don't think it should be used like that.

@trwnh what do you think about this representation:

{ "type": "Group", "id": "https://forum.example/testtopic", "inbox": "https://forum.example/testtopic/inbox", "outbox": "https://forum.example/testtopic/outbox", "context": { "type": "Collection", "id": "https://forum.example/testtopic/context" "items": [], }}

It is very similar to your idea of a followable collection, but without mixing core types.

[email protected]

Over in another thread, Steve said something that stuck with me:

What is an Actor, anyway...

The ActivityPub Recommendation added additional requirements for an actor to have inbox and outbox endpoints. (However, the inverse isn’t necessarily true. An object with an inbox and outbox endpoint may or may not be an AP actor.)

I think a Collection could have an inbox, without becoming an Actor, and that kinda makes both options defensible logically, although I can see pros and cons to both. "Collection with an inbox" seems to me appropriate for collections objects that emphatically aren't Actors (say, a subreddit, a channel, a thing Actors post into), while "Actor Group" (the multi-type enthusiasts might even want to insist on the "type": {"Group", "Actor"}" rather than just refining Group as an extension of Actor!) seems more appropriate for a group chat, a mailing list, a group of Actors who act collectively and can be blocklisted or moderated as if they functioned as one Actor.

Basically I'm worried our fear of neologism is leading us to cram disparate things into the same data model to avoid writing a FEP with an @Context extension-- maybe Groups and Collections both deserve to exist for different use-cases!

a

silverpill:

Yes, Collection can represent a conversation or a photo album, but I don’t think it should be used like that.

Why not? I would think that the Collection being a target for Add and Remove activities is self-evidently a natural way of doing things.

A Group with a context collection doesn't make sense at all. It implies that the Group is part of that collection, instead of the collection containing posts.

bumblefudge:

I think a Collection could have an inbox, without becoming an Actor

That's a distinction without a difference.

bumblefudge:

I’m worried our fear of neologism is leading us to cram disparate things into the same data model to avoid writing a FEP with an @Context extension-- maybe Groups and Collections both deserve to exist for different use-cases!

I’m worried of the inverse, that we throw away what was perfectly well-intended in favor of something else that works pretty much exactly the same. Collections can have inboxes and followers and they can even be self-managing actors that Add objects into themselves. All of these and more are valid mechanisms. You can have a [Collection], a [Application, Collection], a [Conversation, Service, Collection], whatever. Creating your own vocabulary term ought to be reserved for when you have a clear concept that isn't expressible using current vocabulary.

I should probably also mention I am currently workshopping a FEP for further specifying Collection subtypes, such as Conversation and MediaAlbum. Mike Macgirvin from Streams a while ago expressed a desire to identify the purpose of a context collection, and it is a perfectly reasonable ask.

Steve Bate

trwnh:

bumblefudge:
I think a Collection could have an inbox, without becoming an Actor
That’s a distinction without a difference.

I'm not convinced this claim is accurate. As you know, AP inboxes are based on Linked Data Notifications (LDN) and is intended to be interoperable with it. A notification receiver in LDN has an inbox but there's no concept of an actor. One could view a Collection with an inbox and no outbox as an LDN Receiver rather than an AP Actor (assuming the Collection is not the actor in AP/AS2 activities).

----An aside...

Practically speaking, I'm wondering if the inbox URI in an AP S2S-only context is essentially an advisory for where to POST messages related to the object associated with the inbox. No inbox collection is required and, in fact, most AP S2S-only servers, like Mastodon, do not maintain an inbox collection. There's also no requirement for actor-specific inboxes in S2S (the actor inbox can refer to a server-level inbox), so it seems to me that the relationship between the two is relatively loose. However, actor-specific inboxes are useful for the rarely used C2S API where a client needs to dereference a URI to a Collection of their specific inbox activities.

[email protected]

stevebate:

There’s also no requirement for actor-specific inboxes in S2S (the actor inbox can refer to a server-level inbox), so it seems to me that the relationship between the two is relatively loose. However, actor-specific inboxes are useful for the rarely used C2S API where a client needs to dereference a URI to a Collection of their specific inbox activities.

Make Clients Powerful Again! Actor-specific in/outboxes open up a lot of freedom for actors having multiple servers, doing client-side signing, being discoverable via multiple networks, etc etc.

a

stevebate:

One could view a Collection with an inbox and no outbox as an LDN Receiver rather than an AP Actor

I think the outbox should be there even if private, and I think it should also have a followers collection even if private. I don't think an inbox alone is "enough" to send a Follow, yeah.

Steve Bate

trwnh:

I think the outbox should be there even if private, and I think it should also have a followers collection even if private. I don’t think an inbox alone is “enough” to send a Follow, yeah.

Why? Technically, an inbox endpoint is enough for sending and receiving a Follow (and any other AP activity, AFAIK). I don't know what the purpose of a private outbox would be for S2S purposes (a non-private outbox could be used to back-fill content).

IIUC, you're proposing using the presence of a followers property as an object-level capability indicator. Although I haven't seen it used that way in AP implementations, it's an interesting idea.

[email protected]

trwnh:

Why not? I would think that the Collection being a target for Add and Remove activities is self-evidently a natural way of doing things.

Let's think about the outbox collection, which most closely resembles an API endpoint. Clients POST activities to it, and clients can GET its contents, but they don't directly create the outbox "object". The outbox object is managed by the server.I'm arguing that all collections work like this, that they are APIs. In case of Add and Remove activities, the client tells the server to update the target collection, but again it doesn't manage the collection directly.The nature of collections becomes more evident in C2S setting, especially in implementations where client controls the key and signs activities/objects. It is not practical to re-sign collection pages after every update.

a

Outbox is required by the spec so it's a good idea not to leave it out. However, the other reason is that I would propose the outbox contain the Add activities while the items/orderedItems contains the objects. This way you have mechanisms to fetch/backfill either objects or activities depending on what you want. I agree that it doesn't make much sense to have it be private, but some implementers have made it private before, and some other implementers might check for it as a validation.

silverpill:

they don’t directly create the outbox “object”. The outbox object is managed by the server.I’m arguing that all collections work like this

I would argue that only "special collections" work like this. You can Create a Collection and manage it manually with C2S. You don't need to sign it after every change. Just sign the activities and/or objects within.

Steve Bate

trwnh:

Outbox is required by the spec so it’s a good idea not to leave it out.

I’m apparently not communicating clearly and I apologize for that. I’m discussing Collections with an inbox property and no outbox property. These are not AP actors and outbox is not required in this case. However, I agree the property should be (must be) present for AP actors, since that’s required by the AP Rec.

a

I might not be communicating clearly either, but it’s a consistency thing. The intended usage I’m advocating for is to “make it an actor” by giving it an inbox and outbox, but also to go further and make self-managing collections that are attributed to themselves and Add objects into themselves. You can make the outbox private but you probably don’t want to. I don’t really see why to leave it out unless you were really adamant that the collections wouldn’t be actors. And if you go as far as I’m proposing with self-managing collections, then those are more clearly actors because they will be the actor of the Add activity. But also, you don’t have to go that far to just stick an outbox on it.