The idea of having several instances is an architecture choice. Instead of having all the users and content served by a single monolith, the users and the content are spread around several instances that then talk to one another in the process called federation to serve that content for other instances.
This spread out architecture allows for lesser hosting costs per instance and if an instance goes down it does not mean the entire service goes down as a whole. You may experience technical difficulties on one instance while the rest are completely fine, just unable to get stuff out of the instance. Additionally, it allows for easier moderation as moderators (admins?) are instance specific. You don’t have to moderate the whole of Lemmy, keeping your own house clean is enough. This means you are likely to have a higher ratio of mods per users with more instances, which leads to better quality in moderation work. Then if some other instance is not behaving, stop federating from them to yours.
And then some. I hope this at least explains some of the design choices at fediverse?
Sen perusteella mitä on nähnyt siitä mihin kaikkeen dataan Threads-sovellus pyytää pääsyn niin ei tarvitse kahdesti miettiä. Kun kerran koko soppa on jo muutenkin ActivityPub:n avulla saavutettavissa niin jos akuutti tarve ilmenee etsin käsiini Mastodon instanssin joka ei ole näitä jo defederoinut.