The only threat to this burgeoning community is the same old divide & collapse nonsense that separates citizens under their overlords everywhere.
I would create accounts and start calling to defederate instances which allow non-polite (or politically incorrect or otherwise offensive) communities.
We didn’t just survive the trolls on reddit. We thrived amongst them. We can handle them. We can block them.
I want curatorial tools to curate my own feed. I absolutely 100% do NOT want any admins telling me what I can’t read. And going to another instance is no solution if that instance is blocked.
I don’t want to be on a purely polite ecosystem, or a purely right-wing-idiot ecosystem. I want access to everybody, and the tools to curate that experience.
The trolls do NOT have the power to take us down. But the admins definitely do.
Welcome to the Defediverse.
IMO this is a separate problem; I’d like the ability to move my account between servers and preserve my comment history and subscriptions.
The comment history migration will not happen. It’s not feasible with the way fedi software works. Subscription migration tools exist but are limited, and I am sure they will grow more prolific in the future, because the tools for it are getting better.
I admit it’s more complicated than it first seems, and I’m not deeply familiar with the ActivityPub protocol, but could you elaborate on why it wouldn’t be feasible to extend AP to support user account migration?
I know there’s some kind of identity hashing for servers. If you want to change a user’s entire identity you’d also have to convince all servers that this hash is still yours elsewhere. Maybe if you trigger it from the original server. I don’t know enough of the software to design a solution but it’s not the simplest thing and it’s not built for that. Maybe ask someone with more technical knowledge.
I have a fairly good idea of how this could be implemented, but like I said, it’s more complicated than it first seems.
The issue you mentioned could be solved by the “old” server signing a JWT token that includes both the old user ID and the new user ID. The “new” server would store that token and make it available via an API endpoint so other servers and users could verify that the account on the “new” server is legitimate. This way accounts can be verified even if the original server goes offline.
Bluesky fixed the account portability on federated network problem, look at their docs - your post history and everything can come with you when you change instances