Complicated question sort of.
In the initial release, you will need an HF Ham Radio.
I plan on running a 24/7 HF station/ server for a while to get started. Hopefully others will download and tun them as well all across the world.
The client will need to be an HF radio as well and will need to be the proper licensed ham(legally speaking...), however there would be nothing stopping g anyone from using it in an emergency situstion in the US...legally.
Ans yes, NOSTR could absolutely be used in the future for emergencies I think.
In future releases, I am planning VHF and UHF capabilites, opening it up to lower licenses.
From there, the plan is to add support for the reticulum network, which would open up the possibility of lora mesh nets and even complicated relats and networks like this:
HF radio from anywhere in the world potentially,, to server with hf station with no internet access, relayed via other ham radio, lora, wifi, or even a local tcp network setup, the again relayed via any of the above interfaces to a reticulum station that has internet to be able to post the nostr note, or pull notes, dm, and hopefully if I get if figured out, zaps.
In due time, lol.... I have had to create a mini packet radio network stack from scratch.... and I am not a developer, in fact I am bad programmer...
Replies (5)
Thanks for replying. I am totally loving this idea.
Anytime!
🤘🏻
If I use this, will my npub be tied to my callsign in any way?
That's a good question.
I am still working through login ideas. Ideally in a decentralized way.
The server software id currently planned to keep the npub and callsign locally on its instance.
You can however always run your own server software, so no big deal there if worried about privacy leakage.
The pvt key will ONLY be on the client device. Never the server, and never sent over the radio. Only the signature will be sent over the air.
The main reason to keep the npub locally is to save on bandwidth and bytes.
It's 64 bytes of waste for the key, plus tye extra json and spaces,, when we have to send the callsign anyways, this can be used to help mitigate that issue.
75bytes doent seem like a lot with the internet, but it sure can be the difference between a sent packet or not on HF ij bad conditions.
It will be full FOSS, you could always fork and to a slight tweak to always transmit the npub from client and the server to process it however
It perhaps I could add an option later on.
64 bytes on the request however may not actually be a big deal and worth it for privacy reasons, not sure.
However, let's say you want to wrote a note, and reply to 6 others, and zap 2 more. That's now potentially almost 900 bytes of data that don't need to be sent when they could residen on the server, since the callsign is already being sent with the data requests. The server will just formulate the relay request and auto fill your npub to grab notes or post them.
But again, I want to make server allowable callsigns/users decentralized, rather than localized through me or hardcoded in the code.
My idea was to have a bot running, and the person could send a dm to the bot account npub with their callsign and name or something.
The user could be verified via the different callsign databases as being legit. It then will keep a dB of allowed users/callsigns. Nothing else would be stored.
I can't have the server being pinged to death by non registered users. I want them to be able to not connect to a server if not authorized to help this issue and tying up the server(s) on frequencies.
But I am open to this process, and currently none of this part has been codes.
Let me know ow your thoughts and concerns and ideas!
