One huge shortcoming of the Fediverse as currently implemented is that you have to use a different ID for each app, ie tube.jeena.net/@jeena, toot.jeena.net/@jeena, etc. What if you want to use the Mastodon UI to write a comment on a video? Your comment is going to use a different ID than the one you normally use to interact with videos. Given this, what's the point of federating these different apps with each other?
We need to figure out a way to share a single id across apps. Could be as simple as having a single URL as your user ID profile, and listing multiple public keys which are used by your various apps. The keys can be rotated as necessary since your URL is still the final authority on control over your identity.
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)?
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.
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.
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.
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.
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.
We need to figure out a way to share a single id across apps. Could be as simple as having a single URL as your user ID profile, and listing multiple public keys which are used by your various apps. The keys can be rotated as necessary since your URL is still the final authority on control over your identity.