I just stumbled upon Web Containers, which is essentially one company’s effort to port node.js to the browser using WASM:
Here’s where it gets interesting, esp. in regards to Sockethub, and maybe also local RS servers:
WebContainers include a virtualized TCP network stack that’s mapped to your browser’s ServiceWorker API, enabling you to instantly create live Node.js servers on-demand that continue to work even when you go offline. Because it runs entirely within the browser security sandbox, server responses have less latency than localhost
If I understand this correctly, it would mean that we could run Sockethub locally in the browser, alongside unhosted web apps, correct?
Yeah Redis is for processing large amounts of requests from multiple users. If we have just one user, we could probably just implement a simplified startup mode (--web-container)? which would still do the websocket->schema validation then skip the separate platform processes & redis, and go straight to calling the platform.
I wonder how it behaves though with TCP sockets, this is one of the issues with running anything in the browser, the browser sandboxes code against opening non-web ports. I imagine this operates within the same set of restrictions, though I haven’t been following browser tech as closely as I was a few years back, so things could have changed in this regard.
Yeah, so that’s the big question. They make it sound as if everything just works, but I thought SW are still restricted to Web APIs like Fetch and WebRTC.
It’s as we expected: only HTTP connections are possible. Calling that a “virtualized TCP network stack” is just hyping it a bit too much.
We’re limited by the browser’s ability to make network requests, so connecting to processes like MongoDB, Redis, PostgreSQL, etc. are not currently possible. This may change as Chromium plans to ship Native Sockets in the future. For now, we’re limited to HTTP connections, but we’re able to support other protocols that run on HTTP such as WebSockets. HTTP requests to external services must be allowed with CORS or a CORS proxy.
The Sockethub landing page still suffers from not having a live instance to demo. But it makes sense not to run an open relay.
Suppose, though, that instead of a live server, there was an embedded widget that used a build where the network interfaces were wired up to be serviced by XHR/fetch in the browser, to the maximum extent possible. The user would still be responsible for providing either a URL to a CORS-friendly resource or pasting the payload into a textarea.
Pasting a URL that results in a blocked request isn’t going to provide the desired respnose, and trying to connect to a host running ircd or that speaks XMPP is clearly not going go anywhere, but that’s an opportunity to explain and suggest setting up an instance or trying a different URL—and meanwhile, visitors are still able to get a feel for how it works on inputs that the widget doesn’t fail on.
(In cases where a user shows up and pastes the feed for their own blog which turns out to be hosted somewhere without CORS enabled, maybe they’ll go off and fix it.)
Case study: the new-ish joint ACM/IEEE chapter for Austin put up a vibe-coded site about a month ago: https://local.acm.org/acm-austin/ These are volunteers, and this is approximately the amount of effort they’re interested in dedicating to this.
For the real-time event countdown on the landing page, they have hardcoded placeholder data to get around the fact that they don’t have API access to Luma and/or Meetup. (As a consequence, the current countdown is wrong; there’s an event today at 6PM, but the countdown shows 34+ days before the next one, due to [1].) Luma provides an iCal link (view-source:https://api.luma.com/ics/get?entity=calendar&id=cal-HidBA3hMcIwKB1L), but not RSS. (It doesn’t support CORS, but CORS workarounds are widely available.)
If it were easy to demonstrate and validate that Sockethub could handle the ICS payload (by copying-and-pasting the contents, à la tools.simonwillison.net, onto the Sockethub landing page and checking the output) and there were a build that worked in the browser (or, bonus, if the aforementioned widget were also embeddable and not just on the sockethub.org landing page), then I could show up tonight and say, “Look, here’s Sockethub. Use it.”
(This is only exercising like 30% of the functionality and current value proposition of Sockethub, and they could just use an ICS parser library from NPM, but who cares.)
I’m referring not just to the general concept in that thread, but specifically to:
Infrastructure is not my strength but I could contribute by writing guides and maybe doing video tutorials on how to set up on those platforms. And I would like to run my own instance so I could also test.
And to expand on what I wrote here:
The history of post-jQuery web development and everything that came afterwards shows how willing people are to copy and paste boilerplate to keep using The Thing They Know or to Try The New Thing instead of writing the 12 lines that it would take to actually toggle the div they want to hide or whatever.
