@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

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.

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.

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

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

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

@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.