Replying to Avatar Bill Cypher

If I use this, will my npub be tied to my callsign in any way?
Avatar
Liberty Farmer 1y ago 💬 1

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!

Reply to this note

Please Login to reply.

Discussion

Avatar
Bill Cypher 1y ago 💬 1

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.

Avatar
Liberty Farmer 1y ago 💬 1

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.

Avatar
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.

Avatar
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.