Though the main point of DNS is it manages a namespace, and you wouldn't want clashes, so websites would probably have to have urls like thttp://{some 64char hash}/
(Where the h stands for telehash...
i.e. Map from something user friendly (e.g. username) to a SHA1 hash?
[...]End: a SHA-1 hash key (40 hex characters, 160-bits) stored in the global DHT and distributed between switches. Switches will distribute and look up ends in the global DHT that are important to them. TeleHash defines the SHA-1 hash of the external IP:PORT of a switch as part of the protocol. Applications built on top of TeleHash can add their own ends to the DHT like hashes of files, hashes of e-mail addresses or hashes of other application-specific values (e.g. user@chat).[...]
So if i understand this right, every packet has a protocol-defined +end and the application can add it's own end on top (i.e. an Email adress?).
https://github.com/quartzjer/TeleHash/wiki/My-Understanding-...
For example, if you have a decentralized social network that is based on the same software, say "facespace", every of those software nodes would lookup for the same identifier. i guess...
{ "facespace":"arethuza" }
User A wants to send and receive messages with user B. Both are identified only by their IP and Port pair. User B does not know of user As intentions. So user A send switch C an UDP packet asking for "hole-punching". Switch C has this service where users behind NAT routers connect and signup to be contacted when someone wants to "hole-punch" to them. Switch C sends a packet to B with info about A. B sends A a packet and Bs router is now expecting packets from A. Has soon has A sends its first packet to B its router is open for packets from B. Now both A and B can send packets to each other without C.
DNS is not yet entirely out of the loop. The main switch for telehash is telehash.org:42424