Proposal: URN formats

[skyguy]

To reduce the confusion around the hex strings for Identities and Destinations, I'd like to propose a standard format for their display:

  reti:idh:f554ba504e8549132202874061e13b9a
  reti:dsth:b891c92333a683e51b5c7b5fc6caf2c3

or even shorter, using base58 encoding and Multibase marker:

  reti:id:zXJ5kBUgSD8Ey1mTjrmNcxH
  reti:dst:zPnuMeYQeF9Dd52kCCZ4nHx

Reasoning:

• The format is double-clickable to highlight, then Copy & Paste.
• "reti:" prefix to allow for a protocol handler to be registered and start apps on clicking.
• "reti:" because "reticulum:" is too long and "rns:" isn't memorable enough for people not using it every day: "Was it 'rnf' or 'rms' or..."

Looking forward, a transition URL for HTTP over Reticulum could look like:

  reti:https://reti.click/id:zXJ5kBUgSD8Ey1mTjrmNcxH/aspect/aspect/aspect
  reti:https://reti.click/srv:zPnuMeYQeF9Dd52kCCZ4nHx/

where the reti.click webpage explains how to install Reticulum and access the service.

More generally, a service would look like:

  reti:<protocol>:srv:<destination>
  reti:<protocol>:id:<identity>/aspect/aspect/aspect

What are your thoughts and experiences?

-Kevin

[LinuxinaBit]

💟 I like this idea, and I think it is necessary to standardize the veritable mess that is Reticulum-adjacent addressing schemes:

Identity Hash: <12345678901234567890asdfhgqwerty> (< and > optional)
Destination Hash: <12345678901234567890asdfhgqwerty> (< and > optional)
LXMF Address: lxmf@12345678901234567890asdfhgqwerty
NomadNet Page: [12345678901234567890asdfhgqwerty:/page/index.mu] (brackets optional)

Your idea could potentially be a big improvement, however I do have a few notes:

1. Some of those examples are a lot to type.
2. Identity hashes are effectively standalone; aspects are embedded in the destination hash (source).
3. Colons : are already used in that way by URIs and may create confusion/annoy the IANA.

With that, I would like to recommend something like this instead:

id#12345678901234567890asdfhgqwerty for identity hashes
dest#12345678901234567890asdfhgqwerty for destination hashes (the aspects contained within differentiate protocols)

A path can be added on the end if extra information is needed (intentionally compatible with NomadNet's current scheme): dest#12345678901234567890asdfhgqwerty:/page/index.mu
And a link can have a relative path as well: #:/page/index.mu

Anything other than id# can replace dest# (i.e. something like lxmf#), just for human readability (no plain # though).

That's it!

...Theoretically, at least. I still have to ask Mark 😅

[joakim]

I think : is fine in URIs, plenty of schemes that use that, URN and Spotify for example.

urn:mpeg:mpeg7:schema:2001
spotify:track:2jCnn1QPQ3E8ExtLe6INsx

In the case of NomadNet pages, it might make more sense to use a URL-like scheme where the RNS destination is the authority part? Though I don't think IANA would like that, it's supposed to be IPv4/IPv6 AFAIK.

nomad://12345678901234567890asdfhgqwerty/page/index.mu

[LinuxinaBit]

That runs into the same ‘multiple standards’ issue.

If you really want to use colons instead of hashtags (get it? hash tags? I just came up with that one 😁), and want to keep the rns in the URI, I would still suggest something like this:

rns:id:12345678901234567890asdfhgqwerty for identity hashes
rns:12345678901234567890asdfhgqwerty for destination hashes (the aspects contained within differentiate protocols)

Path example rns:12345678901234567890asdfhgqwerty:/page/index.mu
Relative path example: rns:/page/index.mu

Append anything a-z besides id: to the rns: to visually differentiate protocols, i.e. rns:lxmf:

Edit: Assuming this concept doesn’t break some important convention, I think I like this one a bit better than the hashtag one now…

[joakim]

Hm, I'm honestly uncertain about what is and isn't good URI scheme practice, I would need to study it closer (I have before, my mind obviously didn't consider it worth remembering). Anyway, let's hear what Mark thinks first :)

get it? hash tags?

Hehe, nice (un?)intended pun!

The benefit of using URIs is that they're universally recognized, with wide support from libraries and some languages. And it enables OS level support of links by registering a protocol handler.

Now that I think of it, nomad:// may not work, being a terminal program.

[joakim]

I think you mean URIs? URNs start with urn:. I like URIs though!

I would prefer rns as the scheme. IMO, it's not any harder to remember than https or tcp. It's not taken.

It would be important to make it future-proof. I like Multibase (and Multihash) or something similar. With tech like this, one should think decades ahead. We're stuck with decisions made today for as long as the tech lasts.

Having a URL inside a URI seems wrong to me. If you're talking about a HTTP server on an RNS destination, maybe rns+http://[destination]/[path]… could work?

[r8io]

This is what I like to use for now.

Reticulum Network Resource

• rnr:5c2207aca3aae61598cb79f5ba21a35c
• rnr:5c2207aca3aae61598cb79f5ba21a35c:/page/index.mu

Lightweight Extensible Message

• lxm:195378bc380ac679b223832d9a26f22c

Reticulum Network Identity

• rni:f554ba504e8549132202874061e13b9a
  or maybe even better, just keep:
• <f554ba504e8549132202874061e13b9a>