Also, you can't have many receivers in ham radio data modes. Not legally at least. You must announce yourself and where you are sending it to. 2 stations cannot be using the same callsign at the same time as different receivers if that makes sense.

But by all means, fork it and do whatever you like.

While you are absolutely correct that would save packets and time, there are way too many packets lost in HF radio for something like that, unfortunately. It is not uncommon to miss over other, every third packet. Even the small ones. Something like ardop or Vara does their own acks and systems for error correction, which work fine. But there is zero chance you can proceed with our them and still keep the connection going. I'm fact, on HF, sudden complete signal drop is common.

I'm also in no way going to redo the packet stack at this point, lol.

It was the dumbest move ever. Then galaxy followed.

Airpods are so uncomfortable.

I use a USB c to headphone adapter, lol

No, I'm not using async tcp, I'm not sure what you mean. There is no networking stack other than connecting to the tnc on an ip, and the webserver front end. Everything is over ham radio packets which are not duplex.

Any hardware tnc modem that uses KISS is compatible. It is up to the user to try.

Thanks for your input, but I think we are on different wavelengths so to speak as to what HAMSTR is.

That would be the absolute worst reserve ever. The growth of purchasing power from Bitcoin will be not only taken away by the other coins, but the whole reserve them would trend towards zero. He's a joke.

Ie6

I'd ask for a gun and a bullet.

Rug pull Bitcoin adoption in favor of the IMF, then meet with shitcoiners.

Yes, this checks out

Nope.

I wanted to start with max compatibility with kiss tnc.

That way you can use a million hardware tnc, direwolf, uz7ho, and a bunch of other kiss tnc software packages

Ardop still uses ax25, but I think needs a plain kiss frame not ax25 pre formatted.

Likely HAMSTR could be modified if setting is ardop, then it skips or modifies the packets.

I'm not interested in this feature currently however, as I have lots of other features to work. If you want to give it a rip, go for it.

If you want more speed, ardop wouldn't fix that on HF likely. Maybe a bit, and yes, more robustness though. Personally, I don't like winlink using ardop, never works well for me on HF

After I add some needed features, I will be switching gears towards fldigi instead.

GM Nostr!

Thanks! Shoot me a DM whenever ready with your callsign and I'll add it to the server auth.

Dm34. Yes, hf.

If you want to give it a try, I can setup my rig on a frequency and let the server run today.

Technically I’m am using fx25 in addition, at the tic level which adds a few bytes to each size. Plus kiss framing.

The time includes delays, relay processing, sending, sending ac’s, waiting for connection ack, getting ready, and on and on. There is lots of back and forth. Plus I have control data and flow bytes for missing packet checking. There is crc checksum data 8bytes as well.

Do you mean the packets themselves? I think each packet has around 50 bytes of ‘overhead’. If that helps?

But I would need to check my tic log to verify, I don’t recall exactly.

It’s more like 10. Connection, ack, ready, ready ack, request to send, ready, then the 2 packets for the actual note, with ack in between, final done, done ack, disconnect. Make sense?

also, the content more often the length that causes more packets, not the rest of the structure. sure, you could save a half a packet with extreme conservation, which may help not spllover into another packet perhaps. there is almost always 2 packets for writing a note, and often the 2nd is not full, but saving 50 or 60 bytes likely won't do the trick.

the receive side has no knowledge of anything, it cannot reconstruct or verify signature. it is merely a passthrough, as it has no access or knowledge of the nsec.

Why Haskell? Trying out for IOHK and the Cardano team? 😂

Easy. Blacksmith. I do it in 2025, might as well back then

I am sending compressed Json, yes. A full signed note.

I have no idea what your math means, or where it came from?

A timestamp is not 4 bytes, the kind is not 1, it is a min of 7(kind:1;).

content: "Hello Nostr"; would be 23 bytes.

Uncompressed of course.

Who the hell gets financial advice from a guy or gal that has to drive Ubers to make a living?