00:16 <isd> I'd like to have a default "here's how backing up sandstorm & grains works," and I think anything that fills that role has to be configurable through the Sandstorm UI somehow. So if we were to integrate kopia we'd probalby build some UI around it I think. But I noticed it had a webdav backend and was like, "oh, I could use this to back up my laptop to a davros grain"

00:18 <isd> But yeah, I think being able to use a remote grain as your backup storage for sandstorm would be a great way for users to provide one another with off-site backups; just sync them to a friend's Sandstorm box

00:18 <isd> In this context kopia is nice since it already does encryption.

00:35 <blowfist> well as we speak, is there a mean to backup all the grains you own?

00:36 <JacobWeisz[m]> As a server admin you can stop Sandstorm and then back up the file system.

00:36 <JacobWeisz[m]> As a user, you could mass transfer to another Sandstorm server.

00:37 <JacobWeisz[m]> (Mass transfer probably could be used as the basis of a Sandstorm aware backup system... Your backup location could be a non-publicly accessible Sandstorm server.)

00:46 <blowfist> ah yeah, the mass transfer button

00:48 <blowfist> JacobWeisz[m]: it would indeed be interesting to know how the mass transfer button works so we could try to make some external program to get all the grains data

00:50 <blowfist> or an alternative means similar to the mass transfer button that would make it possible to use either davros directly or some more elaborate backup solutions like kopia

00:57 <blowfist> isd: would it be possible to add standard commands to the HTTP interface? It would be interesting to be able to backup grains that way, no?

00:59 <isd> You mean exposing an API?

00:59 <blowfist> yes

00:59 <isd> Yeah, I think that's something we'll want to do at some point.

00:59 <isd> There are a few issues where it's been mentioned.

01:00 <isd> I kinda want it to be a capnproto-over-websockets thing, just because I only want to support so many disparate rpc mechanisms as public APIs.

01:01 <blowfist> as long as it doesn't add too much burden to the app devs

01:01 <isd> Relatedly, some day I'd like to deprecate (but not remove) the postMessage API used by grains in favor of something capnp -- but we need an implementation of capnp that runs in the browser first for that.

01:03 <blowfist> the postMessage API, the webKeys?

01:05 <isd> Not sure what you're asking?

01:05 <isd> ocdtrekkie: btw, do you know if we have a full listing of the stuff available through postMessage in the docs somewhere? individual mechanisms are documented, but I'm not sure if there's just a central index somewhere.

01:09 <blowfist> isd: I don't know what the postMessage API is exactly. I was just hoping it wasn't the interface exposed with the webkeys

01:09 <isd> No, different thing

01:09 <JacobWeisz[m]> What's postMessage again?

01:10 <isd> e.g. https://docs.sandstorm.io/en/latest/developing/path/#using-the-grains-title-in-your-app

01:11 <isd> There are a handful of ad-hoc calls like that that you can invoke via the browser's postMessage mechanism. Ideally I'd like to have somehting a bit more structured, maybe just using postMessage as a transport for capnproto

01:11 <isd> It's a relatively minor thing

01:12 <JacobWeisz[m]> Ah, I haven't used those.

01:12 <isd> But extending APIs like that is always a little weird in that there's no explicit "here's how you do protocol evolution"

01:12 <isd> whereas with capnp we can add new methods & interfaces, and there's a clearly defined way that the protocol can evolve.

01:13 <isd> powerbox requests also currently go through postMessage, as does setting the url path

01:14 <isd> Like I said, there are a handful of one-off things you can do by sending postMessage calls to the parent window.

01:14 <isd> It's just a little too ad-hoc for my tastes.

01:15 <isd> We've also got the meteor methods, but those aren't exposed to grains in any way, and not really considered 'public'. And I don't really want to make them public, because then we have two entirely separate rpc mechanisms we're exposing to developers...