So, I’m new to the fediverse and Lemmy, and I’m still trying to wrap my brain around it all. I’m sure people have talked about this, but by far my biggest issue so far has been finding communities. I specifically didn’t want t to join a large instance, but that has led to issues of finding communities. I often need to go to lemmy.world or lemmy.ml and search for communities there because searching on a smaller instance won’t yield results if no one’s subbed to that community, even if the instances are federated.

Which leads to the point I’m trying to get to. It feels almost to me like if I’m trying to search for a URL but the DNS says it doesn’t exist because no one on that DNS tried accessing that URL before so I need to query another DNS for it. But in reality, if I ask my DNS for a URL, if it doesn’t know it, it’ll ask other DNSs in turn until a result is determined. Why can’t something like this exist for searching for communities? Does something like this exist at all, or is it impossible / a limitation of activity pub? But I feel searching for a community in one instance should in theory, if it doesn’t know that community yet, be able to query federated instances if they know, until a result is returned.

Apologies if I’m unintentionally beating a dead horse. Or if there was a better community to post this to other than this one. See aforementioned community finding issues, lol.

  • shagie@programming.dev
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    This isn’t quite right. There is no central list that gets replicated. There is instead a set of delegated authorities. That top most delegated authority may be revoked with repercussions down the chain.

    There is no list that has every name in it. If you resolve test.127.0.0.1.nip.io its not going to a central list but rather finding out who is responsible for .io and asking that server if it knows where test.127.0.0.1.nip.io is. Getting a ‘no’ back from the registrar for the country code, it then asks where it can get that information and finds that it should ask ns1.nip.io or ns2.nip.io. The system then asks one of those servers if it knows the address that test.127.0.0.1.nip.io has and that server responds back “yes” at which point the DNS server that you asked may cache the result.

    nip.io also demonstrates that anything that you ask for can be there and thus a central list is impractical. app.10.23.45.67.nip.io works just as well.

    You can say that delegated authorities isn’t federated… ok… but its not a central list that everything replicates and working any censorship of the name can be as easy as finding a DNS server that is serving it. Though again, everyone likes using the big central ones rather than hosting and maintaining their own.