Minutes from 6 June 2024 WG Meeting

julian

Please see below for minutes from today's Forum and Threaded Discussions Task Force monthly meeting.

Apologies in advance if I misrepresented anybody or missed any crucial bits of information

Housekeeping:
- Neither Angus nor Julian have updated the WG fediverse handles yet. Sorry about that! Good start, pat on the back, let's try again next month.
Angus: question of what we want to do with survey reports?
- Potential academic usage going forward
- Use of spreadsheets has direct utility; no need to come up with anything more complicated at this time
- Theoretically, one could develop an entire standard/knowledge graph for how the fediverse works
Group Federation among implementors (1b12/400e)
- Angus: Disambiguation is an issue: is a remote implementor following 1b12 or 400e?
  - trwnh pointed out that it doesn't matter, you can differentiate based on behaviour
  - Angus: From an implementor perspective, I am reminded that it is worth supporting the actions described in 400e as well
  - Julian: If the FEPs don't directly conflict, what is the minimum set of 400e behaviour we need to support?
  - trwnh: just because a group announces, doesn't mean it is 1b12. Hubzilla/Friendica send out announces, but send out the object itself
  - Angus to follow up on that minimum set of behaviours to support
Note vs. Article
- Seems to be a plurality of implementers sending as:Note (given Mastodon's substandard treatment towards Article types)
- If you deal with text, you'll almost always be sending out as:Note
- Much time was spent last meeting discussing the nuances of determining Article vs. Note.
- Evan P. had put it generally: A tweet is an as:Note, a blog post is an as:Article
- Conclusion: exercise in futility to attempt to determine with complete certainty whether any given submission fits "Article" or "Note"
- In the end may be best to let implementers send whatever they want, and others display it as they want.
- HOWEVER, undue influence from Mastodon because as:Article is reduced down to title/url.
  - renchap has opened the door to working out some sort of compromise
  - We will likely not get full representation (inline images, more html tags, etc.) in Mastodon, but a good compromise or stopgap would be to have Mastodon use summary to populate the text
    - Note that this conflicts with existing use of summary as content warning. Discussion to continue via fediverse.
- Angus: Open to facilitating a Mastodon PR if the team are open to one
- Darius Kazemi:
  - "I am happy to support robust implementations for new content types in Hometown as a proving ground for Mastodon "
  - "Also Hometown supports Articles if anyone wants to do proof of concept"
Use of context in objects
- Angus: potential use case bulk importing conversations; if we could get a base implementation working, that would be a good first step
- Julian: Given the results of the survey there is an opportunity here to trailblaze; there is no current observed standard of use for the as:context property
- Angus: A report to SocialCG could come after test/base implementation between NodeBB and Discourse
- Chris Moser: Feels like we've shoving forum/threaded discussions into an ActivityPub protocol
  - Should hash it out more instead of trying to fit it in
- Dmitri: We are talking about AS, not AP; could propose a forum-specific extension (see below re: extending AP/AS)
- Dmitri: Additioanlly, we do have the affordance of interpreting the context field by using as:type.
  - e.g. If it is type Article, then it means root thread, vs. if it is type Note, then means something else, etc.
- trwnh: Partial agree - Doesn't really matter what type is. AS 2.0 was written around that; e.g. context is "put this thing in this bucket"
  - The base use of as:context is to group things together, e.g. Pleroma, context is a literal string match
- Aaron: We need to create a new context for a period of time, use it across some implementations, then add it to AS 3.0 or similar
- Jennifer: Using context as grouping mechanism ; good first step
  - "The information I would hope to get out of a context collection is to know where to send that request to reply, or whether that would even be understood by the recipient"
  - e.g. managing reply control to a thread/topic
  - having an object there is a start, but reply controls would be great
  - trwnh: Some way to having an approval stamp; 0391 special collection proofs tries to describe this
    - we have two parallel paths, one with context collection, one with replies collection
- Chris Moser: AS supports multiple types? That could be used to our advantage; many devs use collection in context, we want to use it as an actor, can they be combined?
- trwnh: it is possible and I advocate for that; logical path is to have collections that can be followed. Actors don't have to be limited by type
- Dmitri: Should we expand the concept of actor? For the purposes of being able to follow. Got into that in previous AP triage meeting.
  - Counter-proposal: instead of collection being an actor, divorce the concept of outboxes and actors
- Julian: Let's take this offline to forum for now, reconvene next month
- Chris: Inbox/outbox not necessarily limited to actors
- a: Yes to adding to next month's agenda; an activitypub actor is anything that has an inbox/outbox. AS specifies types, but this can be discussed later.
Re: extending AP/AS
- Dmitri: A lot of devs would like to know how to extend the protocol
  - SocialCG is working on a "how do you add an extension" report, early draft is up
  - Super-basic and important question
- Jennifer: Extending can mean a couple diff. things; complication.
  - usually means adding a new term to the @context; that's trivial and permissionless
  - Alternatively, also FEP process, modifying AP/AS repo directly — much harder, whole w3c process
  - Dmitri: Adding to @context is easy
- Angus: Could be I or you (Julian) to write a standard
- trwnh: Volunteering to help facilitate creation of note/report to CG
Open floor
- Jennifer: Why the deference to Mastodon? Opportunity to go our own way.
- Julian: Good question;
  - Likely a non-insignificant part of the ForumWG would be happy to turn the tables, but easier said than done.
    - Some software's users would not understand the full context and ask for a better experience from Mastodon.
    - e.g. WordPress federation, was originally as:Article but now as:Note after very quick feedback
  - The ForumWG could play the card to let Mastodon play catch-up, and we might still, but given that they've signalled an interest in working towards a compromise, let's see where it goes (re: Note vs. Article)
- a: I would prefer to see other implementations go their own way, but mastodon CAN change, it will just take time
  - many users want something that works RIGHT NOW, not eventually
- Angus: viewing Mastodon compatibility as a starting point
Action items:
- Angus to investigate the minimum set of behaviours required to support remote implementers adhering to 400e
  - Angus and Julian to work closely on proof-of-concept use of resolvable context between their softwares prior to a formal report
- Spin-off discussions:
  - If you Announce(Object) are you not following 1b12?
  - Article vs. Note; recommendations, article contains richer html, note CAN be stricter, post attachments? Summary, but conflicts with CWs?
  - Is renchap open to better treatment of as:Article; stopgap solution
  - Chris Moser/trwnh/Dmitri - What is an actor, can a collection be an actor? Dmitri summary of previous AP triage meeting

[email protected]

julian:

trwnh: it is possible and I advocate for that; logical path is to have collections that can be followed. Actors don't have to be limited by type

I agree that actors don't have to be limited by type, but I don't think followable collections is a good idea. Actors, objects, activities and collections are fundamentally different things that shouldn't be mixed.

julian:

Chris Moser: AS supports multiple types? That could be used to our advantage; many devs use collection in context, we want to use it as an actor, can they be combined?

The solution is to use actor's outbox as a context.

julian

Just mentioning @[email protected] so he is aware of your reply.

a

silverpill:

I don’t think followable collections is a good idea. Actors, objects, activities and collections are fundamentally different things that shouldn’t be mixed.

Can you expand on this? I don't see a problem with followable collections, and in fact, I see several things it could solve. Say you want to categorize your posts into multiple streams, and let people follow only one or some of them instead of following you for all of your activities. Say you want to follow a specific thread/conversation. Say you want to follow a media album for updates. And so on.

silverpill:

The solution is to use actor’s outbox as a context.

I'm not sure what this would accomplish or even mean. The object exists in context of the outbox collection? You should view the outbox collection instead of this object? One limitation is that the outbox collection MUST only contain activities and not the objects themselves. This can be worked around with followable collection-actors. In that case, the outbox contains all activities produced by the collection, and the items/orderedItems contains all objects that are part of the collection-context.

[email protected]

trwnh:

Can you expand on this? I don’t see a problem with followable collections, and in fact, I see several things it could solve.

ActivityStreams spec defines actors, objects, activities and collections as different core types. That follows the principle of separation of concerns, and generally a sensible thing to do, from the implementer's perspective.

Actors perform actions, other entities are affected by those actions.

trwnh:

I’m not sure what this would accomplish or even mean.

According to the ActivityPub spec, "The outbox stream contains activities the user has published". So, if the context of activity is outbox, that means activity has been published by actor. This is what FEP-1b12 groups do, they re-publish activities.

trwnh:

One limitation is that the outbox collection MUST only contain activities and not the objects themselves.

Yes, I think in the discussed use case (followable streams, conversations and albums), the context collection should contain activities.

Steve Bate

silverpill:

trwnh:
Can you expand on this? I don’t see a problem with followable collections, and in fact, I see several things it could solve.
ActivityStreams spec defines actors, objects, activities and collections as different core types. That follows the principle of separation of concerns, and generally a sensible thing to do, from the implementer’s perspective.
Actors perform actions, other entities are affected by those actions.

The AS2 Follow activity can be used with any Object, not just actors. AS2 says that it "Indicates that the actor is "following" the object". The means that supporting Follow doesn't require the followed object to have an outbox (primarily a C2S concept in AP) or an AP/LDN inbox. I don't see any issue with separation of concerns on this specific topic. However, I agree that treating a collection as an actor may do that. On the other hand, if the collection is logically performing actions (e.g., self-deleting references to activities after some time), then it seems reasonable to me. Just making a collection follow-capable wouldn't justify treating it as an actor.

Publishing collection changes is an interesting case. If the collection is publishing Announce activities, where it is the object of the actor property, then it does seem to at least an AS2 actor. I'd need to think more about whether it would be required to be an AP actor (with a required inbox and outbox).

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.