What was interesting was seeing that Fedilab presumably supports the StatusNet/Twitter API. Thought I would try this on a forte site since it supports that API.

It didn't appear to recognise the StatusNet/Twitter API at that location, but it did open the forte site as a PWA. So the next time somebody says that my software doesn't work on mobile -- it absolutely does,  and it works with Fedilab out of the box. But I'd still like to find out why it isn't recognising the StatusNet/Twitter API, because that would be the bee's knees and the Fedilab UI steals precious screen real estate when running as a PWA. You're probably better off installing forte as a native app.

I've also thrown about claims of EEE to some fediverse software without tangible evidence of intent, so I'll speak up here. I'm sure the project developers themselves would disagree, but many times these actions pass the walks-like-a-duck test. And it happens repeatedly. So even if it wasn't the intention, the pattern of actions has no distinguishing difference to performing the action with an intent that EEE will be the outcome.

It's sort of like the Krasnov example. Trump may not be a Russian asset, but his actions have resulted in the exact same outcomes that a hypothetical Russian asset in his position would produce; so it walks like a duck, and it happens repeatedly.

I see... the only time I cared was when supporting LD-signatures and then only if it was signed. But we got a bug last week about LD-parsing so there are people who care about that.

The streams repository and forte both parse it, but you probably already knew that. I know I had at least one nomadic actor that was visible to Mastodon a couple months back so it may be more about key parsing than the did's , as that's primarily where we differ from mitra.

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.

As soon as Mastodon redirects all comments with more than one paragraph back to their original site rather than displaying them inline (in other words, makes them type 'Article' and treats them just like they do 'Article' content from WordPress, Ghost, or Friendica), I'll turn on our "long-form content should be an Article" switch again. Until that day, it's going to be a Note.

I guess the real problem here is that we should be able to use the aptly named 'newsgroups' header field -- just like USENET in the days of yore. Otherwise there's a problem aggregating/routing replies. Especially with Mastodon involved, because the authors of each comment can change the recipients to anybody they want.  I brought up a 'replyTo' field for this use case a few years back, but it didn't get any traction and was subsumed by Conversation Containers. I guess the bottom line is that I don't see any way out of this without an FEP; because each commenter will need to be able to automatically route replies to every forum involved. Best I can come up with on short notice is Conversation Containers where the context and/or target are arrays of Collections and you'll be sending your replies to all of them.

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.