How does your league move its mail?

[andy5995]

Written by Claude (Opus 5), an LLM made by Anthropic, and posted at andy5995's direction.

Immortal Barons is a from-scratch clone of Barren Realms Elite, so it has to move packets between the boards in a league. BRE did that by writing a netmail with the packet attached and handing it to the sysop's mailer, which addressed and routed it from there. IB instead writes packet files into an outbound directory and leaves moving them to whatever the sysop already runs.

We would rather check that choice against how leagues are actually run today than keep reasoning about it from 1990s documentation.

What a board is configured with now

Everything describing the board itself is a plain text file, bbs.cfg, in the game's data directory:

BoardID       Avalon
LeagueNumber  900
Inbound       /home/bbs/ftn/in
Outbound      /home/bbs/filebox/uplink

Inbound is wherever your mailer drops incoming files. Outbound is one directory whose contents want sending to one other board — a filebox, a BSO directory, whatever your setup calls it. A board that relays for its neighbours adds a line per neighbour:

Link 3        /home/bbs/filebox/node3
Link 5        /home/bbs/filebox/node5

The league's own rules live elsewhere and arrive from the Coordinator, so nothing above is ever changed from outside your board.

What we would like to know

1. When a board joins your league, what do you actually have to change on your own system?
2. Does your league route through a hub, or does every board exchange with every other one directly?
3. What moves the mail — binkd, Mystic's binkp, something else? Does it handle file attach and file routing, or only echomail and netmail?
4. Looking at the file above: is a directory per link what your setup wants, or would you rather name your netmail directory once and have the game address each packet so the mailer routes it?
5. Does every board in your league have an FTN address? Do you know of anyone who would want to join a league without one?

Some things worth putting on the table

• A board does not need an FTN address to play IB. Packets are ordinary files, so a league can move them with scp, a sync tool, or a shared mount. Whether anybody actually wants that is question 5, and the answer decides whether it is worth keeping.
• BRE supported six mailers because each of them wanted something different. If everyone has since settled on Binkley-style outbound, writing that directly is far less code than what IB does instead.
• A league can be arranged as a tree rather than every board linking to every other one, using HOST lines in the node list as BRE did. Question 2 is whether any real league is shaped that way.

The goal is information rather than a decision. If the FidoNet path fits how people run leagues, IB should probably be using it.

[xbit44]

I run my BRE InterBBS league using the traditional old-school FrontDoor-style netmail/file-attach method.

My BRE BBS.CFG is set to FRONTDOOR. When BRE creates outbound InterBBS data, the actual game packet is placed in BRE's OUTBOUND directory. BRE also creates a *.MSG netmail message in Internet Rex's netmail directory which references that packet as a file attach and is addressed to the appropriate FTN node.

My mailer is then responsible for the FTN transport/delivery of that file attach. On the receiving system, the mailer places the received BRE packet in the configured inbound files directory, and BRE processes it with its INBOUND/PLANETARY processing.

So in my case I do not configure a separate outbound/filebox directory for every league member. I give BRE a single NetMail directory and let BRE create addressed .MSG file attaches; the FTN mailer handles getting those attached files to their destinations.

The terminology I would use for my setup is FrontDoor-style .MSG netmail file-attach transport. BRE creates and processes the game data packets; Mailer transports the file attaches.

I hope this option is available for Immortal Barons, since it matches how my existing inter-bbs league is already operating. But, it is 2026 so i'm excited to see other options as well.

[andy5995]

I hope this option is available for Immortal Barons, since it matches how my existing inter-bbs league is already operating. But, it is 2026 so i'm excited to see other options as well.

@xbit44 Hopefully after #121 has had more discussion, we'll see what a final design looks. I'd definitely want you to be satisfied with any system that completely changes the process you and other sysops have been using for BRE.

[RealDeuce]

Answers

1. When a board joins your league, what do you actually have to change on your own system?

I need to configure the DNS (pN.fN.nN.zN.bbsdev.net) with a CNAME pointing to the system, and configure the various passwords needed for moving netmail. For every game the board joins, I need to update the game with the new board and publish that to the rest of the games in the league.

2. Does your league route through a hub, or does every board exchange with every other one directly?

I'm not sure what level you're asking about here. The fundamental basis of FTN is that every board can exchange netmail with every other board, even if the topology is a star. From the FTN perspective, I have a mostly star-shaped tree with the majority of systems directly exchanging with each other and a couple systems that require their mail to be routed. This is transparent to the games though.

From the games perspective, this varies by game. Many simple games only send netmail between the the node and "the hub" and will only process netmail from the hub. Games which wish to exchange netmail with other nodes may do so directly on my network... I have never used game-level routing.

3. What moves the mail — binkd, Mystic's binkp, something else? Does it handle file attach and file routing, or only echomail and netmail?

On my side it's generally BinkIT, but modified to establish trust.

4. Looking at the file above: is a directory per link what your setup wants, or would you rather name your netmail directory once and have the game address each packet so the mailer routes it?

My setup wants to deliver netmail and supports netmail file attach. That config does not appear to have the netmail directory configured. Giving the door enough information to put complete ready-to-deliver packets in the outbound would be a huge pain point.

5. Does every board in your league have an FTN address? Do you know of anyone who would want to join a league without one?

Yes, the FTN address is the fundamental ID for a board. Things like BBS name and Sysop name are fungible metadata.

Looking at the table

A board does not need an FTN address to play IB. Packets are ordinary files, so a league can move them with scp, a sync tool, or a shared mount. Whether anybody actually wants that is question 5, and the answer decides whether it is worth keeping.

While a packet is an ordinary file, the netmail is a metadata file that attests to the trust chain. Without the attestation from a netmail message, there is no way to tell if a packet is valid or came from the claimed system. Naively using scp, a sync tool, or a shared mount enables trivial cheating.

BRE supported six mailers because each of them wanted something different. If everyone has since settled on Binkley-style outbound, writing that directly is far less code than what IB does instead.

Even BSO has multiple variants with features such as outboxes. Supporting BSO and Frontdoor in the same code is really only minor differences, so while I haven't looked at "what IB does", the "far less code" claim doesn't really stand up to the sniff test.

A league can be arranged as a tree rather than every board linking to every other one, using HOST lines in the node list as BRE did. Question 2 is whether any real league is shaped that way.

Again, I'm not sure if you're talking about a single game routing each packet through each game in a separate topology (sometimes encountered in IBBS doors) or if you're talking about the netmail system it travels over. The two are different layers, and the FTN layer inherently provides every board linking to every other one. I do currently run games in my league that make use of the fully-connected nation of an FTN network, but "the league" must be fully connected to be an FTN network.

[andy5995]

Again, I'm not sure if you're talking about a single game routing each packet through each game in a separate topology (sometimes encountered in IBBS doors) or if you're talking about the netmail system it travels over.

Thanks @RealDeuce . The reason some of the questions are confusing is because Claude is still learning about the process, and I never had any experience setting up IBBS BRE or anything FTN related. The responses so far by you @xbit44 should definitely help fill in the gaps.

[RealDeuce]

As a separate follow-on, if you're looking at developing a new way to move game packets, I have many thoughts on the subject... if a game were to digitally sign packets, and there was a way to isolate storage so BBSs can't overwrite/corrupt/delete packets to/from other BBSs, the attestation provided by the netmail could be unnecessary. There are various ways to distribute public keys and establish trust which could be adapted easily, and it's relatively simple to name packets on arrival. The public key could replace the FTN address as the durable ID, and there would no longer be anything unique provided by FTN. This is somewhat more than "packets are just files" though.

[andy5995]

I'm definitely open to "modernizing" things if it makes things simpler. My two chief concerns are: I'd need humans to review code for security issues, and I'd need humans to discuss the design with. I have little experience in the area. So far you and @xbit44 are helping me along brainstorming the design very nicely. Here's a related issue I just opened: #118

[andy5995]

As a separate follow-on, if you're looking at developing a new way to move game packets, I have many thoughts on the subject...

@RealDeuce I've started #121 to hear any more of these thoughts you may have. I hope you guys don't find these Claude posts too annoying or off the mark. I'm not a great technical writer and not familiar with the subject.

[xbit44]

I'm currently looking into joining BRE 999. They use a very new method. i've yet to have time to look into it much.

PowerShell built for my win10/32bit OS:
https://github.com/lime-red/nova-client/releases/tag/0.3.0

https://github.com/lime-red/nova-client
https://github.com/lime-red/nova-hub/blob/main/docs/API.md

[andy5995]

Written by Claude (Opus 5), an LLM made by Anthropic, and posted at andy5995's direction.

Three things in the opening post were wrong.

• "Packets are ordinary files, so a league can move them with scp or a shared mount." The netmail-attestation point landed hardest. Immortal Barons checks a signature only on the parts the Coordinator authors; everything else is applied on the strength of a board-name field, so a file dropped in an inbound directory can grant a realm an army or take land from a real player. The game was leaning on the transport for something it never asked the transport to provide. Now issue A packet's sender is never verified, so anything but Coordinator orders can be forged #118.
• "Writing Binkley-style outbound directly is far less code." Written without having looked at either. Withdrawn.
• Question 2 was two questions, game-level routing and the FTN topology underneath. The answer to the one that was meant — has anyone used game-level routing — is no, which is the useful part.

The distinction it forced is content versus origin. Whether a board's figures are honest is not fixable and never was. Whether a packet came from the board it names is, and was not being attempted; the first being hopeless is no reason to skip the second.

On signing packets so the attestation is unnecessary — worth taking, and the game already has ed25519 and a one-time key exchange for the Coordinator, so it is one key to a key per board rather than starting cold. The half with no obvious mapping is storage isolation. What does "boards cannot overwrite or delete packets to and from other boards" mean for a door that owns a directory on the sysop's own machine — non-colliding packet names, write-once on arrival, something at the filesystem level, or is it a property of the transport rather than the game? That is the part guesswork would get wrong.

Also read the nova-hub docs and client: a transport around the unmodified original rather than a new protocol, and its hub verifies an uploaded packet's source index against the uploading account — so origin is enforced there too, at the hub rather than in the packet.

[RealDeuce]

What does "boards cannot overwrite or delete packets to and from other boards" mean for a door that owns a directory on the sysop's own machine — non-colliding packet names, write-once on arrival, something at the filesystem level, or is it a property of the transport rather than the game? That is the part guesswork would get wrong.

With FTN, it's a property of the transport, though different packages handle it in various ways (and some don't handle it)... the mail may be refused or the filename may be rewritten to avoid collision. The second option tends to break IBBS games, which generally depend on the filename to identify source and destination nodes.

[lime-red]

Before nova-hub I was using filebox, and that influenced the thinking around it.

The point of nova-hub is a drop-in replacement for FTN transit. The game itself does not need to be aware of nova-hub. However if you want to make IB take an active role in the packet exchange, you could pinch or absorb what nova-hub does.

[lime-red]

Another option is to tailor nova-hub (or your adaptation of it) to work in a blended fashion.
Currently nova-hub assumes everyone in the league is going to use it. We could also add an option to tell nova-hub to leave certain boards' packets alone, and use filebox/whatever else to move them instead. The distributed and stateless nature of the packet transit means this can work transparently.

[andy5995]

Thanks, everyone!