IB signs its packets now — what should move them?

[andy5995]

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

Discussion #117 asked how leagues move packets today. The answers moved the question on, so this is a separate thread for what it became: if Immortal Barons signed its own packets, what should carry them, and would any of that be less work than what sysops run now.

What #117 settled

• Both respondents run FTN — one with FrontDoor-style .MSG netmail carrying the packet as a file attach, the other with BinkIT over a mostly-star topology. Neither has ever used game-level routing.
• A per-link outbound directory is the wrong shape, from both directions: one gives BRE a single netmail directory and lets the mailer address each attach, the other called ready-to-deliver packets in the outbound a huge pain point.
• The netmail attests to where a packet came from. IB leaned on that without asking for it or checking it, which is issue A packet's sender is never verified, so anything but Coordinator orders can be forged #118.

The pivot

IB trusts whatever moved the file, and that is what makes the transport load-bearing. Sign the packets and the mover is untrusted by construction. FTN, a server, scp and a shared mount all become acceptable, and the choice stops being about security and becomes about work.

@RealDeuce put the consequence directly in #117:

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.

Read straight, that says IB needs no new transport at all. Keep the file drop, sign the packets, and every sysop goes on moving files the way they already do. Nothing to host, no .MSG writer, no network code in the game, and a board's identity stops depending on being on somebody's network.

Four things need filling in before it can be built:

• Which key-distribution scheme. "Various ways… which could be adapted easily" implies specific ones, and BinkIT modified to establish trust is one that already works in this world. IB's own candidate is weaker: the Coordinator's roster is signed and already broadcast, so it could carry a key per board, but a board joining mid-season then has nothing to verify its first roster against.
• What storage isolation means without FTN. With FTN it is a transport property — the mail is refused, or the filename is rewritten. A server answers it with ordinary file permissions. A league that keeps the plain file drop has no equivalent, and that is the case guesswork would get wrong.
• What "name packets on arrival" should look like. IB reads a packet's source and destination from inside the file rather than from its name, so a renamed packet still applies. Whether the naming should also be specified, and what that buys, is open.
• Whether signing alone is enough to drop the netmail. The claim is that it is. What remains is withholding rather than forgery, and whether that matters in a game where a missing packet looks the same as a board that did not play is worth an opinion from someone who has run leagues.

If a league wants a server anyway

It would be a mailbox: take a packet from a board that can prove it is that board, hold it until the addressee collects it, stop boards touching each other's. It never opens a packet or knows the rules.

Signing takes the weight off the first job, so what is left is authenticated file storage with per-board access control. Existing servers are already that:

• sshd, used as sftp. An account and an inbox directory per board, unix permissions doing the isolation, and most candidate hosts run one anyway.
• A Synchronet board. Synchronet has an SFTP server of its own, riding the terminal SSH server and toggled in SCFG — ALLOW_SFTP, "Allow logins via BSD SFTP". Callers authenticate as BBS users, and a user's ~/.ssh/authorized_keys maps to their sshkeys file, so key auth works with no unix account. What it exposes is the filebase rather than a filesystem, which means the drop area would be a file directory and the per-board isolation would be that directory's access requirements — something a sysop already knows how to set up. Two things I have not checked: whether a directory can be restricted so each board sees only its own inbox, and what the filebase does to a file on the way through.
• WebDAV or a small HTTPS service, where firewalls are the problem, at the cost of a certificate and something to maintain.

Mystic is not a candidate for the server side: as of 1.12 A48 it has no SFTP, and SSH there is a terminal type only. Its server list is Telnet, RLOGIN, SSH, BINKP, FTP, NNTP, POP3, SMTP and HTTP, so FTP or BINKP would be the way in if a Mystic board hosted. As a member board it needs nothing special either way.

A member board needs only a client either way, and for the sftp options that is one every OS already ships.

What a league then costs to run. The FTN columns are reconstructed from #117's answer about joining a league — a DNS CNAME, the netmail passwords, then updating the game with the new board and publishing it — so corrections are more useful than agreement.

The rows are split by how often the work comes back, because that is where the options differ. Joining is paid once; everything under it is paid again each time the league grows.

	FTN, board already on a network	FTN, board not on one	A league server
Once — sysop joins	Name the netmail and inbound directories in IB	Apply for an address, wait for a node number, set up DNS, install and configure a mailer, agree session passwords with an uplink — then name the directories	Point a sync job at the server; IB still reads and writes local directories
Once — waiting on anyone outside the league	Yes — address assignment, and an uplink willing to link	Yes	No
Each time a board joins — existing members	Learn the new board's address, and link with it if they do not already	Same	Nothing
Each time a board joins — Coordinator	Record the address, add it to the roster, publish	Same	Create an account, add it to the roster, publish
New code in IB	A .MSG writer	Same	None

If those columns are right, first-time setup is close to even for a board already on a network — one config line either way. The large one-off saving belongs to a board that is not on one: days of human process against an account and a password.

The recurring rows are the ones that decide it. A league that grows to ten boards pays the FTN rows nine more times, across every member, while the server rows stay with the Coordinator. That is the part a snapshot of one board joining hides, and it is the part that matters for making IB easier to run than the original rather than merely as easy.

A server's costs are plain. Somebody hosts it, and it is a single point of failure. The Coordinator provisions an account per board. A hostile or compromised host can withhold traffic, and signing does not fix that.

If IB talked to a server itself

The table above assumes the sysop's sync job moves the files and IB never touches the network. The alternative is IB doing it — which is what @lime-red suggested in #117, that IB could absorb what nova-client does. Its method, read from that client and the published API, is small enough to sketch:

1. POST /auth/token with client credentials; the reply is a bearer token, good for a day, carried on everything after.
2. GET /leagues/{id}/packets?unread=true — the server lists what is waiting, knowing who you are from the token.
3. GET each one into the inbound directory.
4. PUT each outbound packet as application/octet-stream, then delete or file the local copy.
5. Run the maintenance pass.

The detail worth copying rather than the shape: a filename from the server becomes a path on your disk, so it is reduced to a basename, rejected if that differs from what arrived, and then required to match a known pattern. That check happens twice.

In Go this is net/http and encoding/json with no dependencies. IB would define its own endpoints — there is no existing league to be compatible with — so the numeric board index and filename convention nova-hub uses are not inherited, and identity stays inside the packet.

The cost is the credential and the client. IB would listen on nothing, so the exposure is narrow: keep the secret safe, and treat every response as coming from a host that might be compromised.

Questions

1. For a board that already has FTN working: would an account on a league server be fewer steps than what you run now, or more?
2. For a board that does not: is getting an FTN address a real barrier to joining a league, or does every sysop have one anyway?
3. Would a League Coordinator host a server, or is that the step that kills the idea?
4. If IB signed its packets, does that change what you would want the transport to be?
5. Is there a shape not on this list?

An answer that ends in "use the thing that already exists" is a fine answer.

[andy5995]

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

Before anyone spends time on the questions at the bottom — @RealDeuce, @xbit44, could you check the two FTN columns in the table? They are reconstructed from #117 rather than measured, and the post's conclusion rests on them. If joining over FTN really is one config line for a board already on a network, a league server saves existing members nothing and the idea only matters for boards with no address.

• Board already on a network: is "name the netmail and inbound directories" the whole of it, or does a new board also need a link or a password arranged with someone before packets move?
• Board not on one: is that list right, and how long does it take in practice?
• Coordinator row: is recording the address and publishing the roster all of it, or is there per-member work missing?

Corrections are worth more than agreement here — if the table is wrong, so is what it concludes.

[RealDeuce]

Generally when a node is added to a game, the league coordinator adds a small amount of data to a "WORLD.NDX" style file and send that file off to all nodes in the game (including the one that just joined). The node configures at least the game and sometimes some additional mailer/tosser/scanner bits.

For the league coordinator it's trivial work because they know how to do it. Getting a BBS configured can take multiple tries and active support from the LC.

[andy5995]

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

@RealDeuce, @xbit44 — the table has been reworked and the row that matters most is the one I am least sure of, so it is worth asking before anyone answers the questions at the bottom.

The FTN columns are reconstructed from #117 rather than measured. The one-time rows I am reasonably confident in. The recurring row is inference: reading "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" as meaning that when board eleven arrives, the other ten each have work to do.

• Is that right? When a new board joins an established league, what does an existing member have to do — nothing, learn an address, arrange a link, or something else?
• Is any of that automatic, from a nodelist or the mailer rather than by hand?
• For first-time setup on a board already on a network, is naming the netmail and inbound directories genuinely the whole of it?

If the recurring cost is near zero in practice, the case in the post gets much weaker, which is worth knowing now rather than after someone builds something.

[RealDeuce]

Only the LC system and the new node generally need any configuration. The game itself will propagate the announcements.

[lime-red]

BRE and FE both rely on an FTN address in order to tell boards apart. I'll use BRNODES.DAT to mean both that and FENODES.DAT, since it's tiresome to type out both each time.

The entry in BRNODES.DAT is keyed by the FTN address, linked to the entry in BBS.CFG to work out which one you are.
It doesn't matter if the address is fake, as long as can be matched up. For what it's worth, I gave Eclipse BBS a fake address within MedusaNet :}

In terms of what other boards need to do, the only other board that needs to change anything is the co-ordinator, who adds you to the BRNODES.DAT. The game then takes care of distributing that out (if using FTN mailer), or one must move the file themself (if using Filebox). nova-hub takes care of it in the filebox style.

This is a mirror of sorts of the FTN nodelist. The co-ord will update the nodelist, and press the button that sends it out to all. Until then, receiving boards may know your address but they won't be able to resolve the address without the updated nodelist.

For first-time setup, that's right, that is it. On an FTN transit network, the packets will arrive all in one place. Either the mailer will move them around, or you just point your game at that inbound folder and it'll pick out the files it wants and leave the rest.

[RealDeuce]

Fundamentally, what an IBBS games strictly requires:

1. A durable ID for each node. Sometimes, this is the network address, though most games have their own ID and associate the FTN address to that.
2. A way to deliver a file to a specific durable ID. If the game is a straight hub and spoke, this means it only needs to be able to upload a file to the hub. This is the main purpose of the FTN address.
3. A way to receive a file delivered by another node.

Pretty much everything else is game defined or exists for the traceability.

While preventing cheating in an open source IBBS game is a fools errand, ensuring the league coordinator can reliably determine what node is cheating and cut them out of the game is the basis of any enforcement plan. In traditional FTNs, this is provided by the FTN infrastructure and so many logs.

With public keys and signed packets, it can look a lot different. The public key itself is the ID... or there's a game-specific 1:1 mapping of ID to public key. The signature clearly defines the source of the packet so a detected cheater can be looked up by public key and removed from the game without needing to search through logs. It no longer matters how the files move, but having the coordinator host a simple service that allows POST/GET style semantics with public key auth and route everything through that is what I would reach for if I was designing something from scratch. I would want to make it a generic service where the POST/GET would include metadata indicating a game ID of some sort.

[andy5995]

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

The recurring-cost row was wrong, and it was the row the post's conclusion rested on. Correcting it here rather than editing the post, so the reasoning stays readable.

@RealDeuce:

Only the LC system and the new node generally need any configuration. The game itself will propagate the announcements.

@lime-red:

the only other board that needs to change anything is the co-ordinator, who adds you to the BRNODES.DAT. The game then takes care of distributing that out.

So when a board joins an established league, existing members do nothing. The corrected rows:

Each time a board joins	FTN	A league server
Existing members	Nothing — the game propagates the roster	Nothing
Coordinator	Add the board to the roster, publish	Create an account, add to the roster, publish

That removes the argument the post was built on. A league server saves existing members nothing, because there was nothing recurring to save, and the Coordinator's row gains an account to provision. What survives is the one-off cost for a board with no FTN address — and @RealDeuce puts a limit on that too: the LC's side is trivial because they know how to do it, while "getting a BBS configured can take multiple tries and active support from the LC". That is work in the mailer, which a change to IB cannot remove.

What the thread did settle

Identity. @RealDeuce: "The public key itself is the ID... or there's a game-specific 1:1 mapping of ID to public key. The signature clearly defines the source of the packet so a detected cheater can be looked up by public key and removed from the game without needing to search through logs." @lime-red closes the other end — the FTN address was never a durable identity to begin with: "It doesn't matter if the address is fake, as long as can be matched up."

Distribution. It needs no new mechanism. IB already broadcasts a Coordinator roster signed with the key every board records once by hand (-coord-key). A public key per board rides that same path, and the bootstrap step is one a sysop already performs.

Together those answer the two questions the post listed as blocking, which makes the signing half — #118 — buildable now, without settling the transport at all.

Still open

• Storage isolation, once FTN is not the thing providing it.
• Whether packet naming on arrival should be specified. IB reads source and destination from inside the file, so a renamed packet already applies correctly; what a convention would buy is the question.
• Withholding. Signing stops forgery and says nothing about a host or peer quietly dropping traffic. In a game where a missing packet looks the same as a board that did not play, whether that matters is worth an opinion from someone who has run a league.

On a coordinator-hosted service

@RealDeuce would reach for one — POST/GET with public-key auth, generic, with a game ID in the metadata. Worth recording that it is framed as designing from scratch, and as generic infrastructure rather than something a single game ships. IB would be a client of such a thing if it existed, which is a decision that can wait until it does. Nothing in the signing work depends on it either way.

[andy5995]

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

The "if" in the original title is now a "does", so I have retitled the thread. Packet signing shipped — #118 is closed — and that resolves the question this discussion was pivoting around. Everything below is what actually landed, so the remaining questions can be asked against a real thing rather than a proposal.

What shipped

Every board signs every packet with an ed25519 key of its own, and a receiving board verifies it before applying anything. Two mechanisms with deliberately different trust roots:

• coord.key / coord.pub — the Coordinator's key, recorded once by hand. This is the anchor, and its only job is to make the roster trustworthy.
• board.key, with the public half carried in the roster — distributed inside that signed roster. This is what makes every other packet trustworthy.

The chain closes: a sysop records one key out of band, and every board key after that arrives inside something already verified.

That is worth spelling out because the original post rejected IB's own candidate scheme on exactly this point — "a board joining mid-season then has nothing to verify its first roster against." It doesn't, if the roster is expected to verify itself. The out-of-band Coordinator key is the fix, and it costs a sysop one paste at join time.

Two related changes landed alongside it. A packet now carries the roster's node number for each end and the key is matched on that rather than on the board's name, so two boards cannot collide on a name and a rename does not break verification. And a reset advances a generation marker, so a packet left over from a cleared game is discarded rather than applied to the new one.

What this does and does not buy

@RealDeuce's point in #117 was that signing makes the transport untrusted by construction, and that is now the case: the mover cannot forge, so FTN, a server, scp and a shared mount are all equally acceptable and the choice becomes purely about work.

What it does not do, and cannot:

• It does not vouch for the figures a board reports about itself. Origin is not honesty. A board can sign a perfectly authentic packet full of invented scores.
• It does not stop a transport quietly withholding traffic. That was open question 4 in the original post and it stays open — a missing packet still looks the same as a board that did not play.
• It does nothing about storage isolation. With FTN that is a transport property; with a plain file drop there is still no equivalent.

What is still worth answering

The cost table in the original post is unchanged — signing does not move any of those rows. So the questions that matter are the ones only sysops can answer:

1. For a board that already runs FTN: is an account on a league server fewer steps than what you run now, or more?
2. For a board that does not: is getting an address a real barrier, or does everyone have one anyway?
3. Would a Coordinator host a server, or is that the step that kills it?
4. Given the packets are signed, does withholding matter enough to want a transport that makes it visible?

"Use the thing that already exists" remains a fine answer — and it is now a cheaper one, because keeping the plain file drop no longer costs any security.

[RealDeuce]

What's important and what any league coordinator should be able to do themselves:

1. Given a packet, discover the source and destination node(s) per the in-game ID list. This should be designed with an eye to integrating in automation flows.
2. For FTN networks, an authoritative ID to FTN address mapping should be distributed by the LC. Something similar will be needed for any fully-connected mesh design, so making this generic would be useful. The "address" should be an arbitrary string.
3. For FTN networks, something that takes the authoritative mapping and generates MSG files.

Including automation for the already existing nova-client/nova-hub allows supporting more existing leagues and validating that the tooling is sufficiently generic.

People have also ran leagues over email attachments and via FTP in the past. Basically, with a generic documented mapping, the problem of actually moving the files should be simple for the LC to solve, with pre-packaged solutions for existing methods.

A unique bespoke method should only be considered if requirements suggest it.

[RealDeuce]

Also, a well documented method of triggering packet import and possibly packet export. You want to make sure that each step is atomic so things aren't transferring incomplete packets or importing a packet while data is being mutated etc. When generated packets are finalized, there should be an atomic operation that makes them available to be moved. For import, there's should be a way to indicate a packet is ready for import. Simple existence checks can lead to impossible to debug race conditions.

For export, the game could do an atomic export for every network operation, or there can be a maintenance task that triggers it, this is completely internal to the game. The important thing is that the handoff to the schlepping service be well documented. This should take into account weird filesystem edge cases (such as classic NFS without locking).