The full minutes from the Forum and Threaded Discussions Task Force monthly meeting (held on 5 December) can be found at this Google Docs link The minutes are also inline below. Apologies in advance if I misrepresented anybody or missed any crucial bits of information. December 2024 Minutes Forum and Threaded Discussions Task Force --- Housekeeping Julian noted that the event description in the SWICG calendar calls for a monthly meeting from 1700 to 1800 UTC, although the scheduled time is pegged to 1300 to 1400 Eastern Time (observing DST). Dmitri (absent from meeting) to update event description as:Article and Mastodon treatment of non-notes Darius provided an update – been under the weather and busy with some other work-related items, but: Mastodon team cautiously optimistic about upstream PR, some concerns were voiced over things like inline images Hopefully by next month will have something more concrete to show to them; re: demo package Evan (@[email protected]) planning to get some people together in-person, to work together at FOSDEM in Brussels (Feb 2025); specifically to address long-form text issue Discussions about this in the task force would be considered the crucial pre-work Darius will update the group if something happens before January (re: code or PR package) A test instance up and running, Darius plans to make it more accessible for others to check out Silverpill’s FEP 171b is now an official draft, open for comments on SocialHub No specifics, just a news item. Context collections FEP Convergence Rationale for recommendation outlined in meeting agenda. Evan (@[email protected]) and a (@[email protected]) met up just prior to the WG meeting to discuss and work out differences between their FEPs; main notes: Using context to represent a reply tree is good Restricting usage of context is not the goal of 7888 or the ForumWG Co-exists well with 76ea’s thr:thread property to denote a reply tree, etc. Recommending use of as:context is one good way forward Evan recommends that the “should” in the proposal be changed to a “may” PROPOSAL: Publishers SHOULD use `context` for grouping related objects in a thread (but this is not the only way to use context). RESOLVED with 8 ayes, no nays, and no abstentions Brainstorming focus items for 2025 Emelia (@[email protected]) – multiple contexts? a (@[email protected]) : we need to also handle the fact that some contexts may not resolve Emelia: as:context can be an array of values in JSON-LD a: inReplyTo can have multiple values too; but in general, on the producing side we generate a single value – generally expect context/thread to remain the same (singular values) Sebi: "we thought a lot about multiple contexts" - led us to the conclusion of using profiles/describes property; per spec can only have one value Julian: Handling when implementors (e.g. lemmy/piefed) don't have the concept of topics a: there are multiple different models of how items are grouped together; reply tree model works for large part of the fediverse; mastodon has concept of reply tree represented internally as a conversation (vs context); this could be expanded into a conversation having an owner, etc.; mastodon has the conceptual ground to build upon Evan: reply trees work well on microblogs, blog comment trees, threaded posting systems, forums; other applications expect a more serial model... messenger/chat systems, where ordering of objects is not in a tree, no explicit relation between them; hashtags, locations, few other ways to use context Emelia: clarify overlap between replies collection and context collection? a: in general will include both ancestors and descendants; could add filters, look at tags, etc. to get subsets. If you are querying by context, you are looking for all objects related by said context Evan: full tree Julian: Mastodon reply-tree service proposed (https://github.com/NeuromatchAcademy/mastodon/pull/44) Julian: worried about scalability and performance of a backend service iterating through an entire reply tree; advocates that retrieving as:context is more performant especially if we build in some tooling for synchronization and member checking Emelia: historical reports of harassment due to `inReplyTo`; when looking at context including descendents, then how do we generate the tree? Evan: fep 76ea goes into detail about how reply trees can be managed a: answer is "who has the authority?"; who decides what goes into the collection? the `attributedTo` actor. For the replies collection, this exists IN PARALLEL TO `context`; in some ways a subset of the thread; could be a point of contention for systems that expect all objects to exist in general vs. conversation oriented Julian: upends expectation that objects are independent Darius: does this relate to announce leaking? recommendations that you not forward the entire object, just the ids Emelia: related but different; announce leaking -- should only ever do objects by ref (by the id) a: the paradigm shift is more social rather than technical -- that you cannot just rely on inReplyTo to prove that an object is approved some duplication as context includes replies, but they are distinct collections. They are decided by different authorities. `replies` is decided by whoever wrote the post Ted (@[email protected]): This sounds a lot like reinventing netnews, without taking the lessons that were learned from it; blurring the ideas of message store/relay/display; for all of this to work, the system has to pick up all replies, and let the client filter. Julian/a: anything specific to share? lessons, etc. – definitely of interest in not repeating the same mistakes

Reminder that the ForumWG meeting will start in roughly 1 hour and 20 minutes, at 1800 UTC, this is an hour later than scheduled due to DST (which does not occur for UTC), but should be the same local time if your country observes DST.

@julian Well, there are object types that Mastodon couldn't even handle if it wanted to. For example, it doesn't have anything to handle an Event-type object with. I don't think Gargron would build an event calendar into Mastodon just for Event-type objects, not unless enough people pester him to do just that.#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon

Reminder that the ForumWG meeting is coming up in one hour.

@julian @thisismissem @silverpill which is to say: audience is what decides which objects you are even *aware* of, before you even get around to grouping them logically.in a centralized system you would query for all objects in the database where the context was what you wanted, and where the audience included you.in a decentralized system you work off of what’s in your inbox, and “follow your nose” to the context, which may have its own audience.

@erincandescent @trwnh @evan @jenniferplusplus @mikedev @scott @julian @trwnhThe name of the property could be different, but I think it is useful to have two collections:- "Thread" is easier to implement, and in any case, software needs to keep track of reply trees, one way or another.- "Context" is a bonus. It contains everything related to a conversation, including reactions and edits. Some applications may not need it, and for some it might be difficult to implement, so it should be optional.My estimation is that implementation of "Context" + "Thread" will require roughly the same amount of effort as implementation of "Context" alone, so for those who want "Context" this separation should not be a problem. If software doesn't keep track of activities it can provide empty "Context", but their Add activities should nevertheless have it in target. Perhaps in the following form:"target": { "type": "Context", "id": "<context-collection>", "attributedTo": "<conversation-owner>", "thread": "<thread-collection>" }

Having a separate thread property may be useful. One possible use case would be where threads or posts are labelled or categorized or placed in a list, and this is exposed as a context.In that case, the thread and the context would be different. cc: @Evan Prodromou @Sean Tilley @julian @Darius Kazemi

@julian Yes, it was me. Thank you, I figured it was the one by Mr. Mike, thank you

@[email protected] thank you!

ForumWG meeting in ~1 hour N.B. We are deferring discussion on 1b12 vs 400e as @[email protected] is currently mid-flight, but will continue to discuss resolvable context, backfill, and syncing. There will be time for an open floor to discuss new topics, so if you have any ideas that may benefit the forum and threaded discussions sector of the fediverse, you are welcome to bring them up! Meeting Link

@julian @alex-mehr @trwnh>There's no guarantee that a collection would present items in chronological vs. reverse chronological order — are you checking the timestamps and reversing as needed?The ordering can be specified by some property of Collection>Wouldn't you need to paginage through the entire collection anyway?The client will fetch pages until it finds an item that has already been processed.> I think that informs why I set up topic synchronization in this manner, and why my idea of context collections contain only objects; to me, activities don't really mean much at all.I'd prefer context to be a collection of objects too, as long as there's a way to retrieve activity history.Activity-based sync seems more natural to me. I think ActivityPub can be better understood not as a protocol for social networking, but as a distributed database where nodes sync datasets by sending messages over the network. Messages are activities, datasets are collections. When I send a Follow activity and your server responds with an Accept, followers and following collections are updated on both sides (or their equivalents if you don't store activities and collections). More generally, any activity delivery can be viewed as a synchronization of outbox collection.I think such change of perspective can greatly improve DX and provide a solid foundation for further protocol extensions

Hi,Thanks for sharing this information.

@eeeee don't engage, some people will always be unhappy unless they get everything for free.

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.

The AS2 Recommendation defines actors as "entities capable of carrying out an Activity" and (for the Applicationactor property) "[describing] one or more entities that either performed or are expected to perform the activity". One can infer that any Object referenced or Link'ed to by the actor property of an Activity type is an actor that "carried out (or performed) the activity".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.)From my perspective this means there are AS2 actors and there are AP actors. The former have no inbox/outbox requirement. The AP actors are a constrained variant of AS2 actors. An application can have both kind of actors. Obviously, the AS2-only actors cannot communicate using AP inboxes, but they may still be useful, in general, for modeling "entities capable of carrying out an Activity".I'm not making any claims about well this would interoperate given how the existing AP implementations have evolved. Most current applications are hard-coded to a very restricted subset of AS2 types and often make actor-related assumptions that are not part of the AS2/AP Recommendations.In practice, beyond the 5 core actor "types" in AS2, identifying actor and extended actor types seems to me to be very application-specific.

I've also added FEP 1b12 announces for additional activities: Create Update Like Undo(Like) Delete Confirming that at least Discourse accepted the Announce(Like(Note)) and parsed it correctly.

Hey guys, looking forwarding to seeing you at the meeting today. We have a new video-call url:https://meet.jit.si/ap-forum-wgWe're getting the link updated on our SocialCG event too.

Thanks @[email protected]! That's good feedback and it's really exciting to know that there exist implementors out there whose default is not Note. I think at this point a real-time discussion at the next ForumWG re: the distinction between Article vs. Note would be beneficial. It'd be a continuation of the discussion we had last month. It's clear there are varied opinions on it, but as intimated by others, this might not actually be a problem that has technical solution.

I think the answer to that has to be that you have to take whatever context is associated with the object you're sent as canonical. Otherwise we'll always be second-guessing. The context on the object of the first object in whatever collection you resolve could also be "wrong". Yes, practically speaking, this may lead to errors in certain cases, however I think that's better than making the context overly relative.**edit I guess in this case, practically speaking, you'd follow up with the implementer of whatever platform is being used to resolve the context you initially got and ask them to fix their issue

@julian to clarify: this is mostly about "canonical" identifiers vs. aliases. there is generally one canonical identifier for the conversation collection, and this is what should be used as the value of `context`. this could get a bit complicated but there are potential ways to coordinate replication between equivalent conversation collections, probably involving mutual following/follower relationship, plus some indicator of aliases like `alsoKnownAs` or some other extension property.