Are you sending JSON or some custom packing? Do you need packet switching, or is open broadcast okay? A minimal, TLV based Kind 1 event could look like:
"Hello Nostr":
- 32B (pubkey) + 4B (timestamp) + 1B (kind) + 1B (content length) + 10B (content) + 64B (signature) = 112 bytes
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.
JSON is just an encoding. For nostr it's necessary to produce this encoding in order to verify the signature, but if your medium is constrained, there's no reason you can't define a new encoding. Nostr timestamps are unix timestamps: the essential information in them is four bytes. For essential fields you can just declare an ordering: they need to be there, this is the order, this is their size etc. A receiver would then reconstruct the JSON object based on the format, and then be able to verify the signature.
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.
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.
92 seconds is for two packets?
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?
ax25 has 72 seconds of overhead?
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.
Have you considered a different protocol like ARDOP?
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.
I'm not familiar with HAM, but I am familiar with communications protocols. The problem seems to be that you're using a synchronous protocol like TCP. Other BitTorrent-like protocols might speed things up considerably. I can do some research. You list a few, but what specific hardware systems are you trying to be compatible with?
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.
Sorry, my internet comparisons aren't helping. You said that you're doing this:
T: Connection
R: ack
T: ready
R: ready ack
T: request to send
R: ready
T: Note1
R: ack
T: Note2
R: ack
T: final done
R: done ack
I'm suggesting:
T: Ready to send
T: Note1
T: Note2
T: ErrorCorrectionA
T: Maybe: ErrorCorrectionB
T: Done
R: Maybe: request to resend partN
R: Done ack
So, half as many packets, no channel downtime, and the possibility of many receivers. This is the difference between "TCP" and "BitTorrent". I don't it's incompatible with your hardware goals
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.
The whole idea behind forward error correction and fountain codes is that you spray a lot of data, and the other party eventually checks in to tell you what they missed. I'll do my homework on HAM and check out your git repo. Carry on! 🫡
Sounds good. I do appreciate the feedback.
In the end, the HF packet radio software fldigi and reticulum network are the goals. More flexibility. But ardop seems doable as well.
Lots of fixes and features missing first however, like a decentralized server auth system.
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.
