TZUTC: 0000   
   MSGID: 53570.syncprog@1:103/705 2d81fcdc   
   REPLY: 15650.dove-syncprog@12:1/2 2d81143f   
   PID: Synchronet 3.21a-FreeBSD master/1c123cf4a Oct 24 2025 Clang 19.1.7   
   TID: SBBSecho 3.32-Linux master/ec8f7009f Nov 15 2025 GCC 12.2.0   
   BBSID: BBSDEV   
   CHRS: CP437 2   
   FORMAT: flowed   
   NOTE: FSEditor.js v1.105   
     Re: TITHmailer   
     By: deon to Deuce on Tue Nov 18 2025 09:26 am   
      
    > 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)...   
      
   So it's really up to the individual sysops... when you can connect directly to   
   any system on the network at no cost, you can link your area from any BBS.    
   This is completely supported today on the existing infrastructure, and the   
   default echomail routing is still somewhat different to the default netmail   
   routing.   
      
   The main point is that a tree structure to avoid loops or to minimize costs is   
   obsolete.   
      
    > 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".   
      
   Yeah, even the weakest definitions for MSGID require it to carry both the   
   origin system address and an identifier that is unique on that origin system   
   for a sliding window of at least three years... the "official" standard one in   
   FTS-0009 is pretty terrible (origin followed by a 32-bit hex number that must   
   be magically pulled out of magicland) but even that will work if implemented   
   per the spec (with a separate ticket service that hands out sequential   
   numbers, there's whole other standard proposals for giving out numbers because   
   of this).   
      
   Most of the actualy MSGIDs you see on FidoNet are better, so if you just treat   
   the whole thing as a string it'll work... though you still need to build hash   
   trees to be able to deal with them in reasonable timeframes.   
      
    > 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.   
      
   TITH won't actually put kludges in the message text, so all the administrative   
   "stuff" that TITH adds will be "somewhere else"... though it will get smeared   
   all over the message text per tradition when it goes via a non-TITH   
   interface.  I'm considering initially just having a TITH-only net with   
   everything routed through one system so FidoNet as a whole has a single node   
   to yell at about any bits they don't like.   
      
    > Anyway just spit balling ideas without really thinking them through...   
      
   Yeah, that's how it begins...   
   ---   
    þ Synchronet þ The future of BBSing   
    * 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