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!

I'm having trouble wrapping my head around what you are thinking. In my head the easiest path for a client is to fork js8call to automatically wrap text with the necessary information to be a nostr note. This means your every transmission is tied to your callsign by law. A nostr relay has to be able to have the same data but you are using a relay instead of a client. If you are running a relay that is sharing notes between relays it would be sending other notes in addition to your own and this would obfuscate by sending lots of notes from many npubs from the same call. That relay would have to be very limited. Any of the big relays would be way over bandwidth of any HF link even once we officially go live on not having baud rate limits. I like being a nym on nostr. I guess I could roll a new nsec for my ham stuff and just tie it to my call sign. I wouldn't intentionally tie my call to this nym which is why I asked.