kentonv 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
<isd>
No worries.
<JacobWeisz[m]>
Will let you know whether or not to expect me in a bit.
<isd>
If it's looking like it's going to be sparsely attended maybe we should just call it. I don't really have Important Things To Discuss; it would just be a status update on my end.
<isd>
and I wouldn't mind catching a bit of the debate.
<JacobWeisz[m]>
I can be there if we're there, but also don't have much to offer.
<JacobWeisz[m]>
I just need to work on things already on my todo list.
<JacobWeisz[m]>
I still kinda would like a better tracking method for community collaboration, but I am trying to think of an easier way to fit it into everyone's routines.
<JacobWeisz[m]>
Just so we're better able to share progress updates asynchronously.
<isd>
The big things for me: (1) I've been working on some improvements to the haskell-capnp library, mostly pain points that came up when I started working on the backup thing. (2) I've also been working on https://github.com/zenhack/capnpc-node-typescript, which will make internal refactoring in Sandstorm itself much easier.
<isd>
(3) Somebody started talking about adding 3rd-party handoff support to the Go capnproto implementation; have a call scheduled for the end of the week with him & Ross to get oriented. That will be a neat thing to have.
<isd>
Right now I'm working on doing last bits of testing for the cgroup freezing patch, so we can merge that.
<JacobWeisz[m]>
What does third party handoff support do?
<isd>
Right now you can only do point-to-point connections with capnp rpc; we mostly use it for internal connections inside sandstorm and to connect grains to the supervisor. We could expand that to allow programmatic access to sandstorm over a websocket or something. But with third-party handoff, we could more easily "federate" sandstorm instances; if you had a connection between thelibrary.sandcats.io and say
<isd>
ocdtrekkie.sandcats.io, one of those servers could just hand the other a reference to something on alpha, and it's mostly transparent to the code using it -- it's just objects.
<isd>
Of course, this is the Go implementation, so there are questions about how you'd integrate that with Sandstorm core, but once you have one implementation that supports this you can effectively get it for other implementations via a proxy.
<JacobWeisz[m]>
Okay, thanks for explaining it! (Also, awesome!)
jryans has quit [Ping timeout: 244 seconds]
ill_logic has quit [Ping timeout: 244 seconds]
abliss1 has quit [Ping timeout: 244 seconds]
abliss1 has joined #sandstorm
<JacobWeisz[m]>
I wonder if we could create a repo on something like github.com/sandstormports for keeping track of community progress. Since we could be more permissive on granting access to it, and then easily link to issues on both Sandstorm and related apps and projects.
jryans has joined #sandstorm
<JacobWeisz[m]>
I kinda wish you could bring in issues from other orgs on a project board. But I'm still tempted to just like... try it. People could kick open issues to specify "hey, I'm working on this" and then link to whatever relevant projects or PRs or issues elsewhere, and tag them if they are seeking help or feedback or whatever.
michaeln3 has joined #sandstorm
michaeln3 has quit [Ping timeout: 260 seconds]
_whitelogger has joined #sandstorm
<isd>
The lack of ability to manage issues across projects is a real missed opportunity for something like GitHub. Launchpad tried to do something with this iirc.
<JacobWeisz[m]>
The good integrations with the project repos + Matrix sounds like a really worthwhile result.
frigginglorious has joined #sandstorm
<TimMc>
Speaking of capability handoffs, is there anything like a notion of a communication protocol that Sandstorm speaks that could also be spoken by other projects? I'm thinking of both federation (two Sandstorm instances) and also integration (Sandstorm and other projects).
<simpson>
The closest thing is Capn Proto. In Monte-land, that's the avenue we're taking to slowly-but-surely approach something that can talk to Sandstorm.
<TimMc>
I've been designing a social media thingy and I've been struggling with how general (and "welcoming") to make the protocol it speaks.
<simpson>
Oh! You should talk to dustyweb.
<simpson>
They've been working on https://spritelyproject.org/ and are interested in federated capability protocols.
<JacobWeisz[m]>
Like, presumably we can/should support HTTP APIs if practical and relevant for specific things, and where other projects have offered gRPC, for instance, we would use capnp.
<TimMc>
simpson: I've been following his work on and off. It's pretty cool. (Totally different technical approach than mine, though.)
<simpson>
Yep, it seems that all of us are on distinct platforms. I think it's part of being capability-aware; just like how there's multiple garbage collectors, there's multiple vat providers.
<TimMc>
Vat?
<simpson>
A vat is a place where objects live. Vats take turns; during a turn, an object receives a message from outside the vat.
<simpson>
Vats are both important data structures in E and descendants, even though they're just a queue of actions and some networking info; but also conceptually, as ways to organize objects into computational domains.
<simpson>
e.g. classically, a single computer on a network is a vat. Other computers can't access its objects directly and can only send messages in an async manner.
<TimMc>
Ah, got it.
<isd>
TimMc: also worth noting (if this hadn't been clear) that Goblins is more or less the same protocol design as capnp rpc. Ideally we'd make them actually interoperable
<simpson>
Yes. In an ideal universe, there would be only one encoding to choose from, and only one way to construct handshakes. But unfortunately there's uncountably many ways, and most of them are very bad in typical performance metrics. (Where's that Perlis quote about always starting from scratch?)
<isd>
Surely the number is countable; we're talking about computers here.
<isd>
Also part of the problem is herding cats; there's a big design space, sure, but that doesn't mean people's actual needs can't be met with a smaller number. We seem to all do okay with 8 bit bytes.
<isd>
messagepack and cbor are about as close as you could possibly get without actually being compatible. There's not really a good reason to have both of them.
<isd>
Also, line ending standards in text files. No benefit whatsoever to having differences here.
<simpson>
Well, yes, but *why* 8 bits to the byte? Historically, folks have had use for both 7-bit and 9-bit bytes. So this view suggests that all standardization of this type is accidental and due to network effects.
<simpson>
Same thing with line endings in text files. And this means that we're missing out on being *good* or having any useful measurable qualities (parsimony, expressiveness, etc.) because we're at the whim of whatever ends up being popular.
<simpson>
(This is part of why it makes sense that MarkM and other capability folks tried to bend the course of JS standards; they felt that, if half of all programmers are JS programmers, then fixing JS is easier than writing a new popular language.)
<isd>
My point was that you can narrow down the design space a lot of you strip out variation that isn't actually useful. '\r' vs. '\r\n' vs. '\n'... windows doesn't actually gain anything by not just doing what unix does, it's just an accident of history.
<isd>
I'm not saying there's no room for useful innovation. But a lot of the variation is entirely incidental and doesn't really buy us anything.
<simpson>
There were business reasons why Windows did things differently. They were canny, in the 90s; some things were just compatible enough to entice folks to move to Windows, but not compatible enough to allow folks to go to Novell or OS/2.
<simpson>
To this day, we still see slapfights over the "universal" USB standard. The first slapfight was between Intel and VIA, and today's contenders include such ~luminaries~ as Nintendo, Sony, and Apple.
<isd>
Is the line endings thing actually one of those things where the difference was intentional?
<simpson>
I cannot prove at all why it is that only some 90s-era Windows editors supported non-Windows line endings. I'm sure that somebody somewhere has investigated it.
<simpson>
(Honstly, maybe Conway's Law is the answer. MS infamously breaks teams up into very small pieces; there probably wasn't any coordination between the different text-editor groups other than through common groups who wrote their text-editing widgets.)
<simpson>
(Maybe Conway's Law is our answer, too. We have multiple codebases maintained by multiple teams; no wonder we don't speak the same protocol all the time!)
<isd>
Yeah, that's more or less my point -- I think much of the variation is just a "people coordinating" problem, not one of actual meaningful design trade-offs.
<JacobWeisz[m]>
And often the largest player in a space has little reason to coordinate with smaller players.
<simpson>
We *do* have design trade-offs, though, for sure. Like, there's no better way to explain why Monte is slow but Capn is fast; Capn makes speed a top priority and Monte explicitly has other top priorities.
<JacobWeisz[m]>
Even if it's trivial to do so, they may just "gain nothing" from a business standpoint.
<isd>
simpson: that I would certainly agree with. But see messagepack vs. cbor, which hit exactly the same spot in the design space while also being incompatible.
<simpson>
isd: Yeah. I very much wish for categorical presentations, in the sense that there should be some sort of obvious natural way that these incompatible-yet-similar things can be transformed into one another. It's deeply frustrating to have to write code over and over and over again.
<dustyweb>
hi hi
<dustyweb>
TimMc: if you'd like to talk at some point, let me know
<isd>
ahoy.
<dustyweb>
we also have a #spritely channel here on freenode
<dustyweb>
you're welcome to join
<dustyweb>
hi isd !
<dustyweb>
btw I was wondering: I know that Sandstorm was designed to be fairly general purpose as a capability operating system containment environment with communication between processes
<dustyweb>
but most of the uses I've seen have all involved the web interface
<dustyweb>
it has made me wonder, how well could sandstorm be composed with something like guix where guix composes its own packages
<dustyweb>
but then sandstorm isolates and links them together
<dustyweb>
mostly ignoring the web stuff?
<isd>
So it's maybe not totally general purpose in that he web-app use case informs some of the decisions we make in setting up the sandbox, e.g. no tty or gpu access, because web app backends generally don't need those and it's extra attack surface.
<dustyweb>
isd: I see
<dustyweb>
isd: but I assume it *could* be generalized
<dustyweb>
but hasn't been yet?
<isd>
Yes, probably
<dustyweb>
wayyyy back in the day, before I knew much about ocaps
<dustyweb>
when we had the whole "userops" discussions
<dustyweb>
there was a false pitting between myself and another guix person against someone involved in sandstorm where it was like "reproducibility VS binary black boxes that you don't have to trust". well, now that I know more about ocaps I think that was a really goofy thing that we had that debate
<dustyweb>
the correct route is a defense in depth approach
<dustyweb>
that combines both
<isd>
Indeed.
<isd>
I think guix could very well be used to build sandstorm .spk packages today. I've had building a tool that does that with nix perpetually on my TODO list.
<dustyweb>
isd: Guix currently has a very nice build backend system
<isd>
...but even without a nice polished tool it wouldn't be hard to put something together on top of the existing tooling.
<dustyweb>
that can even build docker apps and etc
<dustyweb>
as well as universal binaries that can run on any linux-api-running system
<isd>
Yeah, I'm aware. I believe nix has much of that as well. It's mostly a matter of I need to sit down and put in the time... and there are so many other things.
<dustyweb>
isd: understandable
<dustyweb>
isd: it's probably a good idea to see about separating out the core layers of Sandstorm: the container and process-connection part, and the web stuff, and whatever the image stuff is as one layer... then the web-specific stuff built on top of it as another
<dustyweb>
if that can be done
<dustyweb>
it's easier for a) sandstorm to be more usable *generally* for guix users
<dustyweb>
and b) also easier to make the build tools in guix for sandstorm packages
<dustyweb>
however I realize that's probably a lot of work
<dustyweb>
however, composition is typically the programmer bingo free space for good reason :)
<isd>
fwiw, from an API perspective, it's pretty clear what an alternate-UI sandstorm app would look like: if you look at UiView in grain.capnp, you'll see that the newSession methods ask for specific interfaces; right now we always ask for WebSession (from web-session.capnp), but we could do something else for e.g. something built on wayland.
<isd>
Also, I do believe the flatpak folks cribbed some of our sandboxing code. But didn't keep the capnp APIs and thus dropped all the ocap stuff...
<isd>
I think before you went about trying to separate out the layers you'd have to have a clearer picture of some examples of what you might want to swap things out with.
<isd>
Otherwise I think you run the risk of building an abstraction that isn't actually useful to any real applications.
<dustyweb>
isd: that could be true
<dustyweb>
isd: also this isn't high priority for me
<dustyweb>
but something that was on my mind and thought I'd bring up while it was :)
<simpson>
Well, it'd be more useful if we had some sort of minimal vat-in-a-process, a bare-bones rich container for objects.
<dustyweb>
+1 to simpson
<dustyweb>
isd: relatedly, you asked whether or not there was any discussion publicly about getting Spritely's CapTP and Agoric's to work together. I'm literally writing up the issue right now!
<dustyweb>
will like once I'm done.
<simpson>
Specifically written in something like Go or OCaml, so that the actual artifacts we're working with are not dependent on dynamic linkage. (For dynamic linkage, there's CloudABI...)
<simpson>
(And this is why it sucks that I don't have a native compiler for Monte! I don't wanna write Go. OCaml's not bad, I guess.)
<dustyweb>
OCaml, my Caml
<isd>
It would be neat to have some command you could run like ocap-sandbox /path/to/app-package /path/to/grain/storage and it would set up the sandbox and give you a socket to talk to the app inside it. I'm not sure how far away the supervisor is from being that, but it might be less work to canabalize bits of it than try to make the change in-tree without being disruptive.
<isd>
simpson: are you talking about writing the sandboxing tool itself in OCaml/Go, or the thing being sandboxed? If the former, then you're talking about a re-write anyways (since the existing code is C++), if the latter, I'm not sure I understand the problem?
<simpson>
isd: Imagine a minimal viable network of objects communiating using Capn buffers. IOW the objects are the ones that Capn can possibly address. It would be cool to have a minimal vat which does nothing but run those objects, along with checkpointing support and etc.
<isd>
Also, I would not use Go to set up a sandbox like this; there are thorny issues with shared process state in multithreaded programs and dropping privileges, and so I would want a language whose runtime doesn't do much. Honestly I'd probably just do it in C; the logic is just syscall(); syscall(); syscall(); ... higher level language features don't really buy you much for this use case.
<isd>
(It scares me that the docker folks do this in Go)
<simpson>
I'd do it in C, but I don't have the skill to avoid messing up. I need something more structured.
<simpson>
And yes, if the process hosts multiple vats and does something like thread-per-vat, then there's extra stuff to be desired from the host language; OCaml clearly has an advantage over Go there.
<isd>
I don't think we're on the same page about what we're talking about building.
michaeln3 has quit [Ping timeout: 256 seconds]
<simpson>
Probably not. But that's okay! I'm not talking about sandboxing at all, if that helps. The language being hosted doesn't need a sandbox, because it's cap-aware and tamed already.
michaeln3 has joined #sandstorm
<isd>
Ah, yes you are talking about something very different than me.
<isd>
I was still on the "factor out Sandstorm's thing" track.
<simpson>
Ah. I'm imagining what comes after that, I guess. Or perhaps I'm completely lost! It happens.
<isd>
dustyweb: thanks. I'll weigh in on the capnp side of things. It may be that the points in the design space are a bit too different for us to literally use the same protocol, but maybe we could at least make sure it's possible to design a bridge...
<TimMc>
Content-addressed DAGs get written to (and read from) HTTP-accessible file servers. You bring the file server for your 20 closest friends: S3, an Apache server under the couch, etc. All end-to-end encrypted. Polling-based, with an option for a subscription server as a sort of an optional turbo-booster later. :-)
<TimMc>
Identity is a mix of cryptographic and URL-based, but cryptography helps with nomadic identity.
<TimMc>
Not exactly federated, but I have no illusions that everyone will run/pay for their own server. :-)
<TimMc>
Think peer to peer, but asynchronous, and using file servers as "pipes".
<TimMc>
I'm hoping to keep the protocol dumb as dirt, aside from the crypto.
<TimMc>
(I want there to be lots of implementations!)
<isd>
Ok, left a comment re: capnp
ill_logic has joined #sandstorm
catern has joined #sandstorm
<catern>
so that durable objects thing sure is cool huh
<CcxWrk>
TimMc: Your PKI scheme seems to have same set of issues as PGP key revocation. I assume. There no mention of revocation or or operation ordering and that's something to design first if you want to have them. Also no mention of forward secrecy which is big red flag for me.
<abliss1>
catern: i'm hoping kentonv's like a virus. once you hire him into your company, he quietly injects strands of DNA and soon your company is using its engineers to produce capability-oriented products
<CcxWrk>
TimMc: You probably want to also mention whether you are aiming for non-repudiable or repudiable message signatures.
<catern>
abliss1: let's hope for a R >> 1 then
<JacobWeisz[m]>
abliss: That's possibly why I'm excited about lots of Cloudflare things now.
<abliss1>
that would require the company's engineers to become adept capability zealots and then go get hired at other companies. Not sure if he's figured that part out yet
<catern>
it's true that I've become a cloudflare stan now heh
<TimMc>
CcxWrk: Yeah, revocation is hard. In doc/ideas.md there are some notes on a social model of (unplanned) revocation, where the gossip protocol can distribute non-authoritative revocation information. I think it needs to piggyback on the social layer.
<TimMc>
Messages are repudiable, which I think is pretty important.
<TimMc>
(I could have sworn that was mentioned somewhere.)
<catern>
abliss1: I guess the obvious mechanism for R >> 1 is for various Cloudflare capability components to get open sourced and then carried to other companies by their various maintainers
<CcxWrk>
Well, the thing is we have revocation when we actually want rollover. But you can't do access control changes (including key rollover) in an eventual consistency protocol.
<TimMc>
Hmm, that's an interesting way of putting it.
<simpson>
Honestly, I think memes do better than people. The meme of unguessable URLs for stuff like password resets turned into Google Docs URLs as capability URLs for sharing.
<CcxWrk>
And for serializability of protocol you need ordering, which is hard to design securely in distributed setting. You either do distributed consensus (but PoW sucks) or transparent data structures like CT.
<CcxWrk>
So currently in my free time I'm working on way to express arbitrary access control and/or key signing logic in a way it could be easily serialized and verified by transparent log service.
<TimMc>
By ordering you're referring to things like whether or not a revocation came before an authenticated message?
<CcxWrk>
If you have key rollover message you need to make sure no other key rollover can come in and claim it came before.
<TimMc>
Mmm. So maybe a socially attested chain of some sort.
<CcxWrk>
Or in general imagine split brain where one part thinks control has passed from Alice to Bob, while other sees Alice passing control to Eve. Since both operations remove capability to issue the other one from Alice they cannot be converged.
<CcxWrk>
You can do social attestation like Keybase. But I find that both rather limited and also leaking too much metadata.
<TimMc>
If a mismatch can be *detected*, you can always alert the user that something is up.
<TimMc>
Too much metadata, ot leaking it too widely?
<TimMc>
*or
<TimMc>
I want to have a contact gossip protocol that preloads clients with the keys (and key updates) of everyone within N degrees of separation, but oh man is that *fraught*. ("Ugh, I can't believe you've friended Terry!")
<TimMc>
(Knowing who knows who wouldn't be a first-class feature, but it would be hard to prevent that kind of leakage.)
<TimMc>
I don't have a good solution on the forward secrecy front. I don't know how to do that in an offline protocol.
<TimMc>
The best I got is high-entropy object IDs, making it harder to stockpile the encrypted data in advance of a key leak.
<TimMc>
(Is it even *possible* to have forward secrecy without multiple roundtrip communication?)
<kentonv>
abliss1, catern, hah... my secret plan is to build a platform people want to use for other reasons, but also make it capability-based, so that people realize how much nicer it is and start designing their own stuff that way
<CcxWrk>
TimMc: Well, in Keybase's case it was making the social graph public. But if you don't do that you have to have secure contact list intersection. And also accept the fact bootstrapping will be hard.
<CcxWrk>
Commonly used approach to semi-offline PFS is double ratchet (Noise, Signal, OMEMO). But that works in 1:1 setting only and looses some nice properties when you try to do multidevice or multiuser things with it.
<CcxWrk>
TimMc: "private set intersection" are the key words to look up if you want to take the social attestation route.
<TimMc>
Thanks, I'll take a look!
<CcxWrk>
But I'm kinda suspicious of those algorithms, partly because I haven't studied them, partly because of their relation to homomorphic encryption.
<TimMc>
For bootstrapping I was planning on just TOFU -- ask the server for the key to use, use that for starters.
<TimMc>
(And then gossip from there.)
<TimMc>
This whole thing has been an exercise in compromises. -.-
<CcxWrk>
My approach tries to go for a federated setup where you can't prevent instances from lying but it's trivially easy to show if they did. And users could require OCSP-staple style verification from different instances.
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 260 seconds]
frigginglorious1 is now known as frigginglorious
dustyweb has quit [Ping timeout: 260 seconds]
frigginglorious has quit [Read error: Connection reset by peer]
frigginglorious has joined #sandstorm
frigginglorious has quit [Ping timeout: 264 seconds]
<TimMc>
One of my design constraints that is rather unusual in this space is requiring no custom server software. I don't know if I'll end up bending on that one eventually.