@MSGID: 1:266/625 6a256761
@REPLY: 2:341/234.1 6a256172
@TZUTC: -0400
@PID: msged/lnx 6.3 2023-02-24
@TID: hpt/lnx 1.9 2024-03-02
 SS>> @MSGID: 1:266/625 6a24566667e12160
 CN>                        ^^^^^^^^^^^^^^^^

 CN> The serialno field must be 8 chars long according to FTS-0009.

 Thanks Carlos, I overlooked this detail in that spec. I`ve read it
so many times, I can`t believe I missed that sentence in the middle
of all the double-quote babble. 

 I`ll have to give MSGID generation some thought. UNIX time would be
easy and just ignore the 1 second duration that a "duplicate" MSGID
might be generated; I`m not ok with that. Especially given a RasPi could
easily support several hundred concurrent users.

 Which makes me ask the next question, why is it constrained? and
why 32bit? Does anyone know? it is just legacy?

 If it was 64bit (16 hex characters) I could use UNIX nanotime and
generate the serial number within the message base lock cycle. It would be
impossible to generate dups that way. Or use the method I have coded already
that uses 32b UNIX time and CRC32 of the message text. 

Sorry, letting the programmer in me ramble on... bad idea.  

---
 * Origin: <=-[ The Digital Post ]-=> (1:266/625)
SEEN-BY: 19/10 50/109 103/705 104/117 105/81
106/201 124/5009 5016 128/187
SEEN-BY: 129/12 14 102 125 160 165 134/101
153/757 7715 154/10 30 110 201/0
SEEN-BY: 203/0 218/700 840 221/0 1 6 360 226/30
227/114 229/110 112 200 206
SEEN-BY: 229/300 307 317 400 426 428 452 470 664
700 705 240/1120 5832 261/1
SEEN-BY: 263/1 266/75 325 512 618 625 630 267/152
154 280/464 1043 5003 5006
SEEN-BY: 280/5555 291/111 292/854 8125 301/1 310/31
320/119 219 322/757
SEEN-BY: 335/364 341/66 234 342/200 396/45 423/81
120 460/58 463/68 633/267
SEEN-BY: 633/280 712/620 848 770/1 902/26 5000/111
5015/46 5020/400 715 846
SEEN-BY: 5020/848 1042 4441 12000 5030/49 1081
5058/104 5060/900 5061/133
SEEN-BY: 5075/35 128 5083/444
@PATH: 266/625 512 229/426 712/848 280/464 221/1 6
5020/1042 4441