In practice, federation works _great_ when the apps all have the same basic structure, and gets pretty rough otherwise.

Mastodon instances basically _work great_ with each other, and with Friendica and Calckey too, since they have the same Twitter-like structure. Lemmy and Kbin - and all instances thereof - can chat with each other without issue too, since they have the communities + threads structure in common.

But trying to get Mastodon and Lemmy to talk to each other is 1. surprisingly possible, and 2. kind of annoying, since they speak the same protocol but have different structures of communication. And never mind other ActivityPub applications like BookWyrm or WriteFreely or PeerTube.

To expand on this a little the two services make use of different well-defined objects in the AP standard. Lemmy communities are Groups in AP and top level posts are implemented as Pages (rather than Notes). As it stands Mastodon only has basic support for these two but a rework of Groups is listed on the roadmap as in-progress (https://joinmastodon.org/roadmap).

Do they really need to work that differently though? It seems to me that almost all of them can be represented as trees of text entries. Blog+comments, HN/reddit threads, Stackoverflow QAs, DMs, Discord/Slack, forums. These are all just text trees with optional attachments and/or links to other content (images and videos etc). Why not build that tree structure into the protocol (all you need is 1 parent and 0+ children for each entry)?

(Using Lemmy+Mastodon as an example)

Lemmy has the concept of "communities" - subreddits, basically. On Mastodon, you can follow a Lemmy user and see their posts+comments exactly as you'd expect. And you can follow a community too! To Mastodon's point of view, the community is a single user that "boosts" (re-tweets) every post and every comment made within. So following a moderately active community from Mastodon will absolutely flood your feed with 100% of the community's user activity.

Meanwhile, Lemmy doesn't do direct messages or use hashtags as a first-class feature. So if a Mastodon user tries to DM a Lemmy user, or a Lemmy user wants to follow a hashtag, they're out of luck.

And again, there are other Fediverse apps with even different models than these. Gitea, Forgejo, and GitLab are going to adapt ActivityPub to all federate with each other - this is a huge win, of course - but would we expect someone to make or review a pull request from their BookWyrm account?

They absolutely do not. This is more of a state of the ecosystem sort of problem. I think a lot of developers were wary of getting into how some of the more esoteric AP objects should work. It's important to note too that while we have a standard in the form of AP a lot of the decisions about norms for these less common message types simply have not been made, but we are definitely moving in that direction as more services add AP integration.

I don't know enough about the Fediverse, but are those pluggable? I could see having a trusted third party for Identity management.

Why have a third party rather than choosing one of your apps to be the "primary"?

Why add the same functionality to all functions. Doesn't having a single function that handles that. In this case apps.

A blockchain might actually be a decent solution for this. Just make it so the tokens don't have value.

If all your target users are comfortable with the tradeoffs of systems built on blockchains (ie private key is the source of authority), you're probably looking for Nostr.

Nostr is not built on a blockchain

Yeah sorry for those not familiar it probably sounds like I was saying that. I just meant to point out it has some of the same UX tradeoffs.

For context the only things nostr have in common with Bitcoin is using secp256k1 for identity. It has been cooked mainly by bitcoiners but AFAIK part of the driving force was specifically to avoid the "everything is a blockchain with a native token" situation.

Naturally you will find lots of bitcoin people using and developing clients (hence the Lightning integration on most clients) but apparently it has been picking the interest of other groups. There seems to be a thriving Japanese community.

This is impossible, sorry. blockchain is before anything else, a very opinonated implementation of applied economic theory. The technology is secondary and consequent to the belief that people as a whole cannot be trusted to take care of things that they do not pay for. I say this is someone who is far from a fan of blockchain anything, but there's no getting around the fact that it is impossible to divorce it from its core principle, which is that pay to play has to be baked into the system at its deepest foundation.

And as soon as you introduce this, pay for the many becomes profit for the few, and inevitably markets, trading, and rent-seeking cartels form who swiftly capture the natural value confluence points of the system, reversing any decentralizing tendencies it may have, and collapsing it back towards centralization in order to consolidate and protect their advantaged position.

There is a lot of work being done on this.

I personally think initiatives like activiypod and vocata are interesting and would solve it well. They focus on being standard Activitypub implementations that others can subscribe to.