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.
Instead of defederating whole servers, I would like admins to have an “opt out” or “un-default” button, then each user can browse the list of servers that have been opted out and individually opt in again instead of having to move their username to a different server.
I would grudgingly accept having the ability to op-in to “problematic” instances or communities. As long as I’m not denied any functionality. It’s an acceptable compromise.
That’s much better than opt out, the default shouldn’t direct you to hateful communities
this
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