Connecting classic systems to the modern internet won't be worthwhile - no performance to absorb all the extra pushed traffic or (performant) capability to interact with the graphics. But forget all that, and forget the idea of a web browser.
I suppose what I'm thinking is something like what is shown below -- which requires an "all new" kind of BBS host, and "all new" kind of terminal software for the various vintage systems. That sounds bad (i.e. won't ever be built), but humor me for a bit, because there may be a compromise between what already exist and what needs to be built....
The WiModem232 does the work of relaying the local serial IO over to TCP/IP - so you just type "ATDTimts.com:1234" (or something like that)
Most of the vintage systems have some kind of VT100 compatible terminal available (i.e. can interpret those ANSI escape sequences). But the "experience" is going to be inconsistent.
First, consider baud rate. The baud is a function of several aspects: the serial IO hardware available, the MHz of the system, AND how efficiently the terminal software is written. Collectively, all that translates into a max baud rate that that terminal software can support. If you bump up the baud rate just a little bit, it might still kind-of work, but will start to drop characters here and there -- the dropping of characters is (generally) the terminal software not being able to keep up (increasing the MHz of the system might be enough to compensate, but of course at the risk of causing other issues). At least, these were my observations on the PET 4016 and IBM PC 5150 with original serial card. If the characters stop entirely, that's probably past the hardware limits (i.e. wrong baud rate).
Next, VT100: not all the terminal software interprets all the escape sequences consistently. I don't have a specific example to refer to, other than in the PETTERM documentation I recall the author saying something to the effect of "not all VT100 commands are interpreted" (a similar statement is in Brutman mTCP telnet documentation - it may depend on the version, as the software may be incrementally adding more support over time:
mTCP Telnet client for DOS (brutman.com) -- the Netris thing is neat)
Then the BBS software itself - most of them generally have to assume some kind of "text screen" resolution. Some avoid "moving the cursor" and drawing things, being sensitive to connections that don't have 80x25 or 40x25, or just don't have the ability to draw on a screen (so we're going back to line printers...). And some clients might not even support ASCII, or don't support lower case characters (think about that -- RIP password systems that require at least one lower case letter! haha).
Around 1988 or so, there was an alternative to ANSI called AVATAR. As an example: with ANSI, you need about 7 full bytes to express a cursor movement. I've forgotten the specifics, but something like: ESC BRACKET CODE COL SEMICOLON ROW ( <- [ M 34;54 ). AVATAR used a shorter expression, to get that same information down to about 3 or 4 bytes. In addition, AVATAR supports codes for "scrolling windows" - so you could have state info in a portion of the screen, and a "chat window" or "scrolling status window" in another portion (so in one short binary code, you could say "make a window this tall and wide starting at this x,y with foreground A and background B"). But supporting that windowing is asking a lot for whoever is implementing AVATAR - especially on a 64K or 32K RAM system. But in general, when using an AVATAR supported BBS, it was roughly 2x as fast as ANSI (well, if color was involved).
When I wrote DestinyHunter for the 1MHz 6502-based PET, it was a struggle to get flicker free animation while using PETSCII -- parts of it had to be done in assembly. So I can understand the challenges of writing a terminal program that buffers inputs, interprets escape sequences, and draws updates while polling for user inputs -- to then also add some game-state processing on top of that, it's rough (for a 1MHz 64KB system). Asking people to write a NEW terminal software for a 1MHz isn't an easy thing to ask for (e.g. like more clients that support something like AVATAR -- I think QModem on the PC did). You'd have to dust off a lot of old code, that's probably in assembler. Like take PETTERM itself: the code (of just handling the serial IO traffic and interpret a few escape sequences) consumes about 4K RAM (it's on github). But from that baseline, one could add support for new escape/code sequences - but not everyone is assembler savvy. Having the "serial IO code" in C might help (or the groundwork of using inline-assembly to do the serial IO stuff) -- but the more "features" the terminal handles (like elaborate interpretation of escape/code sequences), that effectively slows down your baud rate (if you spend too much CPU time drawing stuff, you potentially start dropping characters in the serial IO buffers).
Around 1994-1996, we had some "graphical" BBS - using new protocols. The concept was similar to ANSI or AVATAR, in that some sequence of binary was interpreted as a command to enter a certain graphics mode, draw some lines, fill this area with that color, etc. On the initial connection, you just had to answer a question on if you supported whatever that protocol was (forget the names -- it was fairly short lived after Internet became affordable, and all the technical talent moved to web-browsers rather than any more fancy-terminal development -- but instead of using TheDraw to create the scenes of your BBS, you used a graphical paint-like editor and specified interactive objects like menus and such). I ran a "graphical BBS" for only a few months, before accepting that the Internet was here to stay.
Anyhow, if we stick with existing VT100 terminals - it seems a kind of "IMTS" could be made, a new kind of BBS host. Most existing BBS host software (written for those old vintage systems) maintained a single connection -- some were advanced enough to handle multiple connections. But this modern one would accept multiple connections, and ask "What resolution in your screen? "
I suppose a couple more questions could be asked, such as:
ABCDEFG
abcdefg
Do you see upper and lower case characters? (I don't think there was ever a system that had lower-case only???)
Then clear and write to screen center "is this centered? -- if answer Yes, then they support VT100 and the screen size is correct.
From there, the "IMTS" would offer "experiences" based on the specified screen resolution, and the connected baud rate. One experience could be coordinating a game of backgammon, across two different types of systems. And to me, that's the main new-things this is offering beyond a telnet-connection and "classic BBS experience." "IMTS" would focus on offering multi-player-heterogenous-systems experiences - and be another way for folks to make interesting use of vintage systems (or modern remakes).
The modern telnet BBS's that are networked together to have multi-user chat rooms -- those are neat. But I think it would be fun to have a dedicated host that acts as a kind of lobby and coordinates connections, to play some simple VT100 games
(so it's not just resurrecting Lynx). At some point, there is a threshold where a 1MHz 2400 baud client can't handle the traffic - so full MMO-style gameplay won't be practical. It would need some "ground rules" where "this lobby requires 9600+ and accepting up to 4 clients" vs a lobby that is "1200+, 2 clients" (which the EBGS would determine and manage), and be "agile" such that clients could come and go casually (i.e. your game opponent might drop out for whatever reason -- but wait a few minutes, and maybe another suitable connection resumes it).
But I also realize this is just terminal-experience stuff, and doesn't really exercise the capability of the connected 8-bit system (graphics or sound, unless a terminal program was built that did something like play audio in the background). It would be an excuse to fire up the old vintage systems, it would be "something they are good for" but can also equally be used by a modern Pi or ESP32.
