> How do you envision the DHT being updated and not being blockchain based?

By being a DHT, not a blockchain? There are many ways for permissionless updates, such as those employed by BEP-44 on mainline DHT (BitTorrent - not blockchain based), IPNS (part of IPFS - also not blockchain based).

I don’t really care about the downvotes - I just want people to comment why, because I’ve said little that isn’t true.

What would you do about sybil attacks?

> because I’ve said little that isn’t true

You have said more than you realize in how you phrased the sequence of questions, and regardless of truthiness or not, they come off as combative.

Another commenter has pointed you towards a discussion where you can find conversations on these topics

> What would you do about sybil attacks?

There are lots that have been done to reduce the impact of Sybil attacks on all major DHTs - deterministic node ids, replication, signed payloads, key abuse detection and mitigation, iterative lookups through trusted nodes, etc.

Those complications are why Bluesky chose something simpler for the PLC that gave them the features they needed given the resources they have available to manage this part of the protocol and infra.

Again, and as I said, DHT resolution is just one of many options.

As for “the complications”, those “complications” are just software - as implemented in dozens of libs - and already running on hundreds of thousands (if not millions) of nodes on some of the larger DHTs.

The “features” they needed were equally solved with did:web using plc.directory - which could absolutely be backed by the PLC transparently.