TZUTC: 1100   
   MSGID: 15650.dove-syncprog@12:1/2 2d81143f   
   REPLY: 53559.syncprog@1:103/705 2d813d7e   
   PID: Synchronet 3.21a-Linux master/b7d3db6c3 Sep 28 2025 GCC 10.2.1   
   TID: SBBSecho 3.32-Linux master/ec8f7009f Nov 15 2025 GCC 12.2.0   
   COLS: 80   
   BBSID: ALTERANT   
   CHRS: CP437 2   
   FORMAT: flowed   
   NOTE: FSEditor.js v1.105   
     Re: TITHmailer   
     By: Deuce to deon on Mon Nov 17 2025 02:49 pm   
      
   Howdy,   
      
    > Yeah, a lot of where FTN ended up is just inertia.  There's various   
    > proposals from the 80s and 90s rotting away suggesting similar things, but   
    > they never caught on in FidoNet, so most of them are half-baked at best.   
      
   I agree. Language is also an issue there, where content is written in english   
   that is too generic, open for multiple interpretations of the actual intent.   
      
   I too thought about written my version of those specs - but glad to see that   
   you've started that bandwagon :)   
      
    > It's been an interesting journey even for just the small bit I've done so   
    > far, realizing that the point I was starting at wasn't quite right... pretty   
    > sure the first thing I'll be creating now will be the bundler, which will be   
    > the thing that implements the Binkley-style outbound, then the unbundler,   
    > which will implement the inbound, THEN the mailer.   
      
   Nice. I was going to work on the mail bundling first (since I noticed your   
   specs starting to define that).   
      
    > The assumption of default direct has some interesting implications for   
    > echomail that I'm still working through, it still keeps collapsing into a   
    > simple star topology, which means the SEEN-BY for pretty much every post   
    > will either be only two nodes, or a copy of the whole nodelist.  It feels   
    > like just a usable PATH will do the job, and a robust MSGID will allow loops   
    > to be detected and mitigated/fixed.   
      
   It might be worth considering multiple star topologies? IE: Distributed,   
   otherwise the network falls apart when the 1 hub at the center of the star   
   topology goes AWOL (which happens too often in othernets)...   
      
   But agree, a MSGID should be the definitive determination of duplicate   
   content, and it might be a dynamic value being the "sender's ID" and a   
   "timestamp". There might also need to be a "context" element to to avoid the   
   situation that two users (in two different msg areas), post a message at the   
   exact same "timestamp".   
      
   If a message has a digital signature added to it (as a kludge so its not   
   displayed for example), then the origin line could be completly dynamic and   
   cosmetic.   
      
   Anyway just spit balling ideas without really thinking them through...   
      
      
   ...ëîåï   
      
   ---   
    þ Synchronet þ AnsiTEX bringing back videotex but with ANSI   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 10/0 1 102/401 103/705 105/81 106/201 124/5016 128/187 129/14   
   SEEN-BY: 153/7715 154/110 214/22 218/0 1 215 610 700 810 226/30 227/114   
   SEEN-BY: 229/110 206 317 400 426 428 470 700 705 266/512 280/464 291/111   
   SEEN-BY: 301/1 320/219 322/757 342/200 396/45 460/58 633/280 712/848   
   SEEN-BY: 902/26 5075/35   
   PATH: 103/705 218/700 229/426