rns.recipes

Hello, I see that Columba and Ratspeak (and some other iOS attempts for similar app) use different urls behind the QR code. Could we all agree on a standard for interoperability please? 😄
I'm thinking of adding a QR generator for my t-deck firmware and don't know what url type to generate.

I am open to suggestions.

Columba's format is lxma://${lxmf_destination_hash}:${public_key}

I chose lxma for LXM Address. I included the public key so that users wouldn't have to separately request keys before sending a message.

Ratspeak definitely came along after Columba, and I can't recall dude.eth ever reaching out for clarification on the format before making his own. I don't care about being first or my format being the one that becomes the standard, but I have had users come to me a few times confused about why the QR codes aren't interchangeable, so I agree that some standard would be good for UX across the board.

Would you include something different in the QR code? Choose a different handle? Let's discuss :)

Torlando wrote:

I am open to suggestions.

Columba's format is lxma://${lxmf_destination_hash}:${public_key}

I chose lxma for LXM Address. I included the public key so that users wouldn't have to separately request keys before sending a message.

Ratspeak definitely came along after Columba, and I can't recall dude.eth ever reaching out for clarification on the format before making his own. I don't care about being first or my format being the one that becomes the standard, but I have had users come to me a few times confused about why the QR codes aren't interchangeable, so I agree that some standard would be good for UX across the board.

Would you include something different in the QR code? Choose a different handle? Let's discuss :)

I like Columba’s lxma:// format, although if it’s specifically for LXMF messaging the destination hash is redundant and could be derived from the public key. I could see that being confusing to people if they were expecting to see a destination hash, though. Including the dest hash and the public key together, you could call it rns:// or rna:// something and have it be applicable for any kind of Reticulum destination.

I guess another option would be to just extend the existing lxm:// URI encoding for paper messages to support optional fields.

Honestly, without getting too much into it, I used to expect to get only the hash from the QR code, just as @K8 said. However lxma://hash:pubkey makes sense and it seems MeshChatX also parses both lxmf:// and lxma:// with both hash only and hash:pubkey, so the two most used GUI clients seem to agree on what @Torlando has put in Columba.
The only question is if Ratspeak can also join the party and align with lxma://hash:pubkey. Perhaps if this can be put on some authoritative place as a recommended url generation, it would be great. I'm talking about GUI clients (including any new which might be created), as this is where most of the new Reticulum users land at.

fwiw, I haven't seen dude.eth on this forum, and his inclusion of a custom crypto coin has turned off a lot of folks.

K8 wrote:

I like Columba’s lxma:// format, although if it’s specifically for LXMF messaging the destination hash is redundant and could be derived from the public key. I could see that being confusing to people if they were expecting to see a destination hash, though. Including the dest hash and the public key together, you could call it rns:// or rna:// something and have it be applicable for any kind of Reticulum destination.

The rns:// URL scheme is already used by rngit. For example, reticulum-js lives in:

rns://adafb3153efd4d96d532568a5208b3b5/reticulum/reticulum-js

(adafb3153efd4d96d532568a5208b3b5 is the destination hash for the rngit server)

I think having a more generic Reticulum URL scheme could be great, not only for contact sharing but also for stuff like NomadNet links. Now they're a bit hard to parse out of content, and apps like Columba can't easily associate OS-level URL handlers for them (so for example opening a NomadNet link from an email would work).

@bergie Ah yeah, of course, totally forgot about that. That scheme is already applicable to anything running on RNS, not just rngit, but for additionally inlcuding the public key there should maybe be a different format. Though now that I'm thinking about it you could just have an optional colon after the dest hash followed by the public key, and have the same URL format work for everything.

I wonder how including the public key works with destinations that enforce ratchets? I think the initial attempt to deliver might fail and the sender would have to request keys from the network anyways.

nomadnet seems to use a slightly different url format, with a colon after the reticulum address. e.g., this thread is 9ce92808be498e9e05590ff27cbfdfe4:/page/forum/thread.mu

I think we can't use universal rns:// e.g. you won't be able to distinguish visually between different type of identity url which doesn't bear any other additional info besides the hash e.g. rnprobe identity and rnsh identity. You could deduce for Nomadnet and lxmf with publikey from the visual suffix info, but not for a bare hash.
Obviously the software could find what's what upon receiving a packet but not if the identity was never met before.

Here's my idea for a generic Reticulum URL scheme: rns://${app name and aspects in dotted notation}/${destination hash}(: {pubkey}) (or some other scheme like reticulum://, rna://, etc.)

Maybe some sort of application-specific part after this too: for NN, the specific page (like /page/index.mu), for rngit the group and repository (like /reticulum/reticulum)

For example: rns://nomadnetwork.node/9ce92808be498e9e05590ff27cbfdfe4/page/index.mu

Carries all of the information necessary to know if it's for LXMF/LXST/NomadNet/rngit/..., resolve the identity pubkey and destination and connect, and optionally to also provide the public key and immediately derive the destination without querying the network for it first.

Now whether or not to use a common URL scheme for all of these different protocols that run over Reticulum is a separate question. It could be pretty convenient but at the same time I don't know how having something like Sideband or Columba opening a rngit URL could work. IMHO per-protocol URLs rather than one URL scheme for everything built on Reticulum might be better for this reason.

neouss wrote:

nomadnet seems to use a slightly different url format, with a colon after the reticulum address. e.g., this thread is 9ce92808be498e9e05590ff27cbfdfe4:/page/forum/thread.mu

thats due to resource urls being structured "desthash:resourcehash"

By the way, it would be awesome to be able to include query parameters support in lxma:// URLs. Kind of like how mailto: works.

What I'm doing here is implementing ownership associating with a remote NoFlo runtime, and being able to create a Qr Code with "send LXMF destination X message Y" would be nice.