| That's actually a fantastic idea, and I assume that the main barrier to implementing this isn't a technical one, but the coordination problem of getting enough instance admins to opt-in to appearing on this system, and finding some neutral third party to maintain it (potentially the same people as run this instances.social site). Splitting your user story into smaller tasks, it seems like the technical side could be implemented as follows: - An agreed API / JSON format / microformat for instances to list the top 3 user interests that distinguish them from other instances (ideally using Wikidata Q identifiers[0], to create a consistent cross-language taxonomy) and maybe a paragraph of text to give a fuller description of the community - An agreed API for checking whether a username is already taken on an instance (and maybe a standardised query string format supported by each instance, which allows a third party site to send their visitor to that instance in such a way that the visitor is presented with a sign-up page where the username box is already filled) - A site with a neutral domain name like "join the fediverse . party" (or just re-use instances.social if that's catchy enough), with the UX you describe - A way for new instance admins to submit their instance for inclusion (which triggers some automated checks like "is this instance online?" and "which parts of the fediverse does it federate with?") Actually the hard part is probably preventing Sybil-attacks, since some attacker could create millions of dummy instances that have only one user on (though the instances will no doubt lie and claim to have billions of users). Maybe there does need to be some cabal or union of instance admins who can be trusted to give estimates for how many genuine users are probably on the smaller instances they federate with (reporting "0" or "negative infinity" for instances which they block). [0] https://www.wikidata.org/wiki/Q43649390 |