Hamstr is probably the best possible -str name out there!

Honestly, I don't disagree! There are so many, but I mean come on...ham radio? perfect

If HAMSTR is out: NODOHR (pronounced No Door) - a fun tongue in cheek as anyone can come or go (no door) and no one can stop you (no door) and it kinda sounds like “Noder”. Nostr Operations Decentralized Over Ham Radio

I like hamstr.

Ok, this is actually fantastic.

It is perfect & the logo possibilities are endless

Complicated question sort of. In the initial release, you will need an HF Ham Radio. I plan on running a 24/7 HF station/ server for a while to get started. Hopefully others will download and tun them as well all across the world. The client will need to be an HF radio as well and will need to be the proper licensed ham(legally speaking...), however there would be nothing stopping g anyone from using it in an emergency situstion in the US...legally. Ans yes, NOSTR could absolutely be used in the future for emergencies I think. In future releases, I am planning VHF and UHF capabilites, opening it up to lower licenses. From there, the plan is to add support for the reticulum network, which would open up the possibility of lora mesh nets and even complicated relats and networks like this: HF radio from anywhere in the world potentially,, to server with hf station with no internet access, relayed via other ham radio, lora, wifi, or even a local tcp network setup, the again relayed via any of the above interfaces to a reticulum station that has internet to be able to post the nostr note, or pull notes, dm, and hopefully if I get if figured out, zaps. In due time, lol.... I have had to create a mini packet radio network stack from scratch.... and I am not a developer, in fact I am bad programmer...

Yes.

HAMSTR is a fucking great name

HAMSTR for the win 🥇

Thanks for replying. I am totally loving this idea.

Anytime!

you know it's hamstr 🐹 - we all know it's hamstr 🐹

Hahaha. Clearly I underestimated the market potential for more STR names.

MUTE: messages unto the ether

Honestly, I don't think you are wrong about the STRs being a bit much everywhere... but to not do it specifically here would str up more resentment for the missed opportunity

Ok, it is settled, and it wasn't even close! It will be named HAMSTR. Thanks to all the ostriches for their input and zaps! #ask nostr #hamradio

Incoming....

😂😂😂

Gangstr Hamstr

Hamstr

Commie sounds good until you think communism

That’s the idea. The whole idea of bitcoin, nostr, and radio can be used against authoritarians and are the opposite of communism, that mixed with comms

Hamstr, I hear you about the str…. But this one just makes sense

HAMSTR

I'm not a hamradio guy, but this sounds cool --> View quoted note →

Hamstr all the way.

Love Commie and the logic behind it, more of a 5D level name.... butttt after reading and hearing Hamstr and Commie about 50 times it's Hamstr for the win. Too much of a low hanging fruit that it would be hubris to resist and ignore. Plus now it's out there.

Never been an easier layup than hamstr

💯 HAMSTR Cypherpunk Hamster logo ftw 🐹

You know what to do

Stir that Ham!!

I am interested ing hearing more and trying it out. Been thinking of something like this but not a developer so don’t know we’re to start. I am a HAm and centrally located with HF capabilities so would like to help if you are looking at relay options

How can you even ask this question!

I was thinking a little paw on a dial 😂

Definitely HAMSTR

hamstr, always has been.

🤘🏻

If I use this, will my npub be tied to my callsign in any way?

As a commie, I have to admit HAMSTR is clearly beter

*better

Hamstr

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!

this is the type of shit I want to get into too... when they shut off internet we have decentralized it via radio ham etc... hamster works

also going to get the blockstream satalite to broadcast to the network if all internet is gone...

Hameq, hamfreq, hamohm, just throwing ideas, I think there is already a client called hamstr. Anyway exciting! Looking forward for updates 🔥🔥

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.

Thnx for this exciting development 🌅 I’m in the HAMSTR camp too🤷🏽‍♂️

👀

🐹

😅

*tired of STR names I understand the fatigue, but this application only has one correct name, and that name is HAMSTR. It's logo must include a cute rodent. I don't make the rules.

If wild thing says HAMSTR, HAMSTR it is.

Simple is usually the best path forward I’d go with with HAMSTR that plays into branding and everything Here are a few more options: 1. RADION Resilient Autonomous Decentralized Independent Open Network • Why: Strong nod to radio with a techy, cutting-edge vibe. Plays well into the decentralized communication angle while sounding like a futuristic protocol. 2. COMMIT Cooperative Open Messaging Made Incredibly Trustworthy • Why: It speaks to both commitment to freedom and integrity in messaging, and it has a rebellious undertone without being too blatant. The acronym drives home the decentralized, trustworthy nature of the network. 3. WAVCOM Wide Area Voice COMmunications • Why: Focuses on the technical and decentralized nature of the communication, but the acronym feels energetic and modern, tapping into the radio wave concept. 4. FRECOM Free Radio Exchange COMmunications • Why: Centers around freedom in communication and plays nicely into the ham radio concept while suggesting a decentralized exchange of ideas and information. 5. RADiCAL Resilient Autonomous Decentralized Information Channel Access Logistics • Why: “Radical” brings in a sense of anti-establishment while highlighting the resilient, decentralized aspect of the project. The name packs an edge without being too niche. 6. OPENCORD Open Peer-to-peer Exchange for Network Communications Over Radio Devices • Why: A technical name with a nod to the radio roots, but also feels like something you’d hear in a cutting-edge comms project. The idea of “open” and “cord” ties in both the connection and broadcast elements. 7. HARMONY Ham-based Autonomous Radio Messaging Operating Network Yield • Why: The irony of using “harmony” for decentralized, often rebellious communications creates a memorable, tongue-in-cheek name while still being technical. 8. COMMIND Cooperative Open Messaging Movement for INDependence • Why: Sounds revolutionary and bold, focusing on communication as a movement for independence, fitting with the anti-authoritarian vibe. 9. FREERAD Free Radio Exchange for Exploration and RADical decentralized comms • Why: A name that’s casual yet fitting for a community-based project, using “free” and “rad” to invoke a sense of freedom and excitement in the decentralized communications world. 10. NEWTONE Networked Exchange With Transparent Open Node Ecosystem • Why: A play on the term “new tone” (as in new methods of communication), with a modern acronym that emphasizes the openness and transparency of the system. 11. WAVSTRIKE Wide Area Voice Signal Transmission Relaying Independent Kinetic Exchange • Why: Feels dynamic, aggressive, and anti-authoritarian with a focus on “striking” against centralized control. The name itself conveys energy and disruption.

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.

Marconi

HAMSTR 🐹 is my vote.

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.

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.

Hamstr

#LoRa #Meshtastic

First one is the token name for a game on tg

Hamstr

yeah, it was the community choice: note1pns66m3vn2t6yg23s0vphvtn63sazkw3tua34gxzwdxm6vxe9jkqzca26a