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!
Liberty Farmer
npub1uw…yfqu7
2024-09-10 16:21:20
in reply to nevent1q…yt24
Author Public Key
npub1uwh0m2y8y5489nhr27xn8vkumy8flefm30kkx3l0tcn0wss34kaszyfqu7Seen on
wss://relay.damus.ioPublished at
2024-09-10 16:21:20Event JSON
{
"id": "3402a611fbd47c29556b9a8954dbe0de48a7cd685252f8438e855880e3e42135",
"pubkey": "e3aefda887252a72cee3578d33b2dcd90e9fe53b8bed6347ef5e26f74211adbb",
"created_at": 1725985280,
"kind": 1,
"tags": [
[
"e",
"0ce1ad6e2c9a97a2215183d81bb173d461d159d15f3b1aa0c2734dbd30d92cac",
"",
"root"
],
[
"e",
"99989e45259bb0f708e16bcb387979fd21f501983ae68814326f5dc59cc5f84a"
],
[
"e",
"691ace1c12ea7ec0205cf5e1c51c6c9d5caa1e11db34e4c686bbfcbeb9e2322b",
"",
"reply"
],
[
"p",
"e3aefda887252a72cee3578d33b2dcd90e9fe53b8bed6347ef5e26f74211adbb"
],
[
"p",
"d7c93c626d28704320899e873c74c24242dd8264f38b140a9c7e41b7467bcf85"
],
[
"p",
"010df0c948fe9ab54d2cb7ea420ffa08d57958981b6ea68e83aaa7eb2dd3f05a"
]
],
"content": "That's a good question.\n\nI am still working through login ideas. Ideally in a decentralized way.\n\nThe server software id currently planned to keep the npub and callsign locally on its instance.\n\nYou can however always run your own server software, so no big deal there if worried about privacy leakage. \n\nThe 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.\n\nThe main reason to keep the npub locally is to save on bandwidth and bytes.\n\nIt'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.\n\n75bytes 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.\n\nIt 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 \n\nIt perhaps I could add an option later on.\n\n64 bytes on the request however may not actually be a big deal and worth it for privacy reasons, not sure. \n\nHowever, 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.\n\nBut again, I want to make server allowable callsigns/users decentralized, rather than localized through me or hardcoded in the code.\n\nMy 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.\n\nThe 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.\n\nI 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.\n\nBut I am open to this process, and currently none of this part has been codes.\n\nLet me know ow your thoughts and concerns and ideas!\n",
"sig": "646524f6bd1cab73a0a665057c63997d94d8a5d5c657b0b45f48f90cd03ac8b64af06f46edaa5025ae4117111ce16e4db30865d5fe2c8ae027dd8eeb9a2aaf68"
}