Three things built to find out whether they could be, and published because the answer was yes. None of them is for sale. What they have in common is the discipline: each one tells you exactly where the real engineering stops, rather than letting an impressive result stand in for a true one.
What does the web look like as a bulletin board?
bbsLive
Type a URL and it comes back as a 1992 board: numbered menus, ANSI colour, CP437, and the pictures redrawn as block art. Not a browser with a retro skin - the page is taken apart into a semantic model, the navigation furniture is thrown away, and what is left is rebuilt as a board in 80 columns by 25 rows of the IBM VGA character set in sixteen colours, because that is all a board had.
Inspect - bbs
An ARIA-informed semantic model, derived from the HTML the server actually sent
Duplicated navigation, cookie banners and boilerplate thrown away rather than styled
Live conferences reading from Hacker News, Wikipedia and GitHub
Rust compiled to WebAssembly, so it renders in the browser
LimitIt reproduces a board, not a page - so it is judged on being singular rather than on repeat value. Every text browser ever written reproduces a page; this one throws the page away. It is an experiment, not a business.
An acoustic modem simulator. Run it on two machines and they establish a real Bell 103 connection over their sound cards, preceded by a faithfully performed dial-up overture. Data crosses the room as sound.
Inspect - modem
The overture performed to real timings: UK dial tone at 350 and 450 Hz, the DTMF digits, double-ring ringback, and the 2100 Hz ANSam answer tone with its phase reversals every 450 ms
Bell 103 FSK at 300 baud carrying actual bytes - originate on 1270/1070 Hz, answer on 2225/2025 Hz
A status bar that shows DEMO MODE whenever the link is wired rather than acoustic
LimitThe screech everyone remembers is a V.34 handshake at 33.6k, and that is not what this is. The overture is performed, the training that follows is an impression because there is no real channel to negotiate, and everything after CONNECT 300 is real. Marking that seam is the whole point - a stunt would hide it.
USB-C connectors are identical and their capabilities are not. One charger delivers 5W, another 65W; one adapter carries video, another cannot. Windows negotiates all of it on every connection and then shows you almost none of it. portmark reads it back out - the negotiated Power Delivery contract, whether DisplayPort is live through that adapter, e-marker cable data, and whether a device is running slower than it could.
$ portmark --human
Adapter 0x343C:0x0000
DisplayPort Alternate Mode: entered successfully
Video yes, DisplayPort is active through this adapter
Port 1
Downstream facing port, over USB Power Delivery, drawing power,
supply offers up to 65W, drawing 5V at 3A (15W).
Negotiated 5V at 3A (15W)
Supply offers
- 5V at 3A (15W)
- 20V at 3.25A (65W)
Inspect - portmark
A native Windows CLI and a tray app that reports the moment something is plugged in - no Electron, no telemetry, and JSON with the raw bytes included so you can redo the decoding yourself
Decoders tested against byte vectors captured from real hardware, so the suite passes with nothing plugged in
The Power Delivery decoder checked against a charger whose printed rating matches what the bytes decode to
LimitNothing is ever inferred from the shape of a connector. Where your PC's controller does not report something, it says so and says why - "this PC's controller does not report cable information" rather than "this cable has no e-marker", because those are different claims and only one of them is supported. It costs the tool some confident-sounding output, and that is the point.
These were built to answer a question. If you have one that matters commercially, bring the workload and the constraints and DBHQ can scope the work around them.
