A good mental model to have is AWS Lambda or other "serverless" cloud functions - you don't have to worry about the setup and security of the host server itself because it isn't the server itself you care about, it's the result of a particular run of code or data access that you're concerned with. The hardware is slightly abstracted away.
The short answer for both of you for the moment: most security risks are about unwanted access or OS vulnerabilities.
For the latter, the flippant answer is "our OS will just not have vulnerabilities". That sounds like a bullshit answer, but our entire stack from the kernel to userspace has a very contained footprint, no dependencies on external code or libraries, our compiler binaries are human readable so nowhere for exploits to hide, and the privileges/access of any additional applications you install will be transparent to the OS and auditable by you. When you have typed, pure functional programming up and down the whole stack, deterministic guarantees like that are feasible.
Re: unwanted access: Our OS should be thought of like a VM. So either a slightly technical person takes the most rudimentary steps to insure a host machine they fully control has access control handled (this isn't that hard. SSH settings + firewall); or a totally non-technical person has a hosting provider (or friend or family member!) handle that detail for them on mamaged hardware.
Kind of vague response for now, but as the weeks and months roll on we'll have more authoritative technical documentation to link to in place of my blathering.
What’s the difference between Kinode and Vaporware (is that the name of your company?) then? Both use wasm to containerize the apps right?
We don't use WASM, we use an entirely new computational model called PLAN and a new Lispy/Haskelly functional language called Sire. The core of our system is an SSI (solid state Interpreter), Kinode's is not. (We'll have a blog post with a frendlier definition of the SSI soon, but for now there is this whitepaper that introduced this concept to the world: https://media.urbit.org/whitepaper.pdf . Disclaimer though that we are not building on Urbit, it's just that the SSI is a general concept.)
We've got some explanation of PLAN here: https://vaporware.gitbook.io/vaporware/overview/overview#persistence-plan
Kinode's identity/networking layer requires blockhain integration. Our networking and identity are optional, freely-chosen by the user, and compatible with standard, blockchain-less cryptographic keypairs very much like Nostr. In fact, you'll be able to use your Nostr keys as identy in our system!
Oh! So maybe then we can think of a spectrum from least to most groundbreak/different like
Umbrel
Kinode
Vaporware
Plunder
Urbit
Vaporware is right in the middle. Nice!
Yea! I like that.
I think you'd want "Solid State Interpreter" at the bottom, rather than "Urbit" as technically urbit is *A* solid state interpreter. But your framing is good regardless
I’m in. Let me know how to be an early adopter haha
🤝
As of this moment we don't yet have any more user-facing toys to play with (we had a few limited demos a couple months back. New ones are in the works).
If you're a developer and want to check out the system as it stands today I could point you to the docs.
If you want to just hang out and talk about whatever and find out about things as they develop, you could join our telegram: https://t.me/vaporwareNetwork
I'll always post relevant stuff on Nostr, too, if you prefer that!
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
In an environment where a host VPS is running an instance of the Vaporware Operating Function, the host VPS might be compromised, but so long as our VM is encrypted and the user has redundant versions replicated elsewhere, an attacker exploiting the VPS via this attack would get nothing more than a bunch of encrypted bytes.
In the (further) future when we're running on bare metal or on mobile devices (like Android forks) - no.
Thread collapsed
Thread collapsed