00:17 <ocdtrekkie> You'd think people would realize by now that piping all of your keyboard input to a cloud service might end in Bad Things(TM). http://www.theverge.com/2016/7/29/12326152/swiftkey-bug-backup-sync-down-error-prediction

01:38 <digitalcircuit> Good thing Windows doesn't do that by default.. wait. (And Google Keyboard for that matter)

03:55 <ocdtrekkie> digitalcircuit: Yeah, I have to disable a lot of things.

03:55 <ocdtrekkie> If only Sandstorm was my operating system too.

03:55 <digitalcircuit> Qubes OS, sorta?

03:55 <digitalcircuit> Not quite as friendly though.

04:35 <ocdtrekkie> I'm kinda sad kentonv is on vacation because when I see a serialization protocol announcement post on HN, I expect to see kentonv's opinion of it.

05:53 <GauntletWizard> jparyani: Did you break that again? I'm suddenly getting a failure "remote exception: expected iter != bridgeContext.sessions.end(); Session ID not found; id = 0"

05:54 <GauntletWizard> I swear this worked yesterday

06:17 <GauntletWizard> Ah, because it actually *does* care about sessionid, it just counts session from zero

06:20 <asheesh> Ah hah GauntletWizard, you're Ted, great to e-see you.

06:28 <GauntletWizard> Good to see you too

06:28 <GauntletWizard> I am unfrustrated!

06:28 <GauntletWizard> And almost ready to actually package this thing up

06:32 <asheesh> Egad

06:36 <jparyani> Ya sorry was afk, but ya you're correct. I guess it does care about sessionId :)

06:37 <GauntletWizard> I misinterpreted what you meant way back; thought that 0 was a fake session id, not the obvious start to real ones

06:38 <GauntletWizard> is session-guessing a security concern? I would have assumed them to be randomized, but eh, why?

06:39 <asheesh> FWIW, it's being run by the app so I see it as very similar to UNIX file descriptors.

06:39 <asheesh> The app could decide to try to read from stdout or something, or write debug data to a network socket it opened rather than to stderr, and it's up to the app to do that if it really wants.

06:40 <asheesh> But yeah, I had assumed they'd be random too before I saw code that used them and saw the numbers.

06:40 <GauntletWizard> yeah, it makes sense

06:41 <GauntletWizard> Argh! What'd I miss; it's broken on my live server.

06:41 <asheesh> Perhaps a problem where the pack'd SPK doesn't have all the needed files

06:41 <asheesh> ?

06:41 <asheesh> If so, a dev server should be able to reproduce the issue.

06:41 <asheesh> (so long as you upload the SPK to the dev server)

06:43 <GauntletWizard> point

06:48 <GauntletWizard> huh

06:48 <GauntletWizard> getting a Grain's package not installed

06:50 <asheesh> When you ^C spk dev, that happens

06:50 <asheesh> At that point, you need to restart (vagrant-)spk dev, or upload the SPK file.

06:50 <asheesh> You have to reload the grain page to trigger it re-checking for the Grain's package.

06:50 <asheesh> This is like the only one element of Sandstorm that's not reactive.

19:01 <ocdtrekkie> o7

19:31 <asheesh> OH RIGHT HI ocdtrekkie

19:31 <ocdtrekkie> Hi

19:31 <asheesh> We were going to video-chat etc but I forgot but I can do that now, or nearly-now in 5 min or so.

20:52 <asheesh> Hi mnutt : )

20:58 <mnutt> hey asheesh!

21:02 <mnutt> anyone have the link to the wekan board with the app ideas / progress?

21:04 <asheesh> I'm sure ocdtrekkie does

21:04 <sknebel> mnutt: this one? https://oasis.sandstorm.io/shared/3T7_gZPyWs9BuuTNoWRSa3ZqLv6F-4-IdYUvKYmcs-y/b/sandstorm/libreboard

21:05 <mnutt> that would be it! thanks

21:08 <ocdtrekkie> I kinda wish there was a somewhat more structured/persistent way to put out such community grains.

21:08 <mnutt> totally agreed

21:08 <mnutt> I was thinking of porting http://tympanus.net/Development/GammaGallery/ and adding a backend/simple management UI

21:09 <ocdtrekkie> Things in both IRC (faster) and the group (slower) get buried by new items in discussions. No sorting or stickying like a forum currently.

21:09 <ocdtrekkie> Interesting

21:09 <ocdtrekkie> With static publishing, I assume?

21:10 <mnutt> yeah. you'd upload a bunch of files, choose a few options (light/dark theme, etc) and then hit 'publish'. It would use vipsthumbnail or something to generate a bunch of different sizes, then publish those + the index.html statically

21:10 <mnutt> lychee is great, but the publishing is a bit awkward

21:11 <asheesh> This is pretty cool.

21:11 <asheesh> I still think someone should write a "Make a static site" plugin to GNU MediaGoblin, but I'd also be excited to use something like GammaGallery.

21:12 <asheesh> ... turns out Kenton Varda has already struck! https://github.com/socketio/socket.io/pull/2603

21:13 <ocdtrekkie> mnutt: At the fear of suggesting piling too much on one codebase, Davros probably is still the best file uploading UI we got.

21:13 <dwrensha> asheesh: I was just going to link to that

21:13 <mnutt> ocdtrekkie: in the future I would love for davros to provide the file list via powerbox

21:14 <ocdtrekkie> How close are we to that now? With where Collections and stuff is?

21:14 <mnutt> the one unfortunate thing about GammaGallery is that their readme says "licensed under MIT" and then goes on to add a bunch of restrictions. I opened an issue to see if they're relicense as apache or gplv3 or something, really anything other than MIT + incompatible restrictions would work

21:15 <ocdtrekkie> asheesh: Hah. Apparently, between when I first couldn't get this to work, and today, kentonv suggested they fix it. But it looks like they haven't done it. :/

21:16 <mnutt> I need to take a look at collections

21:18 <asheesh> Right now, the Powerbox can let you choose a grain, but it can't let you launch a custom chooser UI to pick an object _within_ a grain.

21:19 <asheesh> Additionally, the Powerbox doesn't let an app read data from the chosen grain's storage yet, "merely" let you open the grain as if you clicked on a link to it (open it in a new tab).

21:19 <asheesh> So I'd say we're 1 month away in terms of technical effort, plus any scheduling delay.

21:21 <asheesh> AFK a little bit.

21:25 <mnutt> asheesh: the workflow I'm imagining is that powerbox would let you choose a grain, and in doing so you'd be granting that grain's capabilities (or some subset thereof) to your current grain. I _think_ this would mean it could eventually be possible to expose Davros' webdav API to other grains. At that point, my thinking was that I would have some prebuilt webdav.js libraries available to other apps for choosing a file,

21:25 <mnutt> writing new files, etc.

21:30 <ocdtrekkie> I dunno if you'd need to select files inside the Davros grain, asheesh. You'd probably just say "This gallery should be the files from this Davros grain". But yeah, you would need access to grain storage.

21:31 <mnutt> I'd probably lean towards letting the grain expose an API rather than accessing the grain's files directly off of the disk

21:31 <mnutt> or I guess there may be implications around having dependent grains running and using up memory?

21:34 <mnutt> my local davros is currently using about 35MB. could be better, but it's not too terrible

21:34 <asheesh> I think you're right that RPC to the grain via something like HTTP API support is great if possible.

21:35 <asheesh> A thing I'm concerned about is apps that are written to expect files on disk, but maybe we just plan to support them "later" (and then hope that we never need to).

21:37 <mnutt> oh, so you'd actually be able to somehow mount another grain's storage inside your grain? that could be interesting

21:37 <asheesh> Yeah, but that's vaporware dreamy-asheesh-land stuff with no particular plan as to how it'd work.

21:37 <mnutt> or, you could just run owncloudcmd inside your grain :)

21:38 <mnutt> that would double up on the file storage though

21:40 <asheesh> Sandstorm doesn't currently hard-require root so we can't "just" mount --bind, I think

21:40 <asheesh> We could play games with mount namespaces though, maybe, since I do know we do that... hmm maybe it's easier than I think? But I imagine RPC between apps is something Kenton will be happier with anyway.

21:42 <isd> Don't know how the fuse driver's security track record is?

21:42 <asheesh> Luckily we don't use FUSE for running grains, but only for the spk dev filesystem stuff.

21:42 <ocdtrekkie> asheesh: Did you see the tag about Wekan and Meteor 1.4?

21:42 <asheesh> I did briefly, yeah.

21:43 <mnutt> is sandstorm shell planning to move to meteor 1.4?

21:43 <asheesh> Yes, though ETA unknown, 0-6 months. zarvox did some prep work this week for it.

21:44 <asheesh> The future of meteor-spk is interesting, as is the future of Meteor, just in different ways.

21:44 <isd> asheesh: I guess what I was saying was more, how bad of an idea would it be to let grains mount fuse filesystems?

21:45 <isd> If you did that, you could get the mount feature without much intervention of sandstorm itself; maybe a capnp protocol for fs access, but then you can just have a fuse fs that talks to that protocol

21:45 <isd> but it's something where I'd want to stare pretty hard at fuse's security track record

21:46 <ocdtrekkie> Anyone know how much space updating Ubuntu 14.04 -> 14.04.1 will take up?

21:46 <mnutt> fuse doesn't require root, right?

21:46 <isd> mnutt: correct

21:47 <isd> /dev/fuse needs to exist, and you need to own the mount point I believe

21:47 <mnutt> with this hypothetical davros/powerbox integration you could use the fuse webdav driver

21:48 <isd> I haven't actually checked, but my guess is sandstorm doesn't expose /dev/fuse, as it (sensibly) tends to take a whitelisting approach

21:48 <isd> but it would ease a lot of things to be able to make stuff look like filesystems.

21:49 <isd> It also does some weird stuff with root's ability to interact with the mountpoint, but namespaces should make that moot.

21:51 <asheesh> Yeah, it doesn't expose /dev/fuse, but you could imagine proxying requests involving /dev/fuse to Sandstorm first for it to be the one to be using FUSE.

21:51 <mnutt> on a totally different topic, a while back there was some discussion about sandstorm analytics. are there any thoughts on exposing anonymized app usage data (total installed / monthly uniques, or something) to either app creators, or possibly just everyone?

21:52 <mnutt> I don't have any pressing need for the data, it would just be interesting

21:52 <isd> asheesh: that gets really weird, because sandstorm would have to be running in the same fs namespace for the grain to actually see it.

21:52 <mnutt> or even on the same node

21:53 <asheesh> Could it pass an FD for FUSE into the grain somehow?

21:53 <asheesh> Or /dev/fuse is a socket, not a mknod'd thing, and things in the grain aren't aware Sandstorm is proxying the requests

21:53 <asheesh> ocdtrekkie: I would estimate 200MB extra space.

21:53 <asheesh> (most of which gets reclaimed when you run: 'sudo apt-get clean' afterward)

21:54 <ocdtrekkie> Okay. I have 3 GB of space on that VM. Is there any reason I should be hesitant to do it? (For that matter, is there any reason I should do it?)

21:55 <ocdtrekkie> mnutt: How much of that is Sandstorm already collecting if people opt into that on their server, I guess? Then how much does the team want to share with the class?

21:55 <isd> Probably would have to look at the implementation of libfuse; if it uses ioctls we're probably screwed.

21:56 <isd> I'm assuming ioctl isn't on the seccomp whitelist...

22:00 <isd> https://github.com/libfuse/libfuse#warning-unresolved-security-issue

22:01 <isd> Could also LD_PRELOAD open and friends :P

22:02 <isd> Which might not even require changes to sandstorm?

22:04 <asheesh> Yeah; I don't think we make liberal enough use of LD_PRELOAD, honestly, but I might be crazy. Plus it's a weekend so don't trust me to be make professional judgments today, maybe.

22:05 <isd> I mean, I don't think there's anything that prevents grains from using it now?

22:08 <isd> It falls over with stuff like go that doesn't link against libc. but pobably a solid strategy in many cases.

22:08 <asheesh> Yeah, agreed that nothing stops grains from using it now.

22:08 <asheesh> I must AFK a little bit again!

22:10 <isd> an LD_PRELOAD library that let you spoof the filesystem would be very useful in general.

22:27 <isd> I give it fair ods the plan9 community has built something similar.

22:27 <isd> *odds

23:16 <TC01> So, my sandstorm app that I was discussing the other day works, but vagrant-spk dev is failing attempting to upload the file list with the following output: https://paste.fedoraproject.org/398376/99204991/; anyone have any ideas?

23:16 <TC01> I should note here that my vagrant-spk setup is somewhat... nonstandard. I followed https://github.com/sandstorm-io/vagrant-spk/blob/master/HOWTO-libvirt.md to set up libvirt and also my vagrant image is Fedora, not Debian