Our website is made possible by displaying online advertisements to our visitors.
Please consider supporting us by disabling your ad blocker.
Please consider supporting us by disabling your ad blocker.
OpenSimWorld is the directory of 3D Virtual Worlds based on OpenSimulator and connected through the HyperGrid. Learn More
New Members
Old Gmail , OutworldzOfficial, EmmaStoned, Pvaacc, NexVerse, Yana_Dakota_Author, MiaAraBella, EcTeTkA, SpykerXenno, Laeliarainbow, Magick Caudron, Isabelle_Jeannette, OberonDiastima, Jackkelso, DreamFantasy, Pvausasmm166, Johan_brekke, Pvausasmm144, Lendario2026, CreekmanblueditkoLikes
UUID-home-grid lookup table, as a Kademlia DHT
Discussion for grid owners and HG enthusiast.
Just wondering how many would love to see this implemented for their sims grids.
One of the issues I find with HG is that most of the time the viewer only sends the UUID of an avatar or a group, and not the grid:port. The sim has a lookup table, but if that UUID has never been seen on this grid it has no way to find its home grid. The viewer may or may not have that info; in any case it does not send it.
Current workarounds are a look up table of visitors, to look at the last message to retrieve the grid info, creator info, leftover GridUser rows, and so on. That is not always possible. My understanding is OpenSim wanted to stay as compatible as stock SL / Firestorm as possible, so I am not discussing the option of having the viewer send these fields to the sim.
The idea that has been in my head for a while is to implement a distributed hash table of avatar and group UUIDs and their home grid:port. The DHT can be implemented with the Kademlia protocol. It was used in Kazaa, eMule’s Kad network and on BitTorrent’s Mainline DHT, Kazaa and the Kad/eMule side is the well-tested. There are C# libraries that already do this, Alethic.Kademlia, kademliath, dht-csharp, so we do not have to write the routing from scratch.
Each participating grid becomes a node in the DHT and seeds its own UUIDs and grid URL. Other grids can query the network to find where to request a profile or send an IM.
About privacy
No avatar information is sent to the DHT, no profile, no online status, no group info. It only says this number belongs to that grid. The grids still have full control to deny a profile request, an incoming message, and so on. So grid admins are in control of their resident privacy.
Assets are not included in the network. They are not needed. The unknown-grid problem is profiles, groups and IMs.
Resources
Just a UUID → grid:port (plus a signature) takes little space. Ballpark 100–200 bytes per record. 1,000,000 UUIDs may be in the low hundreds of megabytes for the whole overlay, and those are distributed across all nodes, so expect something like tens of megs per node even for tens of millions of UUIDs.
Bandwidth is little. A new UUID only needs to be seeded on account creation. UUIDs are immutable so there is no update. Once a day the grid can inform of deleted accounts or other housekeeping (URL change, tombstones).
Security
Records are signed. Only the grid that created the UUID can update or delete it.
I am not worried about “someone published this UUID first, now I cannot use it.” Grids mint their own UUIDs. If a number is already sitting in the DHT, you just create another one that belongs to you. The mapping is not a reservation of identity, it is only a pointer for lookups.
Kademlia and the libraries already take the usual overlay attacks into account, at least at the protocol level:
* Sybil: one operator spinning up many fake nodes
* Sibling / eclipse: crowding a target’s routing table so lookups only hit attacker nodes
* Prefix hoarding: parking nodes so you own a slice of the key space
* Routing-table poisoning: feeding bad contacts
* Churn / flood: join/leave or store spam to wear nodes out
While I am writing this I think it can later be expanded to include land / region search. Same overlay, different key type. Not needed for v1.
Making OpenSim actually a decentralized metaverse
This unknown UUID thing affects mainly Standalones sim and mini-grids, with residents they spend most of their time out on the HG, and most of their visitors are HG visitors. But in general a shared lookup helps the small less popular grids as much as the large ones.
https://github.com/amandaleeang/OpenSim-Aura/discussions
Just wondering how many would love to see this implemented for their sims grids.
One of the issues I find with HG is that most of the time the viewer only sends the UUID of an avatar or a group, and not the grid:port. The sim has a lookup table, but if that UUID has never been seen on this grid it has no way to find its home grid. The viewer may or may not have that info; in any case it does not send it.
Current workarounds are a look up table of visitors, to look at the last message to retrieve the grid info, creator info, leftover GridUser rows, and so on. That is not always possible. My understanding is OpenSim wanted to stay as compatible as stock SL / Firestorm as possible, so I am not discussing the option of having the viewer send these fields to the sim.
The idea that has been in my head for a while is to implement a distributed hash table of avatar and group UUIDs and their home grid:port. The DHT can be implemented with the Kademlia protocol. It was used in Kazaa, eMule’s Kad network and on BitTorrent’s Mainline DHT, Kazaa and the Kad/eMule side is the well-tested. There are C# libraries that already do this, Alethic.Kademlia, kademliath, dht-csharp, so we do not have to write the routing from scratch.
Each participating grid becomes a node in the DHT and seeds its own UUIDs and grid URL. Other grids can query the network to find where to request a profile or send an IM.
About privacy
No avatar information is sent to the DHT, no profile, no online status, no group info. It only says this number belongs to that grid. The grids still have full control to deny a profile request, an incoming message, and so on. So grid admins are in control of their resident privacy.
Assets are not included in the network. They are not needed. The unknown-grid problem is profiles, groups and IMs.
Resources
Just a UUID → grid:port (plus a signature) takes little space. Ballpark 100–200 bytes per record. 1,000,000 UUIDs may be in the low hundreds of megabytes for the whole overlay, and those are distributed across all nodes, so expect something like tens of megs per node even for tens of millions of UUIDs.
Bandwidth is little. A new UUID only needs to be seeded on account creation. UUIDs are immutable so there is no update. Once a day the grid can inform of deleted accounts or other housekeeping (URL change, tombstones).
Security
Records are signed. Only the grid that created the UUID can update or delete it.
I am not worried about “someone published this UUID first, now I cannot use it.” Grids mint their own UUIDs. If a number is already sitting in the DHT, you just create another one that belongs to you. The mapping is not a reservation of identity, it is only a pointer for lookups.
Kademlia and the libraries already take the usual overlay attacks into account, at least at the protocol level:
* Sybil: one operator spinning up many fake nodes
* Sibling / eclipse: crowding a target’s routing table so lookups only hit attacker nodes
* Prefix hoarding: parking nodes so you own a slice of the key space
* Routing-table poisoning: feeding bad contacts
* Churn / flood: join/leave or store spam to wear nodes out
While I am writing this I think it can later be expanded to include land / region search. Same overlay, different key type. Not needed for v1.
Making OpenSim actually a decentralized metaverse
This unknown UUID thing affects mainly Standalones sim and mini-grids, with residents they spend most of their time out on the HG, and most of their visitors are HG visitors. But in general a shared lookup helps the small less popular grids as much as the large ones.
https://github.com/amandaleeang/OpenSim-Aura/discussions
Comments
No comments yet