Nostr Web Client

Good points. To clarify:

I am not running a relay. Merely a server that sends and retrieves nostr events and notes from the relays of the server operating choosing. They could certainly run their own if they want.

The relays rjemselves will never, ever see the callsign. It isn't possible.

Js8 call is fantastic. For a bad signal conditions comm of sn ratios, light and short messaging, emergency reports etc.. I use it almost daily.

As a comms mechanism, it is absolutely horrendous. In good timing and good SN, you can get 22 bytes per 15 second slot. Then you have to wait until the next transmit to continue.

Without compression, a smallish nostr note raw json object is roughly 700 bytes. This note here will be well into the kilobytes. Even stripping meta, and other stuff out of it you are left with likely 400-500 bytes.

That's over 6 minutes of transmit time for one small not and no emoji's(which take up 4 bytes) on JS8 call.

Even for emergencies, 6+ minutes to publish or get a note frkm a relay is incredibly horrendous and adds to packet loss massively. If you include acks and connections and the actual requests, it likely would be closer to 10 minutes.

This is assuming no repeated data from lost. Yikes. No thanks.

Vara HF would be best honestly, but it I'd closer source, and their KISS TNC is a pain.

Yes, 100% every transmission has your callsign.

However, the data is legally allowed to be compressed with a public algorithm, so that helps obscure your message, even though that isn't the point and theoretically anyone could just decode the binary, brotli, grip, or whatever schema I end up using.

Only the server has to know your npub in my app, it has to for nostr, obviously so can post and get the notes .

I am not running a relay, merely a server that takes the note from radio and broad asts it to relays.

No permanent logging is done on the server on messages. After disconnect, there is no method to retrieve old connections by design.

If you run your own server, there is literally no provacy leakage I see from client to server to nostr. The relays never see the callsign.

If you were to use mine, I will require callsign and likely npub.

Bill Cypher 1y ago

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.

Reply to this note

Please Login to reply.

Discussion

Liberty Farmer 1y ago

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.