Makes me think of the excellent JSLinux by Bellard, https://bellard.org/jslinux/. Runs Linux / Windows 2000 in the browser with internet and file storage. Or another one which can boot a custom iso you provide, http://copy.sh/v86/
Very interesting demo; a couple of q's: how is it qualitatively different from Fabrice Bellard's JSLinux, apart from the speedup? and what is the use case?
I would argue that the speedup is critical for being practically useful.
In terms of use cases: education, testing, documentation, distribution of applications, safe execution of legacy applications... and there are surely many others
IIRC Tailscale tries to keep their cost at minimum with high NAT traversal success rate so that DERP servers are rarely required. But this approach would always require using DERP servers which would increase tailscale’s bandwidth cost a lot if widely used. I wonder how Tailscale think about this
Hi, lead developer of CheerpX here. The main difference is about the level of performance we can reach thanks to our sophisticated JIT engine. Feel free to try running a payload yourself in v86 vs WebVM to see the difference.
WASM, yes. Tailscale, yes. In the browser, sure, I'll take it.
But what I really want is a capability-based WASM sandbox runtime (like wasmtime or workerd from Cloudflare) that provides an API that lists people that it can send messages to (through Tailscale.)
I configure the runtime with my contacts, and say which apps can communicate with which people.
And then a Dynamic DNS-like system for me to have an identity key, and look up the servers to find them. In case my contacts need to migrate to a new server. Maybe Tailscale already does this?
The runtime keeps the apps updated (like Sandstorm.io).
Maybe it would be nice if tailscale could "peer" with other whitelisted networks that agree and share selected services/endpoints between peers. Given this plus a namespace system (DNS?) you'd be pretty close to a usable, secure, decentralized, p2p mesh network.
"Enarx": Reads like "e-narks", the "e" from email (rather dated as a prefix these days, but we're all used to it), and an intentional misspelling of the plural of "nark", as in one who reports information to the authorities, a snitch, or tattle-tale.
I'm supremely impressed by Sandstorm.io, but I think it was designed kind of like an old BBS. One server, letting users come to it.
What I'm describing, I think could be the basis for federated services.
I imagine implementing RSS feeds and RSS Aggregators on top of a system like this.
And lots of other services, too.
I like the idea of it being capability based and sandboxed, because then I can feel safe running a service you wrote on my machine.
And I like the idea of all of the networking being in the framework, rather than being implemented in each app. Just like Sandstorm.io takes a lot of the problems of sharing out of each app.
The way this article ended up with WASM + Tailscale in the browser seems like a great way for a client to talk to a server based on WASM + Tailscale, like I want. So then my phone can connect to my home PC, running these federated services. I can picture implementing Google Photos on top of that. With sharing, too.
We keep seeing more and more abstractions, but unfortunately they are the wrong abstractions. We need working process isolation, not endless VMs inside other VMs. We need a logical layer on top of TCP/IP, not crazy complicated VPN schemes. Etc. This is completely obvious to some people, and seems completely incomprehensible to others. Unfortunately, the companies with resources are mostly staffed with the latter.
Mind expanding on this? Why are better protocols incomprehensible? I find it hard to believe big orgs like Cloudflare, Google, etc. wouldn't be very interested in abstractions that save them or make them money, but I've been surprised before.
The problem is not that a superior abstraction exists that you can make money from, the problem is that you have to hire people who work well with that abstraction, and that is usually the impediment.
For example, I bet NixOS would alleviate a lot of pain with development and deployment, but the learning curve is steep, poorly documented, and still in need of work, and the community is just not very big yet.
I'm waiting for someone to comment that because some programmer was lazy enough to use Go instead of C or C++, Tailscale module takes 16 MB, when the entire CheerpX VM was 6 MB. Just the stack is almost twice as big as the entire VM.
Why is it written in GO when it could have been written in C? Lazy programmers.
"Structured programming" (AKA the 'for' loop, 'if' statements) had early adopters, and serious arguments over their wasteful inefficiency took place at industry events.
Interesting thought, but realistically what need is that serving besides curiosity?
Even chromebooks have real linux underneath, the scenario you're describing is so niche it's hard to imagine. IMO it makes much more sense to use free tier on a cloud provider
Moving emulators and virtual machines to the Web can be handy for software preservation. The Internet Archive has a massive collection of games and applications that you can run right now, on any device with a browser, thanks to this kind of tech.
Also (speaking from 1st hand experience) some big companies issue laptops that are extremely locked down - with IT needed to install any software and only after it's been vetted. This gives a bit more liberty without crossing any of the security boundaries.
a “cross-platform” assembly format could, in time, make introducing new hardware architectures a bit easier.
for example, these guys link to a discord channel to chat about their work, but i can’t join it easily because even though Discord ships a Linux client, they only ship it for x86 and not arm. further down the road, i’d like to try some RISC-V devices: that’ll be that same experience times ten. a portable assembly format has the chance to overcome this.
We weren't unaware of these things. Wasm is the first low-level format to instantly have broad availability, becoming available in all web browsers in 2017. AFAICT none of the previous formats had low overhead platform-independent in-process sandboxing, and certainly none had a machine-checked proof of type system soundness.
As for how sound the type system is in the face of attacks at the Flash, ActiveX and Java applets scale, it remains to be seen, although there are already some USENIX papers slowly coming up regarding WebAssembly actual security.
hey i’m not saying it will or won’t succeed on that front — just that it’s a motivating factor.
but also, look at its neighbors. Vulkan/SPIR-V has made it standard to ship bytecode-level shaders (graphical or compute) which are device agnostic but still performant. even if we’re cursed to try this “architecture agnostic” stuff a hundred times, i don’t think we can say there hasn’t been any progress. that progress only comes from people trying, even if 9 out of 10 serious attempts are flops.
Isn't Discord's desktop client just an Electron wrapper around their website? It seems like there might be an easier way to get that running on other platforms.
If I wanted the full-fat Discord app (rather than a browser website or PWA, or a third-party client Discord will ban you over), I'd look into https://github.com/SpacingBat3/WebCord (which I think isn't detected and banned, but I cannot guarantee this or that they won't rewrite Discord to the point you can get banned for using it).
Do you have any cases of people getting banned over it? It would be scary, uBlock Origin blocks /api/*/science and it would be terrifying if running an adblocker could get you banned from Discord.
Wasm cannot indeed do much beside manipulating it's own memory and pure computation. Anything interesting happens via "imports", which are arbitrary functions implemented in JavaScript.
The networking capabilities are implemented via a JS API (itself, compiled from Go to WebAssembly/JavaScript). This Go library connects to Tailscale DERPs via WebSockets to provide network access to the Tailscale network of each user. The broader internet can then be also accessed if an exit node is configured.
