Forums and Threaded Discussions Task Force

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.

@grishka @mikedev>The originating server may not know who is part of the group and who is not, and therefore it can't enforce privacy by requiring a signed fetch.In Friendica, group participants are represented by private followers collection, which can be retrieved using signed fetch:https://socialhub.activitypub.rocks/ap/object/781ebb23f1080082071d0c156543eb5fSo I don't see any fundamental difference between FEP-400e and FEP-1b12. The authentication issue, however, is quite important, because without FEP-8b32 the group either doesn't scale or can impersonate anyone.@julian

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.

trwnh: Topics can be split In addition to splitting topics, topics or their posts can also be merged into another topic. The UX for this is quite variable; sometimes entire topics can be merged into another, sometimes a certain range of posts within a topic (post 5 .. 10 from 15 posts), and sometimes a selection (post 5 and 10 from 15 posts or just a singular item post 5 from 15 posts). trwnh: Topics exist in a category For #Flarum topics can also not exist in a Category (we call them tags and that extension is optional, like all of our extensions). Even when using a Category, once the Category is deleted, we do not hard delete any topics contained within but unlink them, making them less visible but still existing within the Forum. Regardless, to us, Topics CAN exist in a category, it's not required. trwnh: Users can be followed for posts and topics Users can be messaged directly This sounds as if this is a given, I don't think it's guaranteed in every Forum software. But if can implies optional, then

@[email protected] said in Traversing the reply chain when working with topics: infinite inReplyTo chain. I think this could be solved in part by the chain traversal sanity checking to ensure that the id is not already retrieved, but I'm not naive enough to assuming that that can't be circumvented. ... so yes, in that sense a limit makes sense from a security standpoint.

Cheers @[email protected] thanks for making it official. @[email protected] hopefully you can subscribe to the recurring event now

Hey @[email protected], how can I add events to the SWICG calendar? I notice there's a little button to include "Task Forces" in the listing, so I think listing our meetings would be helpful, now that we've settled on a more consistent time/day-of-week. cc @[email protected] (unrelatedly, do you get notified if I mention your SocialHub handle?)

@[email protected] said in Article vs. Note vs. Page: Since then WordPress has joined the Fediverse, and now Ghost is about to join as well. I think the ability to display rich content may soon become a serious competitive advantage. Completely agreed. The best time to consider a different approach is now, so I am hoping we can make some headway here at the WG meeting. Stay tuned... cc @[email protected] @[email protected]

@julian @rimu i think that was rimu actually, although i can probably give a summary

@devnull https://mastodon.social/@trwnh/112281961971187240https://mastodon.social/@trwnh/112281966283361424

Thanks @[email protected] — I think this is (one of) the last piece before two-way federation will start working. Hopefully it will be merged and updated soon

If I did things correctly, I should have a rudimentary two-way synchronization working now… I'm not sure if there's still a 5 minute delay between posting and federating... let's see.

@julian I am once again reminded of why Roberts Rules are written the way that they are and why the "Roberts Rules for small groups" caps at 12 people.

@[email protected] not a problem, I'll post up the minutes soon for open discussion! We didn't get into any technical details re: ordered collections, etc., so there's still time to discuss the intricacies of 9988.