There are different solutions for this problem, depending on the system requirements. For example, if the system doesn't require internet to work, URLs doesn't makes sense they cannot be shared since the server/service behind them cannot be reached. However, we can observe other techniques and projects that use fault-tolerant protocols to share data over a noisy, lossy channel. I'm thinking of data over audio, where data is transmitted encoded in audio. Normally, the protocols used there have well-designed fault tolerance and tones to indicate the beginning and end of the stream. You can do the same and have chunking, sequence start bytes, and end bytes. This way, you can check data integrity too.

If the system requires internet to work, it can be resolved in multiple ways, from URLs to pure Nostr. I was already experimenting with the concept of using derivation paths to share Cashu tokens. For example, let's say we have a shared secret, like a Diffie-Hellman key exchange, which becomes our seed from which we can generate and derive new addresses. Knowing that, we can just exchange a derivation path with a fixed length. Then, with that derivation path and a relay hint, we can use NIP-60 to find the tokens. This can also have a different design approach where I expose an extended public key (xpub) from which you can derive addresses that only I control, and then share the derivation path of the key you used to lock the tokens.

Reply to this note

Please Login to reply.

Discussion

This is a great idea; great several ideas

Audio could work, but I do like Diffie-Hellman key exchange concept better. With something like meshtastic, each device has a pub/priv key; so curious if I could lock the shared secret to that specific public key.

Maybe use same concept as a fixed-length derivation path, & find those proofs with NIP-60

I didn't mean to suggest using audio. I mentioned it because normally protocols for data over audio use these kinds of methods to transmit the data in noisy/lossy channels, we can apply the same principles here. I think the interesting thing would be to have a way to transmit the tokens without assuming there is an internet connection, right? Because if there is internet, why use lora?

On the other hand, what kind of keys are they? In any case you can always sha256 digest and get a key out of any string.

They are sha256 I'm pretty sure; I'll double check.

Messages can be encrypted too (unfortunately not default, but just a toggle switch to turn it on)

Exactly; needs to be useable over low bandwidth protocols like LoRa

- could use offgrid 2.4GHz for larger & faster transmissions, but not everyone will have a router in their pocket, or within range to a long range WiFi signal

Nope sry, keys are derived from elliptic curve25519, while messages are AES encrypted