A story about FidoNet nostalgia, a curious AI, and a project that got away from me in the best possible way.
THE EXPERIMENT
I ran BBSs in the 90s. If you were around then, you know what that means -- the hiss of a modem, the ritual of calling your uplink node in the wee hours of the night, the way FidoNet mail would tumble in like a slow, careful tide. When the internet ate the BBS world alive, most of us just moved on. But that particular itch never fully went away.
Fast forward to 2025. The AI conversation was everywhere, and I found myself curious about something specific: how would a modern AI like Claude handle something old? Not old in a "write me a poem in the style of Shakespeare" way, but old in a genuinely technical, protocol-level way. FidoNet and BinkP are not in any mainstream curriculum. The spec documents are text files from the 1990s. Would Claude even know what a .PKT file was? What about AREA: lines, or the INTL kludge?
I decided to find out. I chose PHP deliberately -- not because it was the obvious choice, but because I wanted to demonstrate something. PHP has a reputation as a web scripting language, but it's fully capable of daemon-based networking with nothing beyond its standard extensions. No PECL, no exotic dependencies. I'd written network daemons in PHP before and knew it could handle this. The experiment was about the AI and the protocol, not the language -- but PHP was a deliberate statement.
The prompt was simple enough: help me build a PHP-based BinkP node.
THE SHELL AND THE STACK
What came back was a surprise. Claude produced a working scaffold -- a BinkP mailer stack in PHP that, with some debugging and coaxing, actually connected to a real FidoNet uplink and exchanged mail. The initial commit, "Initial Commit," landed on August 24, 2025, and within the next few days the project had a working packet processor, a nodelist importer, basic echomail and netmail reading in the browser, and a user registration system.
The early commits tell the story of two things being figured out simultaneously: the FTN protocol quirks (TZUTC offsets, INTL kludge parsing, MSGID formats) and the practical scaffolding of a real web application. The database started as SQLite, because that's the path of least resistance when you're just experimenting. By August 28th, barely four days in, it had already migrated to PostgreSQL -- SQLite wasn't going to hold up.
A pattern emerged quickly. The AI would produce something that mostly worked, you'd run it against a real FidoNet link, and reality would surface the edge cases: authentication quirks with multi-address nodes, packet date parsing that went sideways because a remote sysop's clock was wrong, character encoding mismatches between CP437 and UTF-8 that made old messages look like abstract art. Each one of these became a commit. Each one was a negotiation between a 30-year-old protocol and a modern web stack.
One early commit stands out: "vendor has no business being in git. thanks claude." The composer vendor directory had been committed wholesale. This is the other thing you learn quickly when working with AI on a real codebase -- it writes code, not ops. You still have to know what you're doing.
THE PIVOT: FROM TOOL TO PLATFORM
Through September and October 2025 the project sharpened into something recognizable. Message threading landed. A proper address book for netmail. Echoarea subscriptions. Saved messages. Search. The REPLYTO kludge. Draft support. Analytics. A weather report script for piping content into echo areas.
The project had drifted, almost without a deliberate decision, from "FidoNet experiment" into "real BBS software." The name changed too -- from "binktest" to binkterm-php, and the product name BinktermPHP crystallized.
By this point there was a live instance running at mypoint.lovelybits.org -- connected to a real FidoNet uplink, operating as a point system hung off an existing Synchronet board.
JANUARY 2026: THE MULTINETWORK EXPANSION
The first major architectural milestone came in January 2026: multi-network support. Until this point, the system handled one FTN network. The commit message on January 21st reads plainly: "WIP - multinetworking for echomail and binkp." Within two days, it was done -- full multi-network routing and packet filtering, per-network echo area tags using the tag@domain convention, and domain-scoped nodelist management.
This was also the moment the project got its first real deployment. claudes.lovelybits.org came online in January as a dedicated node with its own FidoNet address -- no longer a point hanging off my Synchronet board, but a node in its own right. A sysop could now maintain uplinks to multiple networks simultaneously -- LovlyNet, Fidonet, or any other FTN network -- with each echo area cleanly scoped to its originating network.
January also brought the WebDoor framework. This was the feature that tipped the project from "FTN client" into "BBS." A WebDoor is a sandboxed web application -- a door game in the classic BBS sense, but running in the browser. The first doors were Wordle, Blackjack, Solitaire, and Hangman. The terminal itself became a WebDoor. Gateway tokens let external door services authenticate users without exposing credentials. A credit system gave the economy a backbone.
The telnet daemon arrived in earnest in January as well -- a full server-side terminal BBS accessible via Telnet, complete with ANSI rendering, menus, and echomail/netmail reading. The project now had three distinct access surfaces: browser, API, and terminal.
FEBRUARY 2026: DOS DOORS AND THE FULL STACK
February was the month BinktermPHP earned the right to call itself a full BBS stack.
The DOSBox door bridge landed -- a multi-user DOS door integration that lets classic DOS BBS games run as web-delivered sessions, complete with DOOR.SYS drop file generation, concurrent session management, and a WebSocket bridge connecting the browser to the running DOS process. Barren Realms Elite, LORD -- the classics were back, running in a headless DOSBox instance, served through a browser.
At the same time, file areas arrived: upload/download support with ClamAV virus scanning, TIC file processing for FTN file distribution, per-area rules, and domain-scoped permissions. A proper BBS file section.
The MRC (Multi Relay Chat) WebDoor came in February too, connecting BinktermPHP instances to the MRC chat network. And the Gemini Capsule server launched -- making BinktermPHP's echo areas accessible to Gemini browsers, giving the project a presence on the small internet.
The SSH daemon, the admin daemon (a separate process for safe config writes from the web layer), LovlyNet automatic network registration -- February was dense.
MARCH 2026: POLISH, QWK, AND THE LONG TAIL
March brought integration depth. The QWK offline mail format -- a format from the very BBSs of the 90s -- was implemented, letting users download a packet of messages, read them offline in a QWK reader, write replies, and upload a REP packet.
The BBS Directory launched -- a geocoded, searchable list of active BBSs with a Leaflet map, individual BBS detail pages, and Gemini exposure. An echomail robot framework arrived for automating content processing such as test auto responder robots and extracting BBS data into the new BBS directory from automated "last call" reports.
The French locale landed, starting the i18n work that would eventually cover Spanish, Italian, German, and more. The MCP server (a Model Context Protocol server for AI assistants) shipped, making BinktermPHP's echomail archives queryable by AI tools.
Interests -- user-defined topic preferences that filter echo area subscriptions -- landed in March, giving users a way to navigate a large message base without drowning.
APRIL-MAY 2026: AI, MESH RADIO, AND WHAT'S NEXT
April 2026 brought AI assistants to the BBS itself -- not just as a development tool but as a feature. A per-message AI assistant landed mid-April, letting users invoke AI help directly while reading or composing messages, with support for multiple providers including OpenAI, Anthropic. A RAG-based support bot using embeddings followed. The irony is not lost: an AI-assisted project now has AI as a first-class citizen for its users.
JS-DOS doors shipped -- WASM-based DOS emulation directly in the browser, no server-side DOSBox required. The door game catalog expanded to include browser-native options alongside the server-relayed classic sessions, like Doom!
And then, most recently: PacketBBS -- a mesh radio interface that exposes BinktermPHP's echomail and netmail to Meshcore and other RF networks. Short-form BBS commands over LoRa radio: READ, POST, LIST areas, DM. Authenticated sessions. Local chat rooms bridged to the mesh. AX.25 TNC/KISS interface support. The BBS, which started as a web wrapper around an internet protocol from 1984, now speaks to battery-powered LoRa radios in the field.
LESSONS LEARNED
Working with AI on a project like this teaches you things that are hard to learn any other way.
The AI knows more than you expect, and less than you need. Claude had genuine knowledge of BinkP, FTN packet formats, and CHRS kludges -- knowledge that surprised me. But it would also confidently produce code that worked in isolation and broke against real network partners. The protocol knowledge was real; the testing was not. Every claim had to be verified against an actual FidoNet uplink.
Commit messages are honest. Reading through nine months of git history, the AI-written commits are mostly clean and descriptive. The human-written ones are where things got terse or frustrated: "maybe fix sharing" appears three times in a row in September 2025. That's what debugging a sharing URL across different proxy configurations actually looks like.
The project grows toward what you need. No one sat down and designed BinktermPHP as a full BBS stack with DOS doors and mesh radio integration. Each feature was added because something was missing, or because a user on the live instance needed it, or because a protocol was already halfway implemented and the rest was obvious. The architecture followed the use, not the other way around.
Old protocols reward patience. FTN is full of implementations that disagree, edge cases that only appear with specific remote systems, and underdocumented behaviors that sysops discovered empirically in the 1990s. None of that is in any training set. Getting things right meant running packets, reading the actual FTS specifications, and sometimes just trying things until they worked.
The rename matters. Going from "binktest" to BinktermPHP was a small thing operationally and a large thing psychologically. It was the moment the project stopped being an experiment and became a product with a name, a mascot (Kludge the Corvid), a support BBS, and a Reddit community.
WHERE IT STANDS
BinktermPHP is now a full self-hostable BBS platform. A sysop can stand up an instance, connect it to one or more FTN networks, run door games (browser-native or classic DOS), host file areas, serve a Gemini capsule, accept QWK mail clients, bridge to mesh radio nodes, and offer a real-time browser-based community interface -- all from one PHP application.
It started as a question: how well does a modern AI understand a 40-year-old protocol?
The answer, it turns out, is: well enough to build something real. The rest was iteration.
BinktermPHP is open source. The live support BBS is at claudes.lovelybits.org. The project page is at https://lovelybits.org/binktermphp.
Leave a Comment
No comments yet. Be the first to comment!