Neon Modem Overdrive: five forums and a bulletin board system in one terminal

Five backends behind one terminal interface

Neon Modem Overdrive is a BBS-style command line client that supports Hyperuplink, Discourse, Lemmy, Lobsters and Hacker News as backends and integrates all of them into a single streamlined terminal interface. The author notes, with some pride, that they did call it Neon Modem Overdrive.

The name is the joke and the point. The project is explicitly trying to reproduce the feel of the bulletin board systems that preceded the web, and the BBS reference is a link to the Wikipedia article on bulletin board systems. The BBS reference in the name is not nostalgia for the technology but for the interface: one place, a list of boards, a prompt, keyboard commands.

The support table is the clearest statement of the scope, and it is unusually complete. Every listed system, Hyperuplink, Discourse, Lemmy, Lobsters and Hacker News, has every capability ticked: available, list forums, list posts, list replies, create post, create reply. A client where some backends are read-only would be a client where you have to remember which is which. Here, the only variable is whether you have an account.

Creating posts and replies needs an account on the system, but every system can also be connected without one for reading only. That distinction is the practical dividing line in the configuration, and it means you can start reading immediately and add credentials later.

The stack is Go with Charm's Bubble Tea TUI framework, and the dependency list in go.mod shows the rest of the Charm ecosystem in use: bubbles for the widgets, glamour for rendering markdown in the terminal, and lipgloss for styling.

Credentials come from a command, not from a file

The configuration design is the most careful part of the project, and it is worth understanding before you connect anything.

Initial setup is done through neonmodem connect, and the readme points you at neonmodem connect --help for the details. Connecting a service adds it to the configuration TOML, whose location follows the platform: on Unix systems it is under $XDG_CONFIG_HOME when that is non-empty and otherwise under $HOME/.config, on Darwin it is in the Library Application Support directory, and on Windows it is under AppData.

Reconnecting a system that is already connected asks whether to keep the existing connection or replace it. The replacement behaviour differs by backend, and the difference is a security detail worth noting. Replacing a Hyperuplink connection revokes the previous API key on the board, unless the key came from a command. For every other system the previous credentials stay valid on the site until you revoke them there, because Neon Modem cannot do that everywhere. In other words, the client can clean up after itself on one service and not on the others, and you have to do the manual revocation yourself.

The credentials feature is the interesting one. Every credential can be read from a command instead of being stored in the file. You add the suffix _cmd to its name and use the command as the value:

[Systems.Config.credentials]
username = 'vera'
token_cmd = 'pass show lemmy/token'

The connect command asks for every credential whether to enter it or to read it from a command, and stores only the command. When both token and token_cmd are set, the command is used.

The commands run when Neon Modem starts, before the interface opens, and they run with $SHELL -c, or cmd.exe on Windows, in the current terminal and environment. That detail is what makes pass and gpg-agent work, since they need a terminal to prompt. The first line a command prints to stdout is the credential, prompts have to go to stderr or the terminal, and pinentry-curses needs GPG_TTY exported. A command that exits with a non-zero status, prints an empty first line, or runs longer than 60 seconds makes the system unavailable.

The fallback when a credential is stored in plain text is that the file is created with mode 0600, and if the file cannot be written at all, for example because it links into the Nix store, the command prints the [[Systems]] tables to add by hand. One caveat is worth internalising: comments in the configuration file are lost on a write.

OpenWith runs commands with the post's metadata as variables

The OpenWith feature turns the post view into a launch point for other tools, and its security design is the part to read twice.

Entries define commands that run on the post shown in the post view. Each has a name, which a dialog lists, and a cmd:

[[OpenWith]]
name = 'Save page'
cmd = 'wget -q -P ~/Downloads "$NM_POST_URL"'

[[OpenWith]]
name = 'Bookmark in nb'
cmd = 'nb bookmark "$NM_POST_URL" --tags incoming'

The O key in the post view lists the commands. The selected one runs in the background with $SHELL -c, and it receives a set of environment variables describing the post: the system type such as lemmy, the system URL, the forum ID and name on that system, the post ID, the post URL, the post subject, the creation time in RFC 3339 in UTC, and the linked page of a link post.

The security property is stated carefully and it is the right one. A value that does not apply is empty, and the values never become part of the command line, so post content cannot run as code. The values are passed as environment variables rather than interpolated into the command string, which is the difference between a forum post title being a string and a forum post title being a shell injection.

The documentation also warns to quote the variables, as in the examples, because the shell splits unquoted values into words, and notes that on Windows they are written with percent signs instead.

Two operational limits are stated. The command's output, up to 1000 lines per stream, and its exit status are written to the log. And commands have no terminal, so anything interactive in them will not work.

Installation covers releases, source, AUR and NetBSD

There are four documented installation paths, which is a sign of how widely the tool is used.

From a release, you download the latest release archive and unpack it:

$ tar -xzf ./neonmodem_*.tar.gz

The binary is called neonmodem, and the readme says to feel free to move it to somewhere like /usr/local/bin.

From source, the clone is from a slightly unusual URL, tty.fail, rather than GitHub:

$ git clone https://tty.fail/mrus/neonmodem.git

Then you change into the directory and run make. Building needs Go 1.26.7 or newer, which matches the go.mod module directive, and the binary is again called neonmodem.

There is an AUR package for Arch Linux, to be installed with whichever AUR helper you prefer, and a package in the official NetBSD repositories, installed with pkgin install neonmodem. A NetBSD package in the official repositories is a stronger signal of adoption than a download count.

The Makefile itself shows a project with a full CI discipline. The default target installs the Go dependencies and builds, with the version string injected at build time from git describe. There are targets for test, vet, a cross-platform vet that runs for Windows and for Darwin, gofmt, golangci-lint, and govulncheck, and a check target that runs the format check, the vet, the cross vet, the tests and the probes, running the linter only if golangci-lint happens to be on the path.

The repository also has a .goreleaser.yaml, which is what produces the release archives, and a .golangci.yml for the lint configuration.

A licence the classifier cannot name, and an active but small project

Two facts about the project as a software artefact are worth knowing before you depend on it.

The first is the licence. The repository records a custom licence that GitHub cannot classify, with a LICENSE file at the root, and the readme carries a badge for a licence called SEGV LICENSE at version 1.1. That is a personal or non-standard licence rather than an OSI one, and if you are putting this in a commercial context, read the file rather than assuming MIT. The name of the licence, on its own, suggests the author has views about software licensing that will be spelled out there.

The second is the activity level. The repository is not archived, the default branch is master, and the last push was on 2026-10-10, eleven days before the current date. The three most recent releases are v2.0.0 from 2026-10-10, v1.1.0 from 2026-07-20 and v1.0.7 from 2025-06-13. A 2.0.0 on the same day as the last push means a deliberate major release rather than a slow drift.

The release cadence before that was every few months, and the move to a 2.0 line with the new configuration and OpenWith work suggests the author took the opportunity to reshape the configuration format.

The homepage is neonmodem.com, and the project also links to a BBS-themed site at tty.fail, which is the same host the source clone comes from. That split between a conventional project page and a BBS-styled one is a small detail that tells you the aesthetic is part of the pitch, not a wrapper around it.

Editorial conclusion

Neon Modem Overdrive suits someone who reads several forums and a link aggregator daily and wants one keyboard-driven interface instead of five browser tabs, and it suits a person who already keeps API tokens in a password manager since the credential commands plug straight into that workflow. It does not suit a team that needs moderation tooling, scheduled posting, or a stable API to build on, and it does not suit someone who wants a graphical client. Before installing it, run neonmodem connect --help, pick the credential-command route over the plain text one, and read the OpenWith section carefully, since those commands run with your privileges and no terminal.

Frequently asked questions

Official sources

1. Issues
2. mrusme/neonmodem on GitHub
3. Project website
4. README
5. Releases