isd changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev | This channel is logged at: https://freenode.irclog.whitequark.org/sandstorm/
<jimpick> i have been using node.js + wasm (and wasi too) with success
<jimpick> (other projects)
<jimpick> Deno is fun because it gives you another layer of sandboxing (like a browser) compared to Node.js ... but it's also difficult if you want to rely on an existing npm package that hasn't made it over to the deno ecosystem yet
<jimpick> ... also, I used to work with Ryan Dahl back in my Joyent days and it's fun to see what he's up to lately
<isd> Lavamoat is a thing worth knowing about, re sandboxing.
<jimpick> Yeah. I played with it and watch kumavis' talk on it a few weeks ago
<jimpick> I did a SES-based chat bot a few years back https://github.com/jimpick/cabal-ses-bot
<jimpick> Lavamoat is really neat - it can sandbox individual npm modules
<isd> jimpick: fwiw, you don't necessarily need wasm/wasi to do what you're discussing -- you could just have it exec() a static Linux executble.
<jimpick> i understand that. WASM is interesting if you want to do apps that work on ARM as well as AMD64 (or more exotic things like RISC-V) ... you could ship the WASM file and the capnp file .. but the runtime would need to be different per arch
<isd> True, though we're not there yet since Sandstorm doesn't yet run on anything but amd64
<jimpick> of course, you could just run qemu style VMs instead of WASM on those archs
<jimpick> WASM is a much simpler model ... and probably much faster since there's a compiler arms race between the big vendors to make it go fast
<isd> yes.
<jimpick> the new arm based macbooks run x86/amd64 code almost as fast as arm code under their emulation system, so it's probably not so much a performance win as just having a simple super secure sandbox environment
<xet7> In that sandstorm-rawapi-example I get: /opt/sandstorm/latest/usr/include/sandstorm/util.capnp:97:28-34: error: Not defined: stream
NekoIncardine has joined #sandstorm
xet7 has quit [Quit: Leaving]
<isd> xet7: update your capnproto
<isd> 0.8 or later should be enough
nicoo has quit [Remote host closed the connection]
nicoo has joined #sandstorm
digitalcircuit has quit [Remote host closed the connection]
crab has quit [Ping timeout: 240 seconds]
digitalcircuit has joined #sandstorm
crab has joined #sandstorm
<JacobWeisz[m]> So I need both a "under 140 characters" short description of Sandstorm, and a "under 500 words" long description of Sandstorm.
<JacobWeisz[m]> I am not positive our GitHub About is still the best choice for that description.
<jimpick> "Sandstorm is a self-hostable web productivity suite. It's implemented as a security-hardened web app package manager."
<jimpick> yeah, that's a bit meh
<JacobWeisz[m]> There was a lot of debate during Sandstorm's startup days whether it wad an app platform or a productivity suite.
<jimpick> It's actually an operating system :-)
<JacobWeisz[m]> That is how I like to think about it.
<JacobWeisz[m]> But it is hard to sell people an operating system in the cloud.
<JacobWeisz[m]> Because what is an "operating system", really?
<JacobWeisz[m]> We can be a little more technical with these descriptions, but not too much.
blowfist has joined #sandstorm
<jimpick> it is a system for operating
<jimpick> :-)
<jimpick> fine-grained privacy-oriented self-hosted app runtime
<jimpick> that's a mouthful too
blowfist has quit [Ping timeout: 240 seconds]
<jimpick> individual-empowered productivity ecosystem
<isd> Some of the current branding is I think partially motivated by a "how to we sell this" mentality, rather than just a "how do we explain this" -- as the business was trying to figure out how to do enterprise sales, and get more directly to "here's what you can use it for"
<isd> Which has value, but I do think it kinda obscures what it's really about.
<isd> But this is the problem with system components in general: they're inherently somewhat nebulous, since they are not the application itself, but infrastructure to support it
<jimpick> yeah, it has that startup fundraising baggage to shed
<isd> The phrase "personal cloud computing" suggests a nice metaphor for the time sharing -> PC transition of Yore.
<isd> Other taglines: 'The "cloud" is other people's computers -- Sandstorm is yours."
<isd> But that's not really an explanation as such.
blowfist has joined #sandstorm
<jimpick> "Sandstorm ... we can't explain it, you just have to experience it ..."
<isd> Ha
blowfist has quit [Ping timeout: 260 seconds]
blowfist has joined #sandstorm
<jimpick> classic
<isd> I do think it's worth taking seriously the idea that no 140-character summary exists that will explain it well to most people.
<isd> So the question then is, if that's all the space that you have what should you do with it?
<isd> Probably something other than explain what Sandstorm is.
<jimpick> it's got a lot of similarities with docker ... but i think the value is in the sandboxing and how it takes auth and document management out of the apps and gives it to the powerbox which puts the user in control
<jimpick> open source apps deconstructed for privacy and productivity
<JacobWeisz[m]> Ian, I forwarded you the email so you can see.
<isd> Cool, will have a look soonish
xet7 has joined #sandstorm
xet7 has quit [Remote host closed the connection]
xet7 has joined #sandstorm