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.
Login to reply
Replies (2)
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.