For years, the default answer for real-time bidirectional communication on the web has been simple:

• Need a chat? Use WebSockets.
• Need signaling? Use WebSockets.
• Need lightweight control messages? Use WebSockets.

And honestly, most of the time, that answer is still correct… although not necessarily the most optimal (I still find XMPP / Jabber a pretty robust alternative, and my default choice for certain scenarios where a battle-tested solution with scalability, resilience and chat features matter).

But while working with WebRTC and SFU architectures, I kept running into the same question:

If we already have a fully encrypted, low-latency, bidirectional transport through WebRTC DataChannels (based on SCTP protocol), why introduce a second parallel communication stack with WebSockets?

I’ve always loved terminals and retro-computing. I find they were a technology that didn’t got fully their full potential due to graphical interfaces (it’s strange I say this since my first computer was a Macintosh LC II at a time where everybody else had at most a PC with Windows 3.11…). That’s the main reason I added support for Unicode BPM plain in Linux kernel for NodeOS, specially to have available the Braille patters used by blessed-contrib to draw graphical diagrams in the terminal. That’s the reason why when I discovered BOOTSTRA.386 project, a Bootstrap theme that mimics a text-mode interface in a website similar to old BBSs (fathers of web forums, and grandfathers of current online walls), I got enthusiastic about the idea of making it compatible with real terminal web browsers like Links, w3m or Lynx.