mikedev

I think a couple of folks have mentioned trying to consolidate both of these approaches into one. I once used something that resembled 1b12 (long before there was a "threadiverse"), but as I recall it didn't really work well with private groups and aspects/circles - where you're often dealing with third-party permissions. You can only relay public activities to third parties via an Announce, and so conversations with restricted audiences don't work out very well for viewers on Mastodon. The third party does not have permission to access the activity from its author, only from the conversation owner. Once you've run into this issue, you are likely to more fully understand the advantages and disadvantages of these two approaches. Container operations are pure relays and work correctly with third-party access control, assuming you're using signed objects (which everybody should be using, but that's a hill to die on another day).

True, but fetch one collection and you've got it all. Might be paged, and with Mastodon that means another fetch for every ten activities (seriously?), but those are just implementation details.

We're using both here. There's an icon to let you know that you're looking at an actual conversation -- vs. a collection of microblog posts that once had a common ancestor.

The differences in signal/noise ratios between the two styles are quite dramatic. Neither is better or worse than the other. They are different. And they can both co-exist.

Also, conversation containers has the ability to "reply to all" as well as "reply to sender". Microblogs don't have this concept, and instead "reply to all" means "send to all your followers, instead of a reply directed to the actual conversation audience.

Additionally, consumers are also able to query the context owner for an index without needing to crawl the entire reply tree.

While this is certainly true, when conversation containers are working correctly, you never need to backfill a conversation. It is all delivered to you.

We accept punycode usernames and render appropriately; or pass through UTF-8 usernames. The biggest issue is autocomplete; so we provided that using aliases/petnames for connections. Probably will have issues on some platforms.

Might want to use a custom taxonomy/tag type for cross-posts. That's what we use for saving messages in "folders". While we don't typically federate these, I would imagine you might want to share those tags with software that supports cross-posting.

We normally do full activities, but after some prodding, I've begun implemented the forth-coming FEP about context vs contextHistory. So now the default context is objects for Create|Update|Delete Note|Article and activities for everything else, and contextHistory is full activities for everything associated with the opening post-of the conversation; but what a nightmare...

We do not typically provide URLs as collection members, because you may need a signed activity to access and validate third-party objects which have source access control enabled.

Conversation containers does send a 'Remove' if something is removed from a collection. But we typically don't waste resources on spammers, so we don't necessarily send a 'Remove' if we decided not to add it in the first place (perhaps due to comment controls, permissions, or blocks). You can send these as Remove activities if you want, but please don't force me to do so.

If you've fetched a conversation collection, it would be most common to do so in order to cache the conversation locally. In this case storing under local entities is going to be much more efficient if parents are stored before their children, so the InReplyTo can be pointed to an existing stored entity. If you do it backward, it's kind of awkward.

That said, our implementation of Collection objects has a flag to reverse the returned item order. So as long as the order is defined and isn't going to change, I don't actually care what it is; beyond the storage efficiency mentioned above. We need to sort it how we want after fetch anyway, because that's just basic input sanitisation.

It would seem most natural to me to send the collection in "thread" order - start from the root and recursively traverse every branch/leaf encountered. I'll mention this for consideration -- but again I really don't care.

That wasn't in my original doco and I'm not using it currently. I'll need to see what problem is solved by having Context before I offer an opinion.

I recall @[email protected] took issue with the fact that 'context' and 'target' are the same object and he felt this was duplicitous. There's also a bit of an issue that a "partial object" (defined in FEP-400e) isn't really defined anywhere in the base specs either - and perhaps using Context will help resolve that.

Since it's a SHOULD, my original implementation is arguably compliant with the FEP without it.

https://codeberg.org/silverpill/feps/src/branch/main/171b/fep-171b.md

It isn't so much "one FEP to rule them all" as it is that Conversation Containers stands on the shoulders of giants.