Here's something I never seem to get a clear picture of, with these federated options. The typical explanation that makes the concept easy to understand is that federated services are "like email, we can have different providers, e.g. you might have a gmail account and I might have a yahoo or outlook address, and we'd still be able to communicate".
I think that's a very good way to put it, but the issue is that with email providers most users have an account in a company that is well established and its future continuity is not in doubt, at least in a span of months or couple years. And even if yahoo happened to close their email service, there are good software solutions that are mature and can be easily found and used to move your emails from one IMAP address to another.
Now, with federated options, I see all these funny looking domaim names, which I'm sorry but to me they scream "I'll be gone by next week (or month or year)". In general, apart from the most prominent federated instances -those that typically belong to the creators or are endorsed by them-, there is a lot of small instances that don't transmit a lot of confidence in their long-term existence.
And I get it, these are hosted mostly by users of the network. But the thing is that I'm a user, not a sysadmin. I have enough work already at work, and for this kind of use I'd really like to not worry about hosting a service by my own (especially after seeing this list of requisites! [0]) or that the instance I chose 6 months ago is now disappearing without notice. Are any fediverse implementations working on this issue, such like promoting an instance rating / trust system, or something like that? Apart from, of course, tooling to make migration a one click process.
[0]: https://docs.pixelfed.org/running-pixelfed/prerequisites.htm...