https://gitlab.synchro.net/main/sbbs/-/commit/5ce56d3bbb5ec6cabd66ae50
Added Files:
src/tith/GNUmakefile README.md base64.c base64.h src/tith/hydro/hydrogen.c hydrogen.h src/tith/hydro/impl/common.h core.h gimli-core.h src/tith/hydro/impl/gimli-core/portable.h sse2.h src/tith/hydro/impl/hash.h hydrogen_p.h kdf.h kx.h random.h src/tith/hydro/impl/random/avr.h ch32.h cheriot.h chibios.h esp32.h linux_kernel.h mbed.h nrf52832.h particle.h riot.h rtthread.h stm32.h unix.h wasi.h windows.h zephyr.h src/tith/hydro/impl/secretbox.h x25519.h src/tith/nodelist.c tith-client.c tith-common.c tith-common.h tith-config.c tith-config.h tith-server.c tith.h
Log Message:
Start of the TITH (This Isn't That Hard) project

TITH aims to be a new, modern, complete FTN stack, focusing on being
usable with Synchronet. The code will be C11 only as much as possible,
with OS-specific code only used where absolutely necessary.

TITH will be leaving behind historical FidoNet baggage wherever
reasonable while still adhering to the original spirit of as many
documented interfaces as possible. As an example, the standard TIC
format *requires* and 8.3 filename for both the TIC file itself and
the file it describes. The TITH stack will instead have a very similar
control file (likely tac) that will be mostly the same, but with the
File line allowing long, UTF-8 filenames. Converting from TIC will
be handled by the TITH stack, but converting to TIC is someone else's
problem.

TITH will be fully 5D, without the 8-character limit on domains. The
current plan is to use FSC-0067 style node addresses (ie: fidonet#1:103/1 instead of 1:103/1@fidonet).

TITH will be UTF-8. It will aggressively convert things to UTF-8 and
stubbornly keep them that way.

TITH will be multiple small programs that each do one job. If there's
a documented interface for programs that do the same job, TITH will try
to use that interface.

TITH does not care if unmaintained legacy software does not work
properly with the netmail, files, or echomail that TITH produces.
As an example, the SPTH control paragraph from FSC-0067 is planned to
be implemented. The stripping of PATH paragraphs and pruning of
SEEN-BY paragraphs is almost certain to cause issues with ARCmail 0.6.
I don't care. I only care about things that are on FidoNet (and other
FTN networks) today.

TITH formats, protocols, and interfaces will be publicly documented
and each time one is completed or updated, an FTA-1002 compliant version
will be posted on the internet, and a post will be made in the FTSC
public echo with a summary of the document/changes, and the URL it's
hosted at. This will be the extent of the engagement with the FTSC.

I plan to work with my NC closely, and work through them to keep TITH
accepted by the FidoNet community. Should some things be rejected by
my NC (or *Cs above them), TITH will attempt to provide the service
using alternative means. For example, TITH will require a 43-character
public key be added to the nodelist. The nodelist line length limit
is currently 157 characters. If the *Cs don't approve of using 27% of
the possible line for a something only a small number of systems use
(which would be a reasonable decision ignoring the reasonableness of
157 characters as a limit), infrastructure to maintain a TITH-specific
nodelist format and distribute it to interested parties will be set
up with no complaints. The idea is to improve FidoNet by example, not
to start debates.

Initial development is around the mailer component, which will provide
FTS-5005 BinkleyTerm Style Outbound support and a slightly modified
FSP-1040 SRIF interface. Every time I consult that FSP, which has the
same number that was assigned to the last document I submitted to the
FTSC, I'll be reminded of why I don't plan to engage with the FTSC
regarding any of this.

TITHmailer (name subject to change, TMail?) will provide public key authentication, with the public key in the nodelist. Transfers will
be encrypted.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: src/tith/GNUmakefile README.md base64.c base64.h src/tith/hydro/hydrog
By: Deucе to Git commit to main/sbbs/master on Thu Nov 13 2025 05:35 pm

Hey Deuce,

Start of the TITH (This Isn't That Hard) project

TITH aims to be a new, modern, complete FTN stack, focusing on being
usable with Synchronet. The code will be C11 only as much as possible,
with OS-specific code only used where absolutely necessary.

Love everything you are doing - and I'll work with you to make it a reality if you are interested.

I'm no *C in fidonet, but I created clrghouz to support the backward legacy, while thinking about new stuff. Havent progressed that far on the new, I think I have the foundations in place now to do so...

Happy to be another system that supports a new way of doing this hobby, that results in a better way to support the legacy BBSing that we play with...

Reach out if you want another system to bounce of off..


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI

Re: TITHmailer
By: deon to Deuce on Fri Nov 14 2025 05:07 pm

Love everything you are doing - and I'll work with you to make it a reality if you are interested.

Reach out if you want another system to bounce of off..

I think we're a ways away from that yet... but the quickest way to start using it would be to join my useless and crappy FTN network (https://bbsdev.net/BBSDev/) since that's where it will be deployed first.

For just the mailer, I expect I'll get that finished before the new year, but the other tools I don't realistically expect to finish up for a few months yet. I'll likely put out a call in Synchronet Sysops once I think it may be working and not have bugs.
---
þ Synchronet þ The future of BBSing

Re: TITHmailer
By: Deuce to deon on Fri Nov 14 2025 02:15 pm

Howdy,

I think we're a ways away from that yet... but the quickest way to start using it would be to join my useless and crappy FTN network (https://bbsdev.net/BBSDev/) since that's where it will be deployed first.

I sent you a netmail (QWK routed via VERT I'm assuming) - hope you got it.

(I dont hang out much in IRC, because my laptop sleeps and the connection always drops - so I need a better setup there.)

BTW: Was curios, reading your TTS docs, and wondered if there is an error there.

TTS-0002 - Section 5 Encoding.

Your example is based around:
0b0000'0010'0111'1010 (378)

However, 378 is
0b0000'0001'0111'1010 (378)

So the most significant bit is position nine, not ten.

Did I read it wrong?


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI

Re: TITHmailer
By: deon to Deuce on Sun Nov 16 2025 04:56 pm

I sent you a netmail (QWK routed via VERT I'm assuming) - hope you got it.

I did get it, I still had "email forwarded to netmail" in my user settings which, of course, forwarded the netmail to email. :D

So, I got it in Thunderbird and replied using my BBSDev SMTP account... I didn't get an error from Thunderbird, so I assume BBSDev accepted it then routed it.

BTW: Was curios, reading your TTS docs, and wondered if there is an error there.

I'm certain there's multiple errors there. :D

So the most significant bit is position nine, not ten.

Did I read it wrong?

After some close examination, I have come to the tentative conclusion that you are right and 378 is *not* greater than or equal to 512... thanks, I'll update the doc.
---
þ Synchronet þ The future of BBSing

Re: TITHmailer
By: Deuce to deon on Sun Nov 16 2025 01:02 pm

Howdy,

I did get it, I still had "email forwarded to netmail" in my user settings which, of course, forwarded the netmail to email. :D

Sweet that works :)

So, I got it in Thunderbird and replied using my BBSDev SMTP account... I didn't get an error from Thunderbird, so I assume BBSDev accepted it then routed it.

This didnt work :( I didnt get anything, well yet anyway...

I'm certain there's multiple errors there. :D

I found a few spelling errors and notice a grammar error as well. I was going to log into gitlab and comment there, so its easier to highlight them, but I got distracted...

I like the way you plan on handling new payloads, and had not thought about it that way for what I'm working on. I should have considered it, since I'm processing media files and they use a similiar approach for media atoms.

After some close examination, I have come to the tentative conclusion that you are right and 378 is *not* greater than or equal to 512... thanks, I'll update the doc.

Phew, I was worried I had messed up in primary school somewhere, and that there were some other ramifications, related to me handling numbers, that that I was unaware of... :)


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI

Re: TITHmailer
By: deon to Deuce on Mon Nov 17 2025 08:15 am

I like the way you plan on handling new payloads, and had not thought about it that way for what I'm working on. I should have considered it, since I'm processing media files and they use a similiar approach for media atoms.

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.

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.

With those three things in place, it should be possible to convince Synchronet with SBBSecho to do full 5D support using multiple sbbsecho.ini files. Once
that's working, I'll define the message format and replace SBBSecho. After that it's just a matter of fleshing out all the various maintenance robots, nodefix, filefix, areafix, etc.

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.
---
þ Synchronet þ The future of BBSing

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

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

Deuce wrote to deon <=-

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...

So, it sounds like this is more involved than maybe originally
thought...

So maybe the naming convention (This Isn't That Hard) should be
re-thunk, and changed to "This Isn't That Simple".

TITSMailer has a nice ring to it, and rolls right off the tongue. ;-)



... If it has tits or tires sooner or later it's going to give you trouble!
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL

Re: Re: TITHmailer
By: Gamgee to Deuce on Tue Nov 18 2025 08:17 am

Anyway just spit balling ideas without really thinking them through...

Yeah, that's how it begins...

So, it sounds like this is more involved than maybe originally
thought...

So maybe the naming convention (This Isn't That Hard) should be
re-thunk, and changed to "This Isn't That Simple".

TITSMailer has a nice ring to it, and rolls right off the tongue. ;-)

Heh, it'll still be FidoNet, so it certainly needs to remain complex. It's certainly a better name (TITHmailer is terrible). Alas, the TITH project already has "tith" in to many places for me to be arsed to change it.

That said, for the mailer, I can certainly go with "This Is That Simple" since the mailer will just take up to one bundle from here and put it there, and take up to two bundles from there and put them here. Of course, the server needs to parse the bundle on the fly, so it gets a bit complex again.
---
þ Synchronet þ The future of BBSing