kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things Say hi! | Have a question but no one is here? Try asking in the discussion group:
<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"
<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
<isd> In this context kopia is nice since it already does encryption.
<blowfist> well as we speak, is there a mean to backup all the grains you own?
<JacobWeisz[m]> As a server admin you can stop Sandstorm and then back up the file system.
<JacobWeisz[m]> As a user, you could mass transfer to another Sandstorm server.
<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.)
<blowfist> ah yeah, the mass transfer button
<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
<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
_whitelogger has joined #sandstorm
<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?
<isd> You mean exposing an API?
<blowfist> yes
<isd> Yeah, I think that's something we'll want to do at some point.
<isd> There are a few issues where it's been mentioned.
<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.
<blowfist> as long as it doesn't add too much burden to the app devs
<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.
<blowfist> the postMessage API, the webKeys?
<isd> Not sure what you're asking?
<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.
<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
<isd> No, different thing
<JacobWeisz[m]> What's postMessage again?
<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
<isd> It's a relatively minor thing
<JacobWeisz[m]> Ah, I haven't used those.
<isd> But extending APIs like that is always a little weird in that there's no explicit "here's how you do protocol evolution"
<isd> whereas with capnp we can add new methods & interfaces, and there's a clearly defined way that the protocol can evolve.
<isd> powerbox requests also currently go through postMessage, as does setting the url path
<isd> Like I said, there are a handful of one-off things you can do by sending postMessage calls to the parent window.
<isd> It's just a little too ad-hoc for my tastes.
<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...
TMM has quit [Quit: - Chat comfortably. Anywhere.]
TMM has joined #sandstorm
pie_ has quit [*.net *.split]
ecloud_ has quit [*.net *.split]
ecloud_ has joined #sandstorm
pie_ has joined #sandstorm
_whitelogger has joined #sandstorm
frigginglorious has joined #sandstorm
TimMc has quit [Ping timeout: 256 seconds]
TimMc has joined #sandstorm
_whitelogger has joined #sandstorm
CcxWrk has quit [Remote host closed the connection]
TMM has quit [Remote host closed the connection]
CcxWrk has joined #sandstorm
TMM has joined #sandstorm