I've thought a bit more, and radio based store and forward nostr could involve a combination of relay and botted client to repist what comes in.

The tricky part is how to handle those reposts, because if it's from one npub, more than a handful of relay users would make it unwieldy to follow what you want.

I'm curious as to whether you think something like an nsec bunker or amber could be used to permit the bot to sign and send what the relay receives in a manner that'd work in the limited bandwidth environment.

The vision here being tha ability to relay notes globally without touching the Internet, but maintaining the cryptographic integrity lf Nostr.

I guess where things really get hairy is when you go to relay things a second time and there's no way to tell Amber or your bunker to allow signing.

Reply to this note

Please Login to reply.

Discussion

Or there's always the option to get way less complicated and basically rsync between the relays. the notes are already signed...

Once a note is signed on the client, it is just json. You can send and forward as many times as needed to get to a relay as long as the signed json is identical bytes and intact.

I guess the question there is HOW that forwarding is done. But that may be where my understanding of Nostr is a bit suboptimal -- that may be as simple as just boosting it without needing to faff about with signing. Otherwise, it seems like it'd be a propagation that's done from relay to relay without going through a normal client connection, which is where things get a bit odd. The goal of course being to allow people following the person posting the note to see it, and also not to have one npub belonging to the relay that is just a mostly unsorted pile of relayed content which is harder to selectively follow.

Sorry, I don't know what you mean? It is a standard nostr note. It is publishing to relays, nothing more. A signed nostr note just like a normal client.

Nostr relays to prop gate from relay to relay typically. That is done at the client level.

There is no such thing as a client that reads a ham radio callsign, nor would a relay use this information.

My understanding was relays don't forward notes to other relays -- only to the client requesting the note. That is where store and forward seems like it would be necessary in order to tie a ham-enabled relay into the broader nostr ecosystem, allowing hams to access nostr as clients without an internet connection.

But, it isn't immediately clear how that store and forward would be established while maintaining the structure of notes and their apparent origins.

I think I need to do some reading.

That is exactly what HAMSTR is. It allows clients to access nostr.

Ahh. I thought it was essentially a single relay that was accessible via radio and internet, but sort of limited there (which is very cool in itself, but not quite as extensible as being able to relay traffic to and from other relays.

Once I'm licensed (and more importantly, have equipment -- the licensing is cheap; the equipment less so!) I definitely intend to play with it a bit!

I don't understand what you mean by relay traffic to and from relays?

That not really how nostr works. Relays are just stored data, nothing more. HAMSTR is not a relay, rather it connects to any relay you wish and published/gets notes from. There are some default relays, but totally configurable and changeable.

Yea, I've not been the best at explaining myself. I was sort of envisioning something that did what Hamstr does with being a gateway to existing, Internet native relays, but ALSO serves as a relay itself, so that in the event of an internet outage, Nostr functionality is maintained over radio (albeit only as a single relay). And you're right, while Nostr relays don't store and forward, I guess I was imagining something that could perhaps be termed a "caching gateway relay" -- something that serves as a relay itself, and also will route requests to other relays, and then cache those responses, in a bid to be a bit more anti-fragile (and maintain as much functionality as possible in an Internet outage).

It'd be less store and forward, and more get and store (and relay upon request).

Definitely don't have it all straight in my head, just sort of playing with a marriage of nostr like functionality with the sort of nntp/fidonet style store and forward networks of BBS's to provide something that feels a little less out of date.

Oh, I understand now. You could easily just add a nostr relays to the server side. Any python or other relay would work fine. Then you could publish locally to that relay always.

I envision many servers across the globe, so internet shouldn't be an issue. If it is, then nostr may be the least of my worries lol

Hah, yea, that's likely the case globally.

More curious though for cases such as particularly problematic regimes. I know at least for awhile, FIDONet was a way that information flowed across firewalls because firewalls blocked TCP/IP traffic, but of course didn't filter traffic flowing directly over phone lines.

Obviously radio has its own hazards as anyone who's ever done a fox hunt knows that locating the transmitter (or at least the antenna) is pretty trivial with a modest amount of equipment. But the optionality so that people can do their own risk assessment and decision making around it would be cool to see.

HF transmissions are much harder to locate than localized VHF signals. But yes, everything has tradeoffs.