Forums and Threaded Discussions Task Force

@erincandescent @julian @darius @trwnh it was offered as an option and I vastly prefer being able to resolve question by question rather than a long conversation thread that doesn't ever finish.

@[email protected] sorry, I invited somebody else in my address book haha

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

@silverpill @mikedev @julian the default assumption should not be "full representation", because you can never have the entire set of knowable facts about a given subject.what we should strive for instead is to make sure that any representation served is useful. this is not the same thing as it being "full". for example, there may be private attributes that are not being served.

While discussing what is contained in the context collection, I'd like to clarify what exactly is being Add'ed in 400e and (the upcoming) 171b, and whether that also coincides with the collection items. That is, if a context collection contains only simple objects, then the assumption is that context owner will only federate an Add out for simple objects. Likewise if the collection contains activities, then I'd expect Add(Like(Note)) to come from that owner. However, a quick re-reading of 400e suggests that only simply objects are federated out via Add. That would tip the scale a bit toward the context containing only objects.

@dariusk I may be overly optimistic, but I'd like to move forward thinking that perhaps that was then and this is now. Let's chat tomorrow (?) about the merits of your implementation and see whether we can make some waves!

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

@[email protected] thank you!

@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

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

I am interested in this topic. Please add me to relevant groups/calls. My mastodon ID is: @[email protected] How do I catch up on the current state of things? All I know is that Mastodon and some other software allows subscribing to hashtags: https://fedi.tips/how-do-i-follow-hashtags-on-mastodon-and-the-fediverse/ But this is neither universal nor sufficient. Each community might use different hashtags for different "topics".

Hi,Thanks for sharing this information.

Just a follow up reminder that there is no ForumWG meeting this month. See you all next month!

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

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.

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.

julian:audience it's not used widely, so there are limited unintentional side effects to using it. julian:technically there is nothing stopping a context in NodeBB from being a part of multiple audiences, our UI is largely built around them only being a part of one. julian:So to that end, if we were to support federated private group discussions, the audience would just be the category (with access restrictions) those objects and contexts are posted to, exactly how 1b12 expects.I'm not sure those three things add up exactly. Having multiple items in audience sounds like by your own admission as something that would cause at least UI issues for NodeBB, and also probably bigger issues for 1b12 implementations such as Lemmy: nutomic:In Lemmy each post belongs to single Group which is specified in audience. Having multiple audience values would be valid according to Activitystreams, but there is no way that Lemmy could support it.Now, this isn't an argument against having multiple items in audience. But it is something that needs more thought before pursuing it.For what it's worth, I remain mostly unconvinced that the best application of audience is to list a bunch of taxonomies. I'm also not sure it should be a single Group actor. I could maybe see it being a private collection including all to/cc/bto/bcc; I could also see it being something that you copy over from the context.audience to your own object/activity audience. So I guess the next question is, how do you include or exclude yourself from an audience? If there were an actor for you to Follow or Undo Follow, then that seems straightforward enough... but addressing and audience doesn't really follow that kind of paradigm. So something else is needed.

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.

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.