00:49:32  <substack>mappum: working on the low-level bios-like bootloader for hyperboot right now
00:50:28  <substack>I'm going to write it so that after the first few versions I should basically never need to touch it again
00:50:45  <substack>and I'm going to have it so that it can load plugins via postMessage from trusted, configurable sources
00:56:03  <jfhbrook>heh
00:56:10  <jfhbrook>it's funny because bios was/is literally that
00:56:29  <jfhbrook>it's technically replaced, yeah? but bios went mostly unchanged for like 20 years
00:56:36  <mappum>substack: awesome. Still based on AppCache?
01:01:05  <substack>I'm using service workers
01:01:17  <substack>but possibly will also add appcache if that makes the payloads more permanent
01:01:57  <substack>the safest thing will also be to save the payload and run it on localhost or file:// but this might be good enough
01:09:06  <mappum>Cool. It sucks that they force checking for updates after 24 hours, but when it updates, but it keeps running the old code until all windows are closed. So maybe we could do something with that
01:09:44  <mappum>Like make the old, trusted version check the new update before it starts running, and issues warnings or encrypts the data before the new code can access it
01:17:55  <substack>I will need to experiment to see what the expiry characteristics are like
01:18:04  <substack>got the versioned database working: https://github.com/substack/pkgdb
01:30:52  <substack>mappum: another technique would be to tell people to edit their /etc/hosts after they visit a bios domain
05:23:05  <substack>"The browser does its best to manage disk space, but it may delete the Cache storage for an origin."
05:23:14  <substack>so the Cache api seems useless for this reason
06:08:03  * contrahaxquit (Quit: Sleeping)
06:22:11  * contrahaxjoined
07:06:24  * fotoveritequit (Quit: fotoverite)
07:16:52  * fotoveritejoined
07:16:56  * contrahaxquit (Quit: Sleeping)
07:20:54  * fotoveritequit (Client Quit)
08:24:00  * ralphtheninjaquit (Ping timeout: 246 seconds)
08:29:23  * ralphtheninjajoined
08:42:14  <substack>I've got something that accepts messages that cache into indexeddb and responds with the cache data
08:42:21  <substack>now to make the puts atomic
09:28:33  * timoxleyquit (Ping timeout: 240 seconds)
09:31:16  * timoxleyjoined
09:58:38  * toddself1joined
10:01:12  * toddself1quit (Read error: Connection reset by peer)
10:01:56  * toddself_quit (Read error: No route to host)
10:09:08  * toddself_joined
10:42:12  * thealphanerdquit (Quit: farewell for now)
10:42:42  * thealphanerdjoined
11:16:29  <substack>https://github.com/substack/slugboot
11:16:34  <substack>all done
11:18:17  <substack>next: hooking up a zombie hoard of letsencrypted slugboots to a slugbooted webapp UI and pkgdb
12:58:52  <emilbayes>yoshuawuyts:
12:59:09  <emilbayes>yoshuawuyts: What happened to server-gateway / api-gateway? (https://github.com/yoshuawuyts/server-router)
13:38:45  <yoshuawuyts>emilbayes: never built it hah
13:39:09  <yoshuawuyts>emilbayes: probably next week somewhere; doing a talk on servers at Cascadia so need to get my server vibes back on
13:42:42  <emilbayes>yoshuawuyts: Hehe alright, just finished reading the source so was gonna attempt something like the last example
13:43:37  <yoshuawuyts>hahaha - soooon it'll be possible!
13:44:06  <yoshuawuyts>pretty cool; Mikey's building an RPC framework around MuxRPC which'll probably work in tandem with Merry
13:45:21  <yoshuawuyts>so we can have like a structures way of doing REST/JSON/HTTP towards the outside and Protobuf/TCP internally
13:45:38  <yoshuawuyts>all layered on top of pull-stream
13:45:57  <yoshuawuyts>s/layered on top of/exposed using/
13:49:49  <yoshuawuyts>✨ lil server land, here we come! ✨
13:51:43  <emilbayes>haha
13:53:04  <emilbayes>yoshuawuyts: Did you ever look at ømq? Just bought the book to learn about network programming and their community efforts. Did see you do something with nanomsg at some point, no?
13:56:14  <yoshuawuyts>emilbayes: http://hintjens.com/books :P
13:57:14  <emilbayes>yoshuawuyts: Guess that answers the question then :p
14:00:12  <yoshuawuyts>I feel 0mq / nanomsg are a great idea until you try and use it - beyond their implmentation (blocking IO 😢) they also don't handle things you'd come to expect from such a lib - stuff like acknowledging messages, etc. etc.
14:00:22  <yoshuawuyts>I feel more traditional queues such as Redis have a leg up on nanomsg for this reason - and if you're going to write everything from scratch I think that using some of the newer, more interesting architectures (like creating a swarm) might provide better results for the same time cost
14:00:25  * fotoveritejoined
14:01:23  <yoshuawuyts>The book is a great read though; and the patterns laid out are super neat - but feel like that's about where it stops; the practical application of the libraries themselves is not great
14:01:30  <emilbayes>yoshuawuyts: I don't know a thing about nanomsg, but in the book they seem to imply that all messages are guaranteed to be delivered and that the messages are send to a background thread and therefore are non-blocking (except for processing the messages, which is up to the user)
14:01:39  <emilbayes>yoshuawuyts: :(
14:03:14  <yoshuawuyts>hmm yeah so with nanomsg processing the messages was: message comes in; STOP THE WORLD; do stuff, regardless of how long it takes; RESUME THE WORLD; send result, take next message
14:03:49  <yoshuawuyts>there's like no way of handling multiple messages like with say require('http'); one message at the time, no concurrency until the message is done
14:04:16  <yoshuawuyts>could ofc spawn up multiple threads using require('cluster') but that's like... 4 messages at the time - probs not what you want, and quite far from how Node's supposed to work
14:04:42  <emilbayes>yoshuawuyts: Oh yeah, so these are concerns about the node.js bindings?
14:05:02  <yoshuawuyts>maybe?
14:05:06  <yoshuawuyts>probably?
14:05:53  <yoshuawuyts>Even if the bindings work, I'm not convinced it's a great idea; nanomsg creator went off to http://libmill.org/ in order to make all of this stuff concurrent (I believe)
14:07:06  <yoshuawuyts>And even when all the bindings are done, still need to like create all the layers on top of it to create a pretty traditional structure; feel either going with an off-the-shelf solution (redis, disque) or torrenty things would be more robust
14:07:13  <emilbayes>yoshuawuyts: Hehe, in the book they seem to suggest that you spawn several threads or child processes, while it's up to language binding authors to handle this best possible in their language
14:07:15  <yoshuawuyts>But that's my take, and maybe I'm boring haha
14:09:20  <emilbayes>yoshuawuyts: I think I'll have to finish the book and see for myself :p
14:09:53  <yoshuawuyts>emilbayes: wrote http://yoshuawuyts.com/workshop-distributed-patterns/build/00.html a few weeks back; might perhaps be of interest
14:10:33  <emilbayes>yoshuawuyts: That's exactly what I saw, and where I discovered nanomsg
14:11:02  <yoshuawuyts>ahhh right ^__^
15:05:49  * gildeanjoined
15:09:39  * Tristitiaquit (Ping timeout: 260 seconds)
15:09:39  * gildean_quit (Ping timeout: 260 seconds)
15:10:42  * Tristit1ajoined
15:25:07  * Tristit1achanged nick to Tristitia
18:33:30  * johnny__joined
18:33:42  * johnny__changed nick to jjjjjohnny
19:04:04  * jjjjjohnnyquit (Ping timeout: 252 seconds)
19:56:49  * jjjjjohnnyjoined
20:06:56  * drptbljoined
20:07:08  * drptblquit (Client Quit)
20:14:27  * saijanai_quit (Quit: saijanai_)
20:39:07  * jjjjjohnnyquit (Ping timeout: 260 seconds)
21:34:04  * ralphtheninjaquit (Ping timeout: 264 seconds)
21:39:50  * ralphtheninjajoined
22:06:54  * jjjjjohnnyjoined
22:19:03  * jjjjjohnnyquit (Ping timeout: 240 seconds)
22:55:49  * jjjjjohnnyjoined
23:22:46  <substack>mappum: working on the malicious update case now
23:23:01  <substack>easy to test if you send max-age: 5 in the http response
23:32:31  <substack>if the tab is still open when the request comes in, I can raise that error in a notification
23:33:44  <substack>but I'm unsure what to do if a tab wasn't open and the page is loaded more than 24 hours in the future
23:37:59  <mappum>substack: i think it still runs the old version first, even if you come back after 24 hours
23:38:17  <mappum>because the update happens in the background after the tab loads the old version
23:38:37  <substack>ah!
23:38:55  <substack>https://github.com/slightlyoff/ServiceWorker/issues/907
23:41:59  <mappum>also https://github.com/slightlyoff/ServiceWorker/issues/761
23:55:07  <substack>maybe appcache can nullify some of these checks in practice, need to test
23:55:24  <substack>but probably not since the worker goes through byte comparison only
23:55:42  * contrahaxjoined