Let's talk about "(D)DNS" and Reticulum/LXMF

[symbioquine]

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 can be more trivially verified/compared by humans
• They can convey meaning
• They can be shorter and less error-prone than hexadecimal addresses

They also come with some very serious disadvantages:

• They will always be an exercise in some sort of centralization/trust (as far as I can tell)
• They can become contentious/valuable
• They add a layer of latency/infrastructure/failure-points involved with their propagation/lookups/updates/etc

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?:

• ".rns" is not currently a TLD in the Internet DNS system - could we leverage a similar strategy to how TOR uses ".onion"?
• If a name system necessarily involves some form of trust/centralization, how can we align incentives so whatever short-term solution we find benefits the network along the way - without becoming too big of a crutch, "too big to fail", or an unnecessary target for government censorship/control?
• Am I missing something? Is there a truly distributed way to build a human-centric name system?

[markqvist]

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:

my_own_home.that_guy_tom.the_server_under_his_couch.whatever_that_thinks_this_node_is

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.

[markqvist]

Also, as a side note, that system would resolve identities, not addresses like in the traditional Internet. That means you can resolve the Reticulum identity for a name, and the use that to find all the relevant destinations you want, such as the LXMF address, a page-serving node address, an rncp file drop, or whatever else you'd want. That's a lot more elegant, I'd say.

[markqvist]

A while back, I thought I'd have time to do the implementation, but unfortunately the rnir tool is still left at the scaffolding. One of these days...

[kegsay]

This description sounds exactly like petnames. I'm not sure how useful the names/trust would be beyond a few hops, but in smaller mesh networks it seems like the obvious choice to me.

[symbioquine]

Thanks for sharing that @kegsay !

[symbioquine]

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 Internet

S01: 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.
S02. As that same actor in possession of such a "link", I want to be able to share it with other actors and have it also go to the same place it went for me.
S03. As an actor to whom a NomadNet resource "link" has been shared, I want to be able to identify whether it has been subtly modified to go to a malicious location.
S04. As the operator of a NomadNet resource, I want to author a "link" and have reasonable confidence it will go where I meant for it to go.
S05. As the operator of a NomadNet resource, I want to author a "link" with a layer of indirection such that I can change the hosting for that resource later - e.g. to move it to a less busy server or one with a better/different network connection while leaving the original server still in place doing its other jobs.
S06. As the operator of a NomadNet resource, I want to author a "link" that is as concise/short as possible to facilitate use-cases like easily scannable QR codes, links shared verbally, better accessibility for impaired users, etc.

Harder

S07. 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 Hard

S08. As a user of NomadNet, I want the infrastructure that powers these "links" to be distributed and censorship resistant.
S09. As a user of NomadNet, I want to control the amount of legal risk I incur by participating in the mechanism that makes these "links" censorship reistant.
S10. As a user of NomadNet, I want to control the degree to which I participate in making "links" - e.g. to material I consider unethical - available.

[symbioquine]

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":

• https://github.com/markqvist/Reticulum/discussions/965
  

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.)

• nomadnetwork://abb3ebcd03cb2388a838e70c001291f9:/page/index.mu
  

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.

[symbioquine]

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.

• Create an identity hash that is actually a lightweight pointer to another and which can be cheaply updated?
• Avoid the need for supporting DNS round robin by supporting some form of cheap proxies - so nodes can load balance for each other?
• ...Are there other indirection needs?

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 nomadnetwork://. Of course nomadnetwork:// can still be supported for concrete identity references, but perhaps it would make sense to pick a 3 or 4 letter one - e.g. rns://.

Another technical opportunity (IMHO) would be picking a delimiter that is a simple ASCII character. The ⇒ character that Petnames proposes takes 3 bytes to encode and does not appear on a typical keyboard. This means it would yield larger/harder-to-scan QR codes and be harder to type. There's also more ambiguity since there are a quite a number of other unicode arrows to get it mixed up with. I suspect things like screen-readers will also tend to have more trouble with less common characters.

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 TXT nomadnetwork=f8ac9c41b857ddf13a9151cec211079b DNS record or a Well Known URI https://betweentheborders.com/.well-known/reticulum.json file with {"nomadnetwork": "f8ac9c41b857ddf13a9151cec211079b"} in it - allowing rns://dns.betweentheborders.com:/pages/index.mu to work as expected.

[symbioquine]

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.

[symbioquine]

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.

[joakim]

The way I've been thinking about representing these, the left-most term is the first one - i.e. the name of the first path segment which is the name that the user has actually directly entered in their petnames "address book".

Absolutely, foo would be defined by me in that example.

I worry about too aggressive/permanent of caching creating unforseen problems. i.e. it might be possible to end up with a poisoned cache

This definitely needs some serious thought because the consequences (including security ones) might not be super obvious...

Good points!

I do see the need to be able to change which identity a petname resolves to, which does complicate things. TTL is an obvious option. One could also broadcast any changes to (public) petnames, combined with a longer TTL, possibly reducing network chatter?

A way to surface petname changes to the user sounds like a good idea, as well as when petnames expire without being successfully re-resolved.

Shower thought: An identity can have multiple paths leading to it. If we model that as a graph, with identities as vertices/nodes and petnames as edges/links between them, one could easily find alternative paths to an endpoint if one should break. Finding the shortest path to an endpoint would be trivial (BFS if unweighted, Dijkstra/A* if weighted). It would create a map of known named identities on the network and how they are interconnected, which would be both cool and useful to visualize. Storing petnames as a graph might help prevent or solve some of the issues we're discussing. It doesn't have to be Neo4j, a lightweight in-memory graph database should do the trick.

[skyguy]

(Replying to multiple messages)

1. Should petnames be _constant_?

They are as constant as you want them to be - they're on your machine and will stay there until you change or remove them. Similar to browser Bookmarks.

2. Should petnames be _mutable_?

Definitely. If I want to rename "Jen" to "Wife" the system must support that.

I suspect that link rot is inevitable.

Always. As you say, servers come and go. However, you can always save a resolved name to a new PetName so that you will always have it.

I don't think long chains of names will be a thing, since they are only relevant to one device. I think there will be a lot of banners on NN sites saying 'Click here to create a PetName for our Directory'.

Once you've found a service you want to use again, you'll assign a PetName and never need to contact the Directory again (since Reticulum Destinations can be moved to a different server without having to change DNS records, certificates, etc.)

[symbioquine]

Shower thought: An identity can have multiple paths leading to it. If we model that as a graph, with identities as vertices/nodes and petnames as edges/links between them, one could easily find alternative paths to an endpoint if one should break. Finding the shortest path to an endpoint would be trivial (BFS if unweighted, Dijkstra/A* if weighted). It would create a map of known named identities on the network and how they are interconnected, which would be both cool and useful to visualize. Storing petnames as a graph might help prevent or solve some of the issues we're discussing. It doesn't have to be Neo4j, a lightweight in-memory graph database should do the trick.

This needs a lot more thought since as you say, the full path only needs to get "re-resolved" if both the path is broken and the endpoint identity has gone away - or maybe if it has changed in a user-hostile way.

In that case, we would need some sort of user interaction or social aspect since otherwise it (the naive implementation) might be vulnerable to a consensus attack where the attacker sets up a lot of paths to the same (popular) destination before that destination changes and then when it changes, they use their position as "alternate paths" to take over that name in a lot of folks' personal petnames directories.

I'm a little nervous about getting too fancy with graph algorithms - at least to start.

Like you mentioned, hopefully identities being fully portable (between devices and physical locations) solves a lot of the use-cases where the current DNS is currently used to plaster over IP addresses changing hands or not being portable between data centers etc. However, I still think there might be an argument for creating a layer of indirection in the core protocols of RNS so that destination identity can be decoupled from "responder identity" - i.e. the same way certificates are portable/duplicable between servers in the current internet infrastructure. This enables the scenario where the responsibilities of one server should be able to be split out between two servers without apparent interruption of service for the client. Of course, without that indirection we might just say that a best practice is to use very fine-grained RNS identities for each "unit" of functionality in a system - even within a single logical software system.

[skyguy]

Like you mentioned, hopefully identities being fully portable (between devices and physical locations) solves a lot of the use-cases where the current DNS is currently used to plaster over IP addresses changing hands or not being portable between data centers etc. However, I still think there might be an argument for creating a layer of indirection in the core protocols of RNS so that destination identity can be decoupled from "responder identity" - i.e. the same way certificates are portable/duplicable between servers in the current internet infrastructure. This enables the scenario where the responsibilities of one server should be able to be split out between two servers without apparent interruption of service for the client. Of course, without that indirection we might just say that a best practice is to use very fine-grained RNS identities for each "unit" of functionality in a system - even within a single logical software system.

That's a good point - to achieve something similar to a current bookmark, the client software should store the NamePart from the final directory lookup, rather than the resulting DestinationHash. So if we lookup
Business Directory.The Co Op.nnsite
and decide to bookmark that site, the client software should save The Co Op.nnsite and the address of the directory service The Co Op. That way, The Co Op can change their entry for nnsite when they need to, and customers will look it up each time.

Damn. The implementation I was thinking about just got another bit harder!

[symbioquine]

Damn. The implementation I was thinking about just got another bit harder!

Which is why we're talking through all this stuff before investing too much in what the code would look like. ;)

That's a good point - to achieve something similar to a current bookmark, the client software should store the NamePart from the final directory lookup, rather than the resulting DestinationHash. So if we lookup
Business Directory.The Co Op.nnsite
and decide to bookmark that site, the client software should save The Co Op.nnsite and the address of the directory service The Co Op. That way, The Co Op can change their entry for nnsite when they need to, and customers will look it up each time.

There's definitely something to that! I wonder if it would make sense to write up some user stories around that strategy? e.g. I'm thinking about how that idea translates to shared/persisted paths like those on printed media/QR-codes, or shared via text channels.

What if the tooling supports resolving longer paths and finding matches for the last two segments transitively, but the UX of the tooling steers folks toward only sharing two segment paths - directory-name.thing-being-linked-to?

[symbioquine]

General Observations

• Chained petname resolution is only possible when intermediate named identities also themselves use the petnames system
• To support semi-offline name resolution - and to reduce the information leaked to directories - public directory listings should be propagated somehow
• To support just-in-time name resolution it should also be possible to request names from a directory or from others that have cached said directories listings
• To avoid leaking information about the exact name being requested from large directories or caches thereof, we can implement a hashed sharding scheme - see below
• There is however, no way to avoid leaking some information when resolving paths unless one goes to the extreme of only passively listening to propagated directory listings and storing everything needed to resolve paths locally
• To support caching propagated public directory information without it being susceptible to modification en-route, the propagated information would need to be signed somehow
• To support caching propagated public directory information without stale/invalid directory listings being maliciously returned from caches, the timestamp/ttl of the propagated information would need to be captured within the signed portion.

Hashed Sharding Scheme

If 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 acme-mining-town.nearby-town-biz-directory.miners-union. Bob should be able to get the identity for the Miner's Union with plausible deniability about what he looked up that is increasingly strong the larger the directory is. e.g. if nearby-town-biz-directory only contains one entry, the risk is pretty high that any node involved in resolving the request will be able to guess that Bob is trying to unionize. However, if the directory contains hundreds or thousands of entries it should start to become plausible that he was trying to look up things like ...nearby-town-biz-directory.freds-haircuts or ...nearby-town-biz-directory.martys-saloon.

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...

[symbioquine]

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.

[skyguy]

I've been following the GNUNet development for many years, hoping it would reach a usable state, but so far it hasn't. Even once it does, I don't feel it's a good fit because:

1. GNS continues the wrong-way hierarchy of NameParts as used by DNS - I agree with Mark that the leftmost name should be a local one.
2. GNS is (currently) integrated into the gnunet daemon system, so requires running additional software
3. GNS uses a database instead of simple files, making maintenance and longevity harder.
4. gnunet is written in C, which makes writing secure networking software difficult and makes cross-platform installation more difficult.

[joakim]

I was going to say "Why can't we just use the local part of the GNU name system (GNS) as-is?" a few days ago, then I thought of some of the reasons @skyguy listed :)

Like @skyguy, I don't think it's a good fit for Reticulum. In general, I'm not sure DHT is the way to go, as it can still be centralized to some degree, and defending against Sybil attacks is still an open research topic. I wish them luck though, the more alternatives we have the better.

I like the simplicity and localness of the "backwards" petnames scheme, I think it's definitely worth exploring further. Good to see that you're well underway already!

[joakim]

What you've described above sounds a lot like SSH aliases, only with distributed/chained lookup and local caching?

SSH aliases are defined in ~/.ssh/config, but petnames obviously need a separate file as it can grow very large. Something like ~/.reticulum/petnames? Wouldn't that be the right path?

As for the hard problem of naming things, I kind of like "petnames". It's more personal than "aliases", which implies anonymity. That said, "alias" is often the word used for naming things in computing. Or maybe just "names"? A named identity.

Anyway, that's bikeshedding :)

[symbioquine]

SSH aliases are defined in ~/.ssh/config, but petnames obviously need a separate file as it can grow very large.

You probably know this, but SSH aliases can be put in separate files if one desires by setting up ~/.ssh/config.d/myconfig.cfg files, but I also tend to agree about a different path. One reason being that I don't think overloading the functionality in ~/.ssh with even more critical stuff is a good idea.

As for the hard problem of naming things, I kind of like "petnames". It's more personal than "aliases", which implies anonymity. That said, "alias" is often the word used for naming things in computing. Or maybe just "names"? A named identity.

I'd lean towards something that's a bit more unique/searchable than "names" or "aliases" since those terms have lots of implementations to get it mixed up with.

[symbioquine]

Like @skyguy, I don't think it's a good fit for Reticulum. In general, I'm not sure DHT is the way to go, as it can still be centralized to some degree, and defending against Sybil attacks is still an open research topic.

I also think that's probably true. My question was mostly a devil's advocate kind of thing. Again probably not great to overload the functionality of a system designed to do such different things - even if we only leveraged the local part as my question suggested.

3. GNS uses a database instead of simple files, making maintenance and longevity harder.

I'm also a fan of some sort of plaintext file format to start - at least for a reference implementation.

[skyguy]

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

[symbioquine]

Wow cool. I look forward to taking a look at the code sometime soon!

[radio-miskovice]

Hello, would you like to share your thoughts on this?
https://github.com/radio-miskovice/ReticulumNameResolver/tree/simple

[lucarinaorg]

very nice, but does this sounds better in Julia (used also in Space applications)?
I show you a prototype:

``
using YAML
using Dates

const __config_files = String[]

push!(__config_files, "./rnsnames.yaml")
push!(__config_files, expanduser("~/.rnsnames.yaml"))

if Sys.iswindows()
push!(__config_files, expanduser("%PROGRAMDATA%\rnsnames.yaml"))
else
push!(__config_files, "/etc/rnsnames.yaml")
push!(__config_files, "/usr/local/etc/rnsnames.yaml")
end

global resolverdata = nothing

function __init_config()
for config_path in __config_files
if isfile(config_path)
return YAML.load_file(config_path)
end
end
return nothing
end

resolverdata = __init_config()

function resolve(destname::String)
if resolverdata === nothing
throw(RuntimeError("No configuration file found for RnsResolver."))
end

attribute = "dest"
destpath = nothing

if count(c -> c == ':', destname) == 1
    parts = split(destname, ':', limit=2)
    destname = parts[1]
    attribute = parts[2]
end

if count(c -> c == '/', destname) == 1
    parts = split(destname, '/', limit=2)
    destname = parts[1]
    destpath = parts[2]
end

names = get(resolverdata, "names", Dict())
entry = get(names, destname, nothing)

if entry === nothing
    return nothing  # Nome non trovato
end

if destpath === nothing
    return get(entry, attribute, nothing)
else
    subentries = get(entry, "/", Dict())
    subentry = get(subentries, destpath, nothing)
    if subentry === nothing
        return nothing
    end
    return get(subentry, attribute, nothing)
end

end

export resolve
``

[skyguy]

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: rnx myserver the rnx program is hard-coded to use rnx.execute as app_name and aspect and just needs to lookup the identity, so it can call resolve('myserver', 'id') and get what it needs. Trying to run rnx myserver/nomad:dest would fail as rnx doesn't know how to talk to a nomad service.

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 rnx:myserver (The // is not needed [1] )

Existing software understands that <space><protocolid>:<protocol-specific-stuff<space> is a URN which should be passed to the Desktop Environment to launch the software configured to handle that protocol.

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 nomadnet:aabbcc.../pages/index.mu. My thinking so far is the protocol could be as simple as sending a Reticulum Request for property<space>name and expecting a list of replies of the form : property=value.

[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.

[radio-miskovice]

Thank you for comments! I had a gut feeling I was kind of overdoing it. The version I drafted the day before this "simplified" version was even worse :) (it is in the "main" branch -> needs to be dropped).

I like the simplicity offered in your comments. A few more thoughts:

1. Regarding the program identification in URN (e.g. rnx:myserver) I am not sure how much necessary it is. Since the whole service would be just looking up identity for the name, it is probably not needed at all since the name resolution service would most likely never be called outside an application.
2. Regarding the idea of returning just the ID, I still have to go through Reticulum source code to understand if it would work when returning only the identity hash or if the full Identity object was needed. I need to go back to Destination and have a look how the destination hash is calculated. If the result had to be full identity object (by "full" I mean only the part containing public key, of course, not the complete set of keys), there might be some additional limitations, such as that the identity should already be known to the current Reticulum instance, so that if the resolver returns id hash, it should be possible to get the identity object from known identities. This is a very simple check in the source code but I am now not in a position to dig through. But I will have a look.
3. What if I just know the destination and don't want to guess appname + aspect? Typically, when trying to control remotely some kind of telemetry equipment or home automation, appname and aspect could be just anything one makes up? Let's say I take Request.py from examples and modify it to handle heating or lighting remotely. I can even imagine having a single program (e.g. HomeControlRequest.py) command line argument that would determine what kind of peripheral equipment to control and at the same time would use a different appname + aspect in order to generate unique destinations. Such as home.heating, home.heating.garage, home.lighting.1st-floor, etc. When being able to obtain only the identity I would need to know all aspects beforehand or include them in the name, like <appname>.<aspect(s)>:myhome. In fact I would perhaps prefer shorter names for local resolution only, getting destination and not caring about the aspects.
4. With regard to the previous point, if the service returned all the information at once in an object (dictionary), that would solve the problem. As the name resolution would probably be provided only as a library API, rather than a CLI user program, it would be fine. At least at the local level and in the initial version. There are use cases when the program needs only destination and use cases where, on the contrary, remote identity needs to be verified.

The expected use of name resolution in CLI:

Variant 1: specific option, such as -N / --name (or --destination-name for those who like typing) would take the name and try to resolve to destination, or identity and calculate destination hash from additional data.
Variant 2: using the existing CLI option/argument. However, if the argument failed test for hex string of the required length of 32 characters, the program could assume it is destination name and try to resolve it by calling the resolver.

[radio-miskovice]

P.S. so far I consider only local library/package and API. The protocol things should be designed as soon as the basic concept is clarified :)

[skyguy]

I've just uploaded a new version of the petnames package - a PetName and Distributed Directory Name Resolver:

https://codeberg.org/SkyGuy/petnames
https://pypi.org/project/petnames/

I've also posted modified versions of rnsh and rnx which support petnames:

https://codeberg.org/SkyGuy/rnsh
https://codeberg.org/SkyGuy/RetiNet/src/branch/dev/RNS/Utilities/rnx.py

So you can now run rnsh server1 or rnx server1 ls instead of typing or pasting the destination hashes.

Try it:

• Install the package with pip install petnames
• Create a file ~/.local/share/petnames/local/server1.txt containing lines like these:

suggested_name=Server One
b_reti_rnsh_dh0 = aabbccddeeffaabbccddeeffaabbccdd
b_reti_rnx_dh0 = aabbccddeeffaabbccddeeffaabbccdd

• Run ddig server1 which should display the properties you created

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

---

https://codeberg.org/skyguy