ViSiON/3: An Experimental Take on BBS Networking
Art by Randers — ADFA / DiE / Shiver / Blocktronics / Lazarus
Where Networking Gets Interesting
A thing that made the scene feel like a scene, was message networks. FidoNet, in particular: a worldwide store-and-forward email system that ran on a combination of dial-up polling, ARC/ZIP compression, and the collective good faith of thousands of volunteer sysops who kept their machines on overnight so the mail could move.
It worked. Improbably (or inexplicably, to me as a newcomer) but it worked. And it still works — FidoNet is not dead and other Fidonet-based networks (like fsxNet, TQWnet, etc.) are not dead… there are active echomail areas in 2026 with real traffic.
FTN networking was designed for a world of analog land lines. Sure, we swapped phone lines for the internet, but getting a new node onto FidoNet still means acquiring a node number, configuring the network and mailer, polling events, importing NA files, etc. (a weekend of configuration, still an exercise in learning the vocabulary of a system designed before most current developers were born), and then maybe waiting for nodelist updates before a single message moves. The barrier is real. For a person who might be setting up their first BBS in 2026, it’s often the point where the whole project stalls.
And before the curmudgeons start with “if you can’t set up FidoNet, you shouldn’t be a sysop,” fine: you can go post that on DOVE-Net. Some of us are allowed to prefer better tooling.
OK, so the real story here is V3Net, a network stack that we’re building from the ground up for ViSiON/3. And to be clear up front: it’s experimental, it is not ready to replace anybody’s production FTN setup, and it does not try to. Let me paint a picture.
What V3Net Actually Is
At this point, I guess it’s a philosophical question. Is V3Net a new BBS message network? Or is it a new protocol for BBS message networking? The answer is both (maybe?).
FidoNet support in BBSs isn’t going anywhere.
But V3Net is what you might build when you ask: what would a BBS message network look like if it were designed today, from scratch?
The simplest answer is that V3Net borrows (somewhat) from the past: like WWIVnet’s ability for node admins to act as area admins, and some early ideas of “tag” based message routing in x84, with a dash of good old-fashioned exclusivity on a sysop-run infrastructure.
A more complete answer looks like this: Server-Sent Events (SSE) instead of dial-up polling and .PKT files. Ed25519 keypairs instead of nodelist entries. A five-minute setup instead of a weekend. And real-time events — logon notifications, inter-BBS chat, network-wide who’s-on lists — that store-and-forward protocols by their nature cannot provide.
The protocol in ViSiON/3 is deliberately minimal. Hubs serve a REST API. Leaf nodes poll for new messages and maintain a persistent event stream connection. Messages are JSON, carrying the fields you’d expect — from, to, subject, body, thread UUID, origin node — and they land directly in local JAM message bases. The API is not designed to be a general-purpose message transport, it tries to be the thing that BBS message networks have always been, but with the tools and assumptions of 2026 instead of 1993.
Just as important: V3Net is additive. ViSiON/3 will continue to support FTN echomail. If you’re already on FidoNet, fsxNet, or another FTN-style network, V3Net is not here to tell you to throw any of that away. It’s a parallel stack for sysops who want a lower-friction way to stand up a new network or join one.
The first named network running on V3Net will be felonynet… Does that ring a bell with anyone? The name is not accidental! The original scene had a particular relationship with authority. Not criminal (right???) but adversarial in the way that independent infrastructure always is. You ran your own machine. You set your own rules. Nobody could take it down by calling your ISP because you were your own ISP. V3Net doesn’t pretend to resurrect that exactly, but it’s not trying to be the ActivityPub of BBS networks either.
V3Net Principles
If you’re a sysop, I think the important parts of V3Net are these:
Built into the BBS, not bolted on. You shouldn’t need a separate mailer/tosser stack just to join a modern ViSiON/3-native message network. V3Net areas are still message areas. They still end up in JAM. The difference is that transport, identity and subscription management are built in.
Cryptographic identity instead of network folklore. Every node has an ed25519 keypair. The node ID is derived from that key. Requests are signed. Trust comes from verifiable keys and signed data, not from hoping a password file, nodelist and pile of side utilities all agree with each other.
The control plane is signed. The Network Area List, or NAL, is a signed JSON document that defines what areas exist, who manages them, and what access mode they use. Any node can verify that the copy it fetched is the real one.
Delegation is first-class. The network coordinator does not have to personally manage every echo. Area managers can approve subscriptions, deny abusive nodes, and maintain policy for their own area without routing every decision through one person.
Leaf nodes should be easy to run. A leaf node makes outbound HTTPS requests and holds an SSE stream open for events. In practical terms that means no inbound port requirement for leaf sysops and a much shorter path from install to moving messages.
Real-time is a feature, not a hack. Presence, notifications and inter-BBS chat are part of the same connection model as message networking, rather than a side-channel somebody glued on later.
Why This Is More Interesting Than It Sounds
The part of V3Net that’s worth paying attention to isn’t the API. APIs are boring. The part worth paying attention to is the area management model.
FTN networking concentrates authority. There’s a Network Coordinator who controls the nodelist. Usually a nice person, right? And there could be Area Managers who control individual echomail areas (increasingly rare). If an AM or NC disappears, it goes quiet. If an NC gets territorial, nodes get delisted. I REMEMBER those days… And I guess this hierarchy exists for good reasons — it provides structure in a system that has no other enforcement mechanism — but it also creates chokepoints, and chokepoints in volunteer-run infrastructure tend to become single points of failure.
V3Net takes a different approach. Area definitions live in a Network Area List — a signed JSON document that specifies every message area a network carries, who manages each one, and what the access policy is. The NAL is signed with the network coordinator’s ed25519 key, which means any node can verify its authenticity independently of wherever it was fetched from. A compromised hub can’t forge a valid area list. A rogue sysop can’t invent areas that don’t exist.
But here’s the more interesting part: coordinators can delegate. Individual areas can have their own managers — other sysops who hold their own keypairs. The coordinator signs the NAL that says “this person manages this area,” and from that point on, the area manager can set policy, approve or deny which nodes carry their area, and handle their corner of the network without involving the coordinator for every decision.
And if a coordinator wants to hand off the network cleanly, the handoff protocol lives in the software itself. A coordinator initiates a transfer from their sysop menu, the incoming coordinator redeems it from theirs, the NAL gets re-signed, and the network keeps running. No emails to send, no manual key distribution, no waiting for someone to update a nodelist somewhere.
Area access control is another piece of this. Area managers can set their area to open (any subscribed node can carry it), approval-only (the manager vets each request), or closed (invite-only). Moderated spaces, topic-specific areas, regional networks… the same mechanism handles all of it, without requiring any special casing in the protocol.
None of it requires a browser, an email or a netmail to a coordinator address. It all happens inside the BBS, in the sysop menu, over the same protocol that carries messages.
Some early screens from the CONFIG binary:
Coordinator, area, and subscription management screens in the current V3Net admin flow.
The Part About Real-Time
Here’s what FTN networking genuinely cannot do, regardless of how well it’s configured: tell you who’s online right now on a board three cities over. There are some mods out there that do that for Mystic, and someone-liner walls that aggregate posts from across the network in real time, but they all rely on hacks — using data areas to carry presence information, or using a separate chat area to carry who’s-on data. They’re not part of the core protocol, and they don’t work across different BBS software.
(I do think synchronet uses a “finger” protocol to query other nodes for who’s on, it’s more of a “who’s on right now?” than a “who’s on right now and will be notified when they log off?”)
In V3Net, the event stream that leaf nodes maintain with their hub isn’t just for message delivery notifications. It carries logon and logoff events. It carries inter-BBS chat. It carries the signal to update the area list when a coordinator adds a new area.
This means a network-wide who’s-on display is not a hard problem. An inter-BBS chat room that spans multiple boards is not a hard problem (and it’s not a mod or a door). A one-liner wall that aggregates posts from across the network in real time is not a hard problem.
These are features that would have required bespoke protocol engineering in 1994 — separate from echomail, incompatible with the existing toolchain, requiring their own mailer configurations. In V3Net they’re a natural extension of the same connection the leaf node already has open.
OK, so the BBS scene in 2026 is small. It’s a few hundred boards, maybe a thousand active users spread across all of them. Real-time presence changes what small communities feel like. Knowing that someone you recognize just logged onto a board in another time zone, and being able to say hello, is a different thing than reading a message they posted six hours ago. It’s the difference between a message board and a place. And it’s a great ad for other sysops.
What Still Needs Solving
It would be dishonest to pretend V3Net is finished just because the ideas are good. A few hard problems still remain:
Coordinator loss is only partly solved. V3Net has a clean transfer flow, and there is a manual disaster-recovery path for re-seeding the NAL after a keystore change. But if a coordinator disappears unexpectedly, the network can still end up with a governance and recovery problem.
Key management matters. Ed25519 keys are cleaner than passwords and nodelist trivia, but they create their own sysop responsibilities. If you lose your keypair, you lose your identity. Backup, rotation and recovery procedures need to be sharper than they are today (there are import/expot utils).
The hub is still a chokepoint. The signed NAL reduces trust problems, but V3Net is still hub-and-leaf. If the hub goes down, the network is impaired. Multi-hub replication, federation, or a cleaner failover story are still open questions.
Abuse control is only partly solved. Area managers can approve, deny and blacklist nodes, which is a good start. But spam handling, moderation workflow, and network-wide abuse response are social and technical problems, and they do not disappear just because the transport is nicer.
Leaf lifecycle management needs more definition. Joining a network is easy, but long-term subscriber hygiene matters too. Hubs need a clear story for stale nodes, manual decommissioning, inactive leaf pruning, and how to treat boards that disappear for months and then return.
Resync and retention policy need to stay boring and reliable. Sysops are going to ask what happens when a node is offline for a week, a month, or longer. How much history is retained, how backfill works, and what the operational limits are need to be documented and tested until they are boring.
User-to-user Mail Needs to handle the concept of “netmail.”
Why ViSiON/3, Why Now
ViSiON/3 has a specific answer to “what is this software?” that goes back to a specific moment in computing history… and the goal is to honor that while building something that can actually run in 2026.
V3Net fits that ethos precisely because it doesn’t try to make BBS networking into something it isn’t (like a web site). It makes the thing that BBS networking always was… distributed, sysop-run, community-defined, but easier to do, with the tools and assumptions of the current decade instead of 1993.
ViSiON/3 is on GitHub. It’s pre-alpha and it will crash. But if you’re interested in BBS software, or distributed systems, or just want to see what happens when you ask “what if we built a BBS today?” it’s worth keeping an eye on and/or doing a test install.
Join us on Discord if you want to chat about it, or if you want to help out.
ViSiON/3 BBS — vision3bbs.com — Join the Discord