You are thinking about callsign leakage into nostr from your app, which is a concern. I am thinking about npub+callsign pairs being captured out of the air during the HF transmit. No encryption, so the only fix there is to be relay like transmitting notes for many npubs from the same callsign or to only use doxxed keys. You could also break callsign TX rules and not transmit it. Something to keep in mind as an emergency skill but not a valid regular habit.

Replies (1)

Got it. My server and client setup doesn't broadcast the npub and callsign together as it is now. It never broadcasts your npub. It's about tradeoffs. Always is. Here, you trade server leakage and or bad server operators for over the air privacy issues. Just your callsign is broadcast. No npub or any other identifying information from nostr. Run your own server and there is no chance of or at least very minimal server leakage of npub and callsign mixing.(barring q hack or something is all). Personally, the advantage of smaller packets and more privacy over the air is the way to go. Again, the compression scheme, would also maximize privacy. You can't encrypt to obscure a message legally. You can absolutely compress data to dave transmit time. You could also broadcast in the open, but not in the right order. Perhaps a scheme to rearrange packets with npubs in random key orders baded on parameters eithin the software. Fork it on your own and change the key integer or something and nobody else would have it to decode. There is nothing illegal about sending full and open text in a random order. That is cypher use potentially, not encryption. But I'm not a legal scholar.