Dinghy index concept papers
Limit draft
.
Motive
Popular view: platforms without a first-class web browser are a waste of
time.
Our view: now is an ideal time to disrupt the entire browser stack with
something simpler and better.
Pitch
A client/server settlement that fills the same usage niche as the web, but
which has better tradeoffs.
Web: DNS, HTTP+TLS+Websocket, HTML+CSS+JS, variety of encodings.
Limit: DNS, Async Binary Message Protcol+TLS, Forth VM, UTF8.
Overview
The Limit Browser (LB) is a vm that runs forth bytecode.
Its main use-case is to make a long-lived TCP client connection to a Limit
Server (LS), and then supply a web-browser-like experience to its users.
While connected to a server, the link stays open. When the user navigates
away, the link drops, and you cannot recover state.
Once the connection is negotiated, LB downloads bootstrap code from LS.
This code will be forth, packed in a binary form.
LB boots the forth code. It is heavily sandboxed.
Client and server can continue to speak to one another using binary events
(async) over the long-lived TCP connection.
The user interface is textual, and drives a bit like a Bloomberg terminal.
We steer clear of text+pictures dynamic that html had. It creates an
arms-race towards complexity. We can add a full graphics mode later. This
would feel more like plan9/inferno than a webpage.
Ability to inspect and learn was significant in bootstrapping HTML.
Copying this, LB allows its user to inspect (1) bootstrap forth and (2)
subsequent messages.
This is better than Java applets. The networking is better and easier to
work with. Limit mandates a simpler user interface, reducing cognitive
load for developers. It is easier to port a (simple) Limit vm to a new
arch than a (complex) JVM.
People should be able to communicate with Limit via small text messages,
as though it was a phone-based text conversation.
AirAsia has recently created a chatbot that lets people change their
airline booking through a whatsapp conversation.
https://www.businesstraveller.com/business-travel/2020/07/29/airasias-customer-service-chatbot-is-now-on-whatsapp/#:~:text=Passengers%20can%20chat%20with%20AVA,that%20are%20short%20and%20simple.
Open problem: work with people from the blind community in order to create
conventions for interacting with these sites. Phone interactions will
benefit and freeload from this guidance.
When a bitmapped display is available, they would have the benefit of
this. Open multiple 'pages' in separate tabs.
Proxy wikipedia and similar sites through a HTTP-to-Limit converter in
order to get lots of content available to early adopters.
Challenge: creating state machines is non-trivial. How to assist content
developers at creating pages that can be offered by a Limit Server? It
should be possible to write raw forth, but many use-cases could instead be
written in a higher level languagethat is compiled to Limit Bytecode.
Hypothesis: /Limit/ would have common purpose with alt-OS communities that
do not have first-class browsers: Haiku, Plan9, Amiga, Suckless, people
who run old SGIs for fun. Imagine if you could just recompile a C
codebase, and change some headers, and get a full-featured browser-like
thing running on these systems.
People who /are/ running a current browser on windows or mac should be
able to interact with Limit as well. It will be straightforward to port
the forth vm to javascript, and to tunnel communication to a limit server
via websockets. In this way, people may be tempted to simply create a
limit server, having confidence that their web and phone users will also
be able to access that content.
The new conversational interaction between whatsapp users and corporate
chatbots (e.g. airline rebooking over whatsapp) shows developer and user
appetite for non-HTTP internet activity. Also - Slack, Gemini.
SSL
Eventually, yes, but not important for early version.
ForthVM
Design values
Be friendly to blind-user use-case from the outset. This will have a
strong influence on the form of the system, forcing it towards
simplicity.
Easy to do easy things, possible to do hard things.
Early target systems,
sdl
plan-9
c#? gtk? rust? amiga? find a volunteer.
Display modes
Mono-Access (Accessibility interactions, text conversations)
When viewed in the Limit browser, this would show as a two pane
display, monochrome.
Alternatively, could interact with it on a braille device.
Top section: display, asynchronous.
Bottom section: command, synchronous.
How to reconcile Braille with UTF8?
Regular users could communicate with this through phone messages,
much like a whatsapp conversation.
Mono-Grid
60x20 character display, UTF8, monochrome.
Asynchronous interaction. Screen can update without keystroke.
Dimensions can scale up.
Fits in 2k of ram.
Convention: should offer a menu hierarchy.
The simple interface and limited character set (not UTF8) are
intended to make this this ideal for secure transactions, and
practical through unix terminal. This is unhelpful for non-western
language speakers. Open problem.
Bitmap
Fixed resolution, 320x480, 24-bit colour.
Resolution can scale up. Remember: users may want to run things in
windows.
Asynchrounous interaction. Display can update independent of
keystrokes.
Interacting with this feels like interacting with a Bloomberg
Terminal.
Forth?
Forth is easy to bootstrap from C (which is available almost anywhere).
Possible alternatives include Mu, Scheme and Red. There may be obstacles
bootstrapping Red on platforms that do not already have a Rebol/Red
interpreter available.
// Nov 2020 hacker news conversation
https://news.ycombinator.com/item?id=25234578
// Early conversation
21:20:22 <@cratuki> tgschultz: some of these ideas will be yours, some will not.
21:20:34 <@cratuki> I can't remember, but the original idea I think I took from you.
21:21:06 <@cratuki> The client. It would host a VM. A bytecode machine. Architecture TBD, but I do have strong thoughts on some qualities.
21:21:08 <@cratuki> Come to that later.
21:21:22 <@cratuki> The client would make /long-lived/ TCP connections to a server.
21:21:41 <@cratuki> This interaction fills a role a bit like HTTP. But it is long-lived, and should be binary (Martin Thompson would support this)
21:22:05 <@cratuki> What does the client look like?
21:22:10 <@cratuki> Is it strictly a grid of characters?
21:22:29 <@cratuki> Or is it more like html, justified text with kerning and what-not?
21:22:39 <@cratuki> Or is it a bitmapped interface?
21:22:41 <@cratuki> Or a vector interface?
21:22:57 <@cratuki> Some use-cases. We would want to do an irc-like within this.
21:23:07 <@cratuki> We would want to offer something like phpbb forums.
21:23:19 <@cratuki> You should be able to browse a view of wikipedia.
21:23:28 <@cratuki> It should be able to support something like gmail/pine.
21:23:41 <@cratuki> What about maps? Does maps matter?
21:23:59 <@cratuki> Does low-bandwidth matter?
21:24:08 <@cratuki> .
21:24:24 <@cratuki> OK. So let's talk about the VM. I think it is important that the VM be something that could be supported by a very low-powered machine
21:24:27 <@cratuki> by today's standard.
21:24:49 <@cratuki> My idea for reference architecture is a wire-wrapped 68k homebrew computer.
21:28:21 < tgschultz> If you're asking me, I lean towards something kinda like how a lot of systems worked in the 8-bit era: a grid of tiles indexing a pool
of writable bitmaps, and maybe some arbitrarily placable foreground objects. That might be mostly nostalgia talking though. A simple
VGA-like aperature of pixels is probably more appropriate? Or yeah, vector drawing is also interesting. Either way, I feel like a
document layout engine where
21:28:21 < tgschultz> the client is supposed to understand how to make all the content fit in a way that makes sense has been proven not to work well.
21:28:24 <@cratuki> 16mhz, 32-bit, several meg of ram
21:29:13 <@cratuki> so - why a document layout rather than a simple grid of characters? If you wanted document layout, you would have to write that in the
code of your bytecode app
21:29:38 <@cratuki> Because I feel like you could implement document layout as an application layer.
21:29:43 <@cratuki> but that the underlying should not be limited to it.
21:30:02 <@cratuki> It is interesting though - you are going further back in technology terms than I expected. I thought you would feel my 68k standard was
underpowered :)
21:30:20 <@cratuki> You could offer different personalities,
21:30:27 <@cratuki> * Flowing document layout personality
21:30:33 <@cratuki> * 8-bit personality
21:30:52 <@cratuki> Then people who were building "pages" of content, could include those assembly routines, and then call them.
21:30:57 <@cratuki> but we could do more if we wanted.
21:31:04 < tgschultz> yeah, but you'd be writing it in a way that made sense based on what the client knew about the display. If my aspect is 4:3 and my
viewing distance is X with DPI Y and Z resolution, do this. If it is 16:9 with vd 10ft... etc.
21:31:20 <@cratuki> good point.
21:31:34 <@cratuki> so there is a tradeoff. do you hard-code the dimensions, or do you have it flow?
21:31:38 <@cratuki> do you have more thoughts about this?
21:32:14 <@cratuki> I think my mental standard is the bloomberg terminal, so I will probably be closer to fixed dimensions than you
21:32:19 <@cratuki> but I can see your point, and am mulling it.
21:32:21 < tgschultz> a big mistake with HTML/CSS/JS I think is that it doesn't expose this kind of information to the code, and you have to guess because the browser lies to you.
21:32:47 <@cratuki> Right. It could be more like ncurses, where the display would tell you what the dimensions were.
21:33:20 <@cratuki> (I know ncurses sucks, but it does that better than web)
21:33:23 < tgschultz> Fixed dimensions has its tradeoffs. It is much simpler for the developer, but less flexible for the user. Not really sure which way I
lean. Do we really need to support 10ft interfaces as well as phoneS?
21:33:36 <@cratuki> Good question.
21:33:44 <@cratuki> I suggest these use-cases,
21:33:55 <@cratuki> * It should work on a phone. We could make a dinghy-browser app on the app store.
21:34:11 <@cratuki> * It should work on the desktop, and be comfortable to interact with
21:34:46 <@cratuki> * After the bomb, a monk should be able to wire-wrap a computer together around a dragonball CPU, and it should not be so demanding that
it can't run.
21:34:52 <@cratuki> There are my three use-cases - thoughts?
21:35:15 * cratuki digs post-apocalyptic computing
21:36:18 <@cratuki> (I don't think we need to support 10ft interfaces. They're for yachts)
21:36:41 < tgschultz> well my thought was more along the lines of TVs, but it is admittedly probably out of scope.
21:36:59 <@cratuki> interested to hear your thoughts about tvs
21:38:04 < tgschultz> Well, you know, every once and a while you want put an interface on a TV. Like, as a frontend to emulators or something like Kodi. I'm
just spitballing
21:38:31 < tgschultz> What's your rationale for limiting the compute power? Just to keep it undemanding?
21:39:12 <@cratuki> Part of what has allowed the web to become bloaty is that computing power gets so impressive.
21:39:25 < tgschultz> true, they just keep piling on more
21:39:29 <@cratuki> And then it is impossible to create a new platform, and you get locking, and then one browser emerges to run them all.
21:39:44 <@cratuki> So if we hardware-limit it, and keep it low, any idiot hobbyist can come along and make their own platform.
21:40:07 <@cratuki> And the benefit of this is, you can start threatening the majors. because you win the cathedral vs bazaar thing.
21:40:32 <@cratuki> I think there is a community in waiting for a decent browser-that-is-not-html-grounded.
21:40:53 <@cratuki> Each couple of days now I see some sign where I think - wow - the world is screaming out for an obscure hacker platform that will grow up
21:41:06 <@cratuki> and twenty years from now everyone will be laughing at how shit the web was
21:41:10 <@cratuki> and it will be more obscure than gopher is now.
21:41:19 < tgschultz> The tradeoff being no matter how fast your computer gets, the dinghy web-app thing will never get faster. I imagine the very first fork
would probably be to unlimit it. I do like the idea overall though of forcing developers to reference such a low spec
21:41:20 <@cratuki> it doesn't take much
21:41:23 <@cratuki> get a basic platform going
21:41:31 <@cratuki> get some people on hacker news going - wow - that is neat
21:41:34 <@cratuki> bootstrap community
21:41:36 <@cratuki> and that's it.
21:41:42 <@cratuki> the trick is to keep everything simple and accessible.
21:42:04 < tgschultz> I'd agree with that.
21:42:32 <@cratuki> if you can get the old guard united around the idea of {omg - don't repeat the mistakes of the web} - wow.
21:42:36 <@cratuki> I wonder what Brendan Eich is up to.
21:43:32 <@cratuki> He'd be good for a project like this.
21:43:58 <@cratuki> I need to write my stuff up. THanks for your thoughts.
21:44:12 * cratuki taking eyes away
21:44:37 < tgschultz> Sure, any time, though I don't think I kept up with you today. I'll re-read this later and dump any additional thoughts then.
Day changed to 19 Jul 2019
12:21:27 < tgschultz> I was thinking, if you want it to be simple for people to dive in and create content, then HyperCard is a good model to learn from. In a
(better) alternetate timeline HyperCard became the web...
23:51:48 <@cratuki> tgschultz: hypercard. that is a good point. I think you could create something like that on top of a bytecode engine.
23:53:33 <@cratuki> I was thinking today, what is the most minimal presentation that this system should be accessible through?
23:54:10 <@cratuki> Is a 2-line, dot matrix display sufficient? Blind users appreciate terse presentation.
23:54:29 < tgschultz> taking accessability into account, blind people should be able to use it
23:54:40 < tgschultz> that's somewhere the modern web has f'd up big time
23:55:24 <@cratuki> yup
23:55:32 <@cratuki> I'm watching hypercard notes on youtube now
23:55:37 < tgschultz> If you can get people to use some kind of native widget set that allieviates a lot of the problem. How you avoid the modern web where
they just roll their own though, I don't know.
23:55:53 <@cratuki> Is there anything modern thta I would be familiar with that it would be similar to? That I would understand by analogy?
23:56:53 < tgschultz> Not that I can think of actually. HyperCard was a kind of thing modern computing has never really replicated (unless you count just
outright duplication).
23:57:50 <@cratuki> "cards contain information and interaction."
23:58:55 <@cratuki> Did you ever play around with Java Studio? It was a visual programming tool where you hooked Beans up to one another.
23:59:07 < tgschultz> As I recall, HyperCard was a WYSIWYG gui using cards as a metaphor, backed by a message-passing programming language and a built in
database.
23:59:50 <@cratuki> I guess we'd want people to be able to develop sites using the hypercard-like thing. Then they would get compiled to application bytecard.
Day changed to 20 Jul 2019
00:00:35 < tgschultz> well, something to keep in mind is that the advantage to an interpreted (or JIT) language is that people can take it apart to see how it works.
00:01:09 <@cratuki> maybe I could store it as forth words. that is like bytecode, but is interpreted and could be taken apart.