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