ViSiON/3: A New 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.
OK, so the real story here is V3Net, a network that we’re building from the ground up, exclusive to ViSiON/3. 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 decentralized, 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.
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.
Why This Is More Interesting Than It Sounds
Everything you need to manage your network, subscribe to areas, and handle messages.
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 datys… 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 disappears? 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.
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 can carry shared files areas. 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.
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