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
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.
The solution is to use actor’s outbox as a context.
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.
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.
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.
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.
Yes, I think in the discussed use case (followable streams, conversations and albums), the context collection should contain activities.
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).
Unresolved issues surrounding Follow activities 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.
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.).
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.
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.
Over in another thread, Steve said something that stuck with me:
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!
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.
That’s a distinction without a difference.
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.
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.
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.
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.
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.
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.
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.
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.
