Let's talk about "(D)DNS" and Reticulum/LXMF #965
Replies: 12 comments 26 replies
-
|
With the prototyping and experimentation I've done, what has made most sense in this regard is to turn the domain directionality around, so you always have a trusted root resolver first, instead of last. In Internet DNS, TLDs are the ultimate trusted root resolvers. In RNS, you'd have something like:
This kind of scheme works without any centralization, but it is not deterministic at all. Depending on who you ask, that can either be a fantastic or a horrible thing. Personally, I think it is fantastic - and it's the way I've been planning to implement it. A scheme like this allows you to traverse paths of name lookup instead of having one rigid scheme imposed that requires complete centralization, while still getting a name-mapping system that makes sense to humans. It also allows complete personal control and can be efficiently managed by individuals or communities, and everyone is free to choose the resolver paths they want. It can also be implemented very efficiently over Reticulum in a completely permissionless manner, and would even support arbitrary registration from users that don't want to run their own resolvers. Hopefully, one of these days, I'll actually get the time and resources to implement it. I'd say most of the architecture of that kind of system running over Reticulum is worked out, including how to tie it all into the existing ecosystem, but it's gonna be a hell of a lot of work to write, test and integrate everything. |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea of turning existing paradigms on their heads. That said, I'm having trouble mapping the system I think I'm hearing described onto some of the key user stories that I think are implicit. Maybe we can make some of those stories explicit. (Hopefully other folks will chime in to help flesh these out too!) Table Stakes (IMHO) - i.e. parity with the InternetS01: As a potential viewer of a NomadNet page or as a potential NomadNet chat participant, I want to find "links" to NomadNet resources in the wider world (possibly in places that can't change easily - like printed material) and have reasonable confidence they go where the author meant for them to go. HarderS07. As the operator of a Nomadnet resource, I want it to be reasonably cheap to author a "link" that is meaningful/memorable to potential users. Really HardS08. As a user of NomadNet, I want the infrastructure that powers these "links" to be distributed and censorship resistant. |
Beta Was this translation helpful? Give feedback.
-
|
As an illustration of some of the opportunity represented by S06, let's look at the URL of this discussion compared with the "link" to the NomadNet page for "RNS Dublin": 54 characters and we delegate our trust in the first 18 characters - 8 of which are the protocol. The portion where we delegate our trust is human readable and the user can focus on just 6 characters which are pronounceable and English words. (Albeit "git" is used in a jargon form that is only meaningful to the target audience.) 62 characters and we delegate our trust in the first 47 characters - 15 of which are the protocol. The portion where we delegate our trust is (basically) not human readable. |
Beta Was this translation helpful? Give feedback.
-
|
Building on the Petnames paper (assuming that's pretty close to what @markqvist was proposing), I think it is helpful if we break up my user stories into 3 separate problems: 1. Human readable names (Pretty much all the user stories except S05 and S07)The Petnames system only directly solves this one, but is a pretty elegant approach. One could even argue is solves an inherent scalability problem with the existing Internet DNS system since most things don't actually need globally unique names. 2. Indirection (S05)Maybe indirection should be addressed (bad pun) completely separately. @markqvist How feasible would it be to handle some of the indirection needs directly at the protocol layer? e.g.
3. Brevity / Accessibility (S07)There are some technical and some social opportunities here. On the technical front, one of the lowest hanging fruits would be picking a shorter protocol prefix instead of Another technical opportunity (IMHO) would be picking a delimiter that is a simple ASCII character. The On the social front, such a system should propose conventions for regional and virtual communities to use for naming their "well known directories" and bootstrapping trust in such directories. In most cases this would just involve using an existing communication channel or physical location to publish the recommended short acronym, custodian identity, and public key for the directory. e.g. A local "Windy Valley Farmer's Market" might include a QR code in their monthly flyer and put up posters each market day that include their directory information which allows the various vendors' pages to be easily looked up by customers "rns://wvfm.joes-organic-eggs:/farmstands.mu". Of course anyone could choose to host a DNS mirror registry and support pointer mechanisms like a DNS TXT record |
Beta Was this translation helpful? Give feedback.
-
|
I took a look at the NomadNet and MeshChat implementations and it seems like both make some pretty strong assumptions about the format of "links" typed in by the user or rendered in Micron pages. This means there's no abstraction where those clients ask Reticulum or LXMF "hey resolve this link for me", instead they get into the weeds with checking that the destination hash is hexadecimal and the right length, etc. That in turn means that an implementation of a DNS analogue for the Reticulum ecosystem would require non-negligible changes in every client that can display pages. That's not necessarily a bad thing, but I think it's helpful to capture that scoping information explicitly here. Of course an implementation like the Petnames paper proposes would also require additional UI features for managing one's own directory of pet names and for approving or choosing resolutions. |
Beta Was this translation helpful? Give feedback.
-
Proposed Goals for Mapping Petnames Onto the Reticulum Protocol:Note: I'm using the terms "Petnames system" and "petname" to reference this DNS analogue system for lack of an official term which obviously is TBD. G01. Reticulum instances can choose to use a petname for any identity regardless of the nature of that identity or whether it in turn also uses the petnames system. G02. Petnames should work with intermittent/unreliable connections and - whenever possible - avoid "request time" petname resolutions - i.e. chained petnames references should usually work even when intermediate names in the chain aren't necessarily "online" at the same time. G03. Using chained petnames references should involve minimal trust in the intermediate identities and should ideally leak as little information as possible about what the actual chain being followed is. G04. Names can be added, removed, or changed at any time by a Reticulum instance using the petnames system and in most cases should not require manually managing expiry/TTLs. G05. Reticulum instances can choose to use a petname for any identity without publishing that name/decision as part of their public petnames directory listing. G06. Reticulum instances can choose to use a different name for an identity in their public petnames directory listing other than what it is called in their private petnames. G07. Public petnames directories should scale to at least hundreds of thousands of entries. G08. Public petnames directories should be able to be used by an unlimited number of Reticulum instances without creating a performance bottleneck and with a reasonable amount of overall network bandwidth usage. G09. Support an intermediate "limited directory mode" between completely public and completely private. As in the pet names paper, allow for limited peer-to-peer name sharing (e.g. of contacts) without as strong of scaling requirements and without the assumption that those names are totally public. |
Beta Was this translation helpful? Give feedback.
-
General Observations
Hashed Sharding SchemeIf we support very large diverse public name directories, we should support resolving names from those directories without leaking to the directory or the larger network what names are being requested. To give an example of why this is important: Suppose that Alice wants to blow the whistle on bad practices at Acme Corp. She should be able to separately manage two of the risks involved when using a public directory to find a known respected journalist; 1. that the returned identity of the journalist to whom she hopes to speak is actually that journalist 2. that her action of looking up the journalist will be correlated with the subsequent story and be used to reveal that she is likely to be the source. The first needs to be solved separately, but Alice should have plausible deniability regarding the second built into the protocol. Another example: Suppose the Bob lives in a company town with a company provided network access and uses the company directory as a first step in resolving the path In both of these two cases, the hardest thing to protect against is collusion between the directories operator and the entity that might punish Alice or Bob for their actions. The simplest way to provide this pluasible deniability for most cases is to just request the entire contents of every directory involved, however that is clearly innefficient and would break beyond certain directory sizes. I haven't figured out the exact mechanics, but I propose that there is probably a way to request hashed shards identifier prefixes - either directly from the directory or from cached data propagated to nearby nodes - where the amount of hash prefix shared is dynamic on the basis of the size of the directory and possibly the desired secrecy/performance of the request. Looking forward to ironing this idea out further... |
Beta Was this translation helpful? Give feedback.
-
|
It's also possible the goals above are too ambitious. Another much simpler strategy would be to assume that one should only use petnames directories that you trust (not to leak what you're requesting) for the purpose you're using them for. If we did that and used a request-time + caching strategy like the Internet DNS system uses, this would be much more trivial to implement. |
Beta Was this translation helpful? Give feedback.
-
|
I've created a partial prototype and a modified version of rnx for us to try out : ddresolve : https://codeberg.org/skyguy/ddresolve It only implements local resolving, but it is already useful to save pasting those long hashes! -Kevin |
Beta Was this translation helpful? Give feedback.
-
|
Hello, would you like to share your thoughts on this? |
Beta Was this translation helpful? Give feedback.
-
|
Welcome to the discussion! Glad to have more people thinking about this. I think the path and attribute parts of your proposal are unnecessary since they are already known by the application resolving the name. For example, when you run: Identifying the protocol has to be done earlier in the process - when you click on a URN, that code has to identify which program to run, then pass the URN to it. So you need something like Existing software understands that The Resolver Protocol itself doesn't really need a defined URL format as it isn't user-facing - people won't see or click on rnrp://... They will click on [1] The '//' is an unneeded part of HTTP URLs since the protocol identifier is already terminated by the colon. Tim Berners Lee said that he regretted making it part of the standard, since it was ugly and people didn't like having to type it! Discussions around the HTTP/2 protocol were thinking about switching to 'h2:example.com' as the URL format, but eventually decided to just make it invisible instead. |
Beta Was this translation helpful? Give feedback.
-
|
I've just uploaded a new version of the https://codeberg.org/SkyGuy/petnames I've also posted modified versions of https://codeberg.org/SkyGuy/rnsh So you can now run Try it:
Let me know what you think! It's still local-resolving only, but distributed resolving is much closer now. The API shouldn't need to change to add distributed resolving. -Skyguy |
Beta Was this translation helpful? Give feedback.


Uh oh!
There was an error while loading. Please reload this page.
-
So I've been playing with Reticulum/LXMF, skimming the discussions here, and trying to grok the larger "let's (eventually) replace the existing centralized Internet infrastructure" strategy.
One thing that seems pretty obvious to me is that RNS needs some sort of name system as a layer of indirection on top of the current RNS addresses.
It took many years (arguably decades) for the larger populace - not just techy folks - to get comfortable with the typing in domains and urls (or navigating them in other content/contexts), but now that people (mostly) know what to expect from that interaction it is part of the "design language" that can be leveraged to make any network technology more user friendly.
Simplified names provide many advantages:
They also come with some very serious disadvantages:
I don't have a solution here, but I wanted to start a new thread since there's some related ones but I didn't see one specifically on this problem.
A few observations/thoughts?:
Beta Was this translation helpful? Give feedback.
All reactions