index concept yachts_and_racing_dinghies system_niches elements_principles designs journal



// 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.

Pitch

    A client/server settlement that fills the same usage niche as the web, but
    which dumps all the complexity.

Overview

    The Limit Browser (LB) is a vm. It makes long-lived TCP client connection
    to a Limit Server (LS).
    
    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 standing 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.

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.

        Easy to do easy things, possibly to do hard things.

    Display modes

        Mono-Access

            16x2 character display, ISO-8859-1, monochrome.

            Top row display, bottom row command.

            Blind-friendly. Could display lines on a braille device.

            Memory friendly, just 32 bytes!

        Mono-Grid

            60x20 character display, ISO-8859-1, monochrome.

            Dimensions can scale up.

            Fits in 2k of ram.

            Useful mode for secure transactions.

        Colour Grid

            60x20 character display, UTF8, 24-bit colour

            Dimensions can scale up.
            
            Fits in 16k of ram.

        Graphics

            Base resolution 320x480, 24-bit colour.

            Resolution can scale up. Remember: users may want to run things in
            windows.
            
            That needs just under half a megabyte.

            Static RAM costs about GBP 4 per megabyte.

    Early target systems,

        python/solent, ncurses

        python/solent, pygame

        plan-9

        c#? gtk? rust? amiga? find a volunteer.

Mono-Access could be re-created in minimal hardware,

    32x 16-segment displays;

    768x LEDs, assuming 4x6 (simulating 5x7 Terminus font)

    1120x LEDs, assuming 5x7 (simulating 6x8 Terminus font)


::: 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.