Project overview · actively developed

What NetBBS actually is

NetBBS is a modern, TCP/IP-native bulletin board system — the dial-up-era style of text-based, multi-user server, rebuilt for today's internet instead of a modem bank. It runs as a complete, standalone BBS on its own, or meshes with other independent nodes over NetBBS Link, an ad-hoc peer network with no central server or registry required.

Ready to run one? → View on GitHub Call ReLink in your browser

Where things stand

What works today.

A complete standalone BBS, with networking and games you can enable as your community grows. The remaining validation limits are part of the picture too.

Standalone BBS

Available

Message boards, file areas with browser and Zmodem transfers, live chat, personal mail, Communities, search, moderation, staff permissions, access levels you can read and rules that promote accounts automatically, menus and lists drawn as the SysOp's own ANSI art, and a built-in SysOp console, for modern UTF-8 terminals, classic CP437 terminals and plain ASCII alike.

NetBBS Link connectivity

Implemented

Peer discovery, shared message boards, chat channels, file catalogues, mail, and relay support for nodes behind NAT or an HTTP proxy. Each SysOp chooses what their node carries: anything past a carry cap is offered for a decision rather than dropped, and content another node originates can be hidden, restored or purged.

Trust & reputation

Validation continues

Local trust policy, signed reports, quarantine, recovery controls, and replacing a node’s signing or transport key are implemented. Trust now also runs without a SysOp: probation ends by itself after contact on three separate days, recovery holds release on time, a node that signs conflicting histories is reported with a signed, checkable accusation, and a key compromise reaches nodes that know the node only by introduction. NetBBS Link remains private and experimental: these fixes still have to be seen on real nodes, and a sustained dogfood run is still required before public readiness is claimed.

Live NetBBS Link chat

Available

Authenticated live chat, presence, recent scrollback on joining, and private messages across nodes, including live relay paths. Lines go both ways: a subscriber node’s callers reach the chat channel’s origin live, and the origin relays them to its other subscribers. Cross-node invitation chats and simultaneous background chat-channel memberships remain outside the current scope.

Inter-BBS chat — the MRC bridge

Complete

A bridge onto MRC, the public inter-BBS chat network that Mystic, Synchronet and ENiGMA½ boards already use: chat channels a SysOp maps to rooms, open rooms callers can enter on demand as chat channels of their own, away/topic/message-of-the-day presence carried both ways, and opt-in private messages. Shipped across v5.7.0 through v5.10.0; the scoping decision behind it is closed.

FidoNet-technology networks

Live test pending

New in v7.17.0: NetBBS joins FidoNet, fsxNet and other FTN networks as an ordinary node, speaking BinkP itself. It polls its hub and can answer calls, carries echoes on message boards, and delivers netmail in Mail, sending it direct to nodes from an imported nodelist. Off until a SysOp enables a network. So far it has exchanged mail only with itself and with test fixtures; the first session with a live hub is still to come. File echoes, file requests, hub mode and QWK are not supported.

Doors & games

Available

Retro Trivia, Voidrunner, and War Dialer are bundled. Add trusted native programs, selected DOS games through DOSBox-X, doors built for another operating system in a virtual machine per caller, or remote services such as DoorParty and BBSLink. Companion services and an optional outbound hook, which lets a door post to message boards and speak in chat channels, support external door developers. Native doors run as the service account; resource limits do not isolate them from its files. Legacy compatibility is documented for specific game versions and host configurations, and virtual-machine doors have so far run one game end to end.

Capabilities

What a caller and a SysOp get today.

Organized by what it's actually for, not by when it shipped.

Core BBS

Message boards & files — a post list and a reader, read tracking per post, full-text search, real Zmodem and browser transfers.
Mail — personal mail, local or across NetBBS Link: drafts, replies, forwarding, several recipients, read receipts, blocking, search, and the delivery state of every letter you sent to another node.
FidoNet & fsxNet — echomail on message boards and netmail in Mail over BinkP, polled and answered, with a nodelist for direct netmail and the SysOp choosing who may send it.
Communities — topic-first grouping of message boards, chat channels, and file areas.
Directory — vCard/finger-style caller lookup and preferences.
Classic terminals — a session speaks UTF-8, CP437 or plain ASCII, detected when the caller connects and changeable in their profile, so SyncTERM draws its boxes right.

Real-time

Chat channels — scrollback, private messages, /nick, /away.
Moderation — mute/ban/kick and moderated-content approval queues.
Node-wide presence — who's online, across every linked node.
Inter-BBS chat — chat channels bridged to rooms on the public MRC network, or any room opened on demand.

NetBBS Link & federation

Signed identity — every peer is a real keypair, not just a hostname.
Trust & reputation — vouching and reputation gate what a linked node's content is worth; probation ends on its own, and equivocation is detected and reported with proof.
Sealed attestations — a caller's verified age or name reaches each node it is published to as a snapshot only that node can open, even a node nobody can dial.
NAT reachability — automatic relay selection and consent, bounded mailboxes, live traffic through an HTTP proxy.
Carry decisions — per-type carry caps; what arrives past a cap is offered, not dropped, and content another node originates can be hidden, restored or purged.

SysOp & customization

Admin console — users, message boards, file areas, chat channels, scheduled backups, installing a new release, the node log, audit log.
Staff permissions — let a helper approve signups, manage accounts or moderate everything without a second SysOp account; members see who runs the node under Operators on the main menu.
Levels — a Levels screen showing what each access level opens, a preview of what a level change opens and closes before it is applied, named levels, and automatic promotion under rules the SysOp sets.
Branding — welcome banner and mastheads, or your own ANSI art as the main menu and the message board, file area and chat channel lists, with live values filled in, items a caller can't use blanked, optional modem-speed playback with a time limit, and SAUCE records from scene tools understood; node-wide accent/header/clock colors.
Editors — a fullscreen WYSIWYG ANSI art editor and a nano-keybound prose editor.

Doors & games

Door runtime — each door is its own subprocess, started without a shell, under enforced CPU, memory, time and process limits. Those are resource limits, not a sandbox: a native door can read what the service account can, so install only doors you trust.
Classic DOS doors — LORD, TradeWars 2002 and Global War through an operator-installed DOSBox-X, over an emulated serial/FOSSIL link.
Native and remote — stdio, a controlling terminal, a private DOOR32 socket, or an allowlisted remote door service such as DoorParty or BBSLink.
Doors from other platforms — a door built for another operating system runs in its own qemu guest per caller, with no network and only two shared directories. POSIX hosts only.
Doors that talk back — an opt-in, per-door hook lets a game post to chosen message boards and speak in chosen chat channels, under hourly ceilings the SysOp sets.
Voidrunner, War Dialer and Retro Trivia — three games bundled with the node itself, the first two rebuilt in v7.2 so every screen is an instrument panel rather than a paragraph.

NetBBS Link

A federation with no one in charge.

NetBBS Link is what happens when nodes choose to talk to each other: an ad-hoc mesh of independently owned boards that discover one another, exchange message boards/mail/files/chat, and stay in sync — with no central server, no company account, and no directory anyone could shut down, buy, or rate-limit. A node that never turns NetBBS Link on is still a complete BBS on its own; NetBBS Link is something nodes opt into together, not something the software depends on. It's the piece of NetBBS we spent the most protocol-design effort on, so here's a closer look at how it actually holds together.

Real cryptographic identity

user@node-fingerprint. Every node's address is derived from its own long-lived root keypair, not a hostname or DNS entry — the network can change out from under it without the identity changing at all.
Split-key design. A root key that rarely touches the network authorizes short-lived operational signing and transport keys; rotating one, routinely or because it leaked, is a SysOp console action that never changes a node's address or its accumulated trust.

Content nobody can quietly rewrite

Signed, content-addressed events. Every post, message-board update, and chat-channel message travels as a canonically-hashed, signed envelope — its ID is its signature, so nothing in between can alter it undetected.
Deterministic canonicalization. Byte-for-byte hashing rules (Unicode normalization, JSON key ordering, no floats) are pinned by golden test vectors, so an independent, non-Python implementation is compatible if and only if it reproduces the same bytes.

Two protocols, one for each job

Store-and-forward. Message boards, mail, files, and governance travel over signed HTTP+JSON — durable, and unaffected by a peer being offline for a while.
Real-time. Live chat rides its own persistent, mutually-authenticated Noise-encrypted channel instead — forcing a chat message through a pipeline built for store-and-forward message boards would be the wrong trade-off.

Trust you can see, on a network you don't fully control

Earned, not inherited. However you found a peer — a configured seed, a signed peer-exchange list, a friend's recommendation — trust in what it publishes comes from vouching and reputation, never from how you discovered it.
NAT-friendly by consent. A node behind NAT can still be reached through relays that opted in and see only routing metadata, never content — the recipient re-verifies everything regardless of who relayed it.

Multi Relay Chat

The other network — and why it is a different thing.

NetBBS speaks two networks, and they are easy to confuse because both let a caller talk to people on other boards. NetBBS Link is the project's own federation. MRC is a chat network that already existed, that NetBBS simply joined. A node can run either, both, or neither. See the MRC bridge screen by screen.

What MRC is

A public, unauthenticated chat network with one central hub, used by Mystic, Synchronet, ENiGMA½ and others. NetBBS speaks its wire protocol directly — no gateway program, no separate client.
Rooms, mapped or opened. A SysOp maps a chat channel to a room by hand; or, behind a node-wide switch, callers open any room on the network and it becomes a real chat channel with the node's own gates, scrollback, moderation and search.

How it differs from NetBBS Link

NetBBS Link connects more than chat. It carries selected message boards, mail, file catalogues, trust signals, and live conversations. MRC connects chat rooms.
NetBBS Link has no centre; MRC has a hub. NetBBS Link peers are cryptographic identities that verify each other directly. An MRC author is a name on someone else's server, so NetBBS renders every inbound line as an external, unverifiable author — never as a local account.

What the SysOp decides

Nothing is bridged by accident. The hub link is off by default and each chat channel is mapped explicitly; open rooms are a separate switch with a cap, a retention period and a blocklist.
Open rooms stay local. A room a caller opened is never shared over NetBBS Link in either direction, and is retired with its scrollback once nobody is using it.

What NetBBS will not do with it

It stores no MRC credentials. Registration and identify commands read the password separately with echo off and send it once; it reaches no scrollback, log or input history.
Private messages are opt-in and unstored. Off per caller until they ask, never written to scrollback, search or any log, and introduced with a plain warning that a public hub can read or spoof them.

Not a mockup

A few real screens.

The other side of the same node: what running one looks like from the SysOp's chair. Unedited captures from an actual running node — the same product this page has been describing, not a rendering. What a caller sees is on the front page. For one part of NetBBS at a time, from both chairs, see the tours of message boards, file areas, doors and the MRC bridge.

SysOp console

Harbor Lights › SysOp operations console
Live health, attention queues, and administrative controls.
───────────────────────────────────────────────────────────
╔════════════════════════════════════════════════════════════════════════════╗
║ NODE  ● ONLINE                                                             ║
║   Active sessions: 0                                                       ║
║ LINK  ● DISABLED                                                           ║
║ CONTENT                                                                    ║
║   Users: 5  Message boards: 3  Posts: 1  File areas: 1  Files: 0           ║
║ ATTENTION                                                                  ║
║   Moderation: 1 pending                                                    ║
║     Users: 1  Posts: 0  Files: 0                                           ║
║   Backup: never                                                            ║
║   Update check: never                                                      ║
╚════════════════════════════════════════════════════════════════════════════╝

CONSOLE                                  QUICK
  [U]sers                                  [N]ode
    Manage user accounts                     Sessions, shutdown, and drain
  [C]ontent                                [F]ull backups
    Boards, areas, channels & more           Create and review complete backups
  [O]perations                             [D]NS
    Observe the node, fix trouble            Managed netbbs.org name status
  [S]ettings                               [T]ime away
    Durable node configuration               Tell members you're away
  [R]efresh
    Redraw with current numbers
  [B]ack
    Return to the main menu
Choice:

A real admin console

Live node health, content counts, and an attention queue with something actually waiting in it.

SysOp › Users

Harbor Lights › SysOp › Users
Account administration, registration policy, and access levels.
───────────────────────────────────────────────────────────────
╔════════════════════════════════════════════════════════════════════════════╗
║ ACCOUNTS                                                                   ║
║   Total users: 11  Active: 9  Pending: 1  Disabled: 1                      ║
║   SysOps: 1    Active ratio: [████████░░] 9/11                             ║
║   ⚠ 1 registration awaiting review                                         ║
╚════════════════════════════════════════════════════════════════════════════╝
  [C]reate user                            [A]uto-promotion rules
    Add a new user account                   Raise new accounts automatically
  [U]ser list                              [E]nable/disable
    Browse and edit accounts                 Toggle account access
  [R]egistration                           [D]elete user
    Signup policy settings                   Permanently remove a user
  [P]romote/demote                         [H]eld names
    Change a user's level                    Names held for deleted accounts
  [L]evels (LAST)                          [B]ack
    What each level opens                    Return to the SysOp console
Choice:

Account administration, one screen down

The accounts panel: the counts a SysOp acts on, a ratio drawn only because it has a real denominator behind it, and the one registration actually waiting — then the actions, each with a line saying what it does, including the Levels screen and the rules that promote accounts automatically.

Settings › Colors

Harbor Lights › Node colors
───────────────────────────
Branding only -- status colors (error/success/warning/etc.) always stay
standard, so a caller can trust what they mean on any node.
Accent color:
  Truecolor:   MetroBBS Underground
  256-color:   MetroBBS Underground
Header color:
  Default:   == Node management ==
Clock color:
  Default:   14:32:07
  01 Accent: 255,140,60
  02 Header: default
  03 Clock:  default


[01-03] change  [S]ave  [B]ack
(Ctrl-H for help on these fields)
Choice:

Brand it without a config file

Accent, header and clock colors as one draft, previewed live in both color depths and applied on save. Status colors never change: an error means the same thing on every node.

SysOp — door compatibility

Harbor Lights / Door compatibility
----------------------------------
External installs are manual. See docs/NetBBS-door-guide.md. Templates need
local paths and game setup.
RUNTIME
  01 Setup template:                    (none)
  02 Import JSON:                       (none)
  03 Restore original API on Save:      False
  04 Adapter:                           dosbox
  05 I/O endpoint:                      socketpair
  06 Executable/runtime path:           /usr/pkg/bin/dosbox-x
  07 Arguments:                         (none)

[01-30] change  [S]ave  [B]ack
(Ctrl-H for help on these fields)
(Section 1 of 6: < > switches)
Choice:

Configuring a DOS door

The Runtime section of a door's compatibility profile — the adapter, the I/O endpoint and the emulator path. Five more sections cover the files, the terminal, the limits and the setup checks.

chat — #lobby, bridged to MRC

[21:24] <alice> tradewars and global war are on the door menu too
[21:24] [MRC] <kite@Blackwater> tw2002! I have not played that since the 90s
[21:24] [MRC] <marla@TheOuterRim> we run trade wars here as well. same universe
age?
[21:24] <alice> fresh one, started it over the weekend
[21:24] [MRC] <jasper@Vertigo> how are you hosting the dos ones?
[21:24] <alice> dosbox-x with a fossil driver, over a serial link
[21:24] [MRC] • jasper@Vertigo whistles
[21:24] [MRC] <kite@Blackwater> that is the part I could never get working
[21:24] <alice> the setup guide has the emulator patches. took an evening
[21:24] [MRC] <marla@TheOuterRim> bookmarking that for the weekend, thanks
[21:24] [MRC] <kite@Blackwater> right. making a character now. what is the
address?
[21:24] <alice> telnet harborlights.example.net 2323 -- doors are on the main
menu
[21:24] [MRC] <kite@Blackwater> see you in the woods
[21:24] [MRC] <marla@TheOuterRim> what is your board called, for the list?
[21:24] <alice> harbor lights. we sit in #lobby most evenings
[21:24] [MRC] <jasper@Vertigo> noted. good to have another board on here
[21:24] [MRC] • marla@TheOuterRim raises a mug back

────────────────────────────────────────────────────────────────────────────────
#lobby[PUBLIC][MRC] | 1 here (0 away) | 3 MRC | alice | 21:24                   
›

A chat channel the SysOp bridged

One local chat channel mapped onto an MRC room. Inbound lines carry the BBS that sent them, so callers always see who is remote — and the SysOp decides which chat channels are bridged at all.

Platform support

Where NetBBS is meant to run.

Tiered by how much a regression there is treated as a real bug.

TIER 1 · PRIMARY

NetBSD

Every design and dependency choice must work here first. pkgsrc is the preferred source for external dependencies.

TIER 2 · SUPPORTED

Linux

Ordinary Python packaging and systemd. A regression here is a real bug unless fixing it would weaken a Tier-1 constraint.

TIER 3 · BEST-EFFORT

Other POSIX

macOS, FreeBSD, and similar systems — supported on a best-effort basis.

DEV ONLY

Windows

Convenient for local development, never a target for production semantics that depend on POSIX facilities.

Go deeper

A handbook for what you want to do.

User handbook

A short guide to connecting, getting around, posting, chatting, exchanging files, and playing.

Developer handbook

Build a door, implement NetBBS Link, or contribute to NetBBS itself, with contracts and reference examples.

Door setup guide

The verified compatibility matrix, the emulator build patches, and the checks to run before callers see a game.

SysOp handbook

Install and run your node, manage accounts and content, connect networks, back up, recover, and upgrade.

Issues & roadmap

Active work, acceptance criteria, and what's actually next — tracked on GitHub.

Releases

Download a release and read its changes and upgrade notes.

Ready to run your own node?

Start with the installation guide, then shape the BBS around your community.

Get started →