<asheesh>
mnutt_: If you're willing to read https://github.com/sandstorm-io/sandstorm/pull/1201 and let me know if it's the kind of thing you would like to see, or how I can improve it, or if it's a step backwards, or hardly a step forwards, I'd mega appreciate it.
<asheesh>
Contextualizing the grain URL & grain frame URL is something I've struggled to express in the past so I kind of hope I got it right once so I never have to again.
<asheesh>
And/or maybe it's so self-evident that I don't need to worry as much about it.
rustyrazorblade has quit [Read error: Connection reset by peer]
rustyrazorblade has joined #sandstorm
<sprin>
Seeing a strange change in permissions when packing my app. When build.sh is run, I see:
<sprin>
-rw-r----- 1 sandstorm sandstorm 1704 Nov 24 18:32 ssl-cert-snakeoil.key
<sprin>
then after packing and launching on a different sandstorm instance: -rw-r--r--. 1 1000 vagrant 1704 Nov 24 18:32 ssl-cert-snakeoil.key
<sprin>
the ssl-cert-snakeoil thing is a Postgres-ism, it's required for postgres to start up, regardless of whether SSL is configured
<zarvox>
uids/gids are not preserved when the SPK is packed or unpacked, and your apps files may be owned by a user that is not the one running inside the grain
<sprin>
I wouldn't be bothered by it since there's only one user in the grain anyway (correct?), but Postgres becomes unhappy :)
<sprin>
2015-11-25 00:36:46 GMT [14-1] FATAL: private key file "/etc/ssl/private/ssl-cert-snakeoil.key" has group or world access
<sprin>
2015-11-25 00:36:46 GMT [14-2] DETAIL: File must be owned by the database user or root, must have no write permission for "group", and must have no permissions for "other".
<zarvox>
I think we only allow one user in the grain at present
<sprin>
Would it work to change the permissions in launcher.sh?
<zarvox>
you can't modify anything under / at grain launch time, only /var
<sprin>
ah, right
<sprin>
I am trying to dance around it, but so far not getting anywhere.
<sprin>
Why does the file become world-readable after packing?
<zarvox>
I think the only permissions bit that we preserve is the executable bit on files.
<zarvox>
If you only have one user, than owner and world are equivalent, and 644/755 are the only two permission states that you care about having.
<sprin>
I definitely agree with that logic, but Postgres has other ideas
<zarvox>
Heh.
funwhilelost has quit [Ping timeout: 255 seconds]
<zarvox>
Would it help if I tried getting postgres up and running inside a sandstorm grain?
<sprin>
it looks as if there is an option to disable ssl: "ssl=false"
<sprin>
zarvox: Thanks for the offer, but it looks like setting "ssl=false" did the trick
<zarvox>
yay! I'm glad to hear you figured it out :)
<sprin>
So Postgres is working happily in a grain created from a package. Are there any other apps that use Postgres yet?
<zarvox>
Yours is quite possibly the first!
<sprin>
neat
joshbuddy has quit [Quit: joshbuddy]
joshbuddy has joined #sandstorm
bb010g has joined #sandstorm
isd has quit [Quit: Leaving.]
jadewang has quit [Remote host closed the connection]
kentonv has quit [Ping timeout: 272 seconds]
rustyrazorblade has quit [Quit: rustyrazorblade]
isd has joined #sandstorm
kentonv has joined #sandstorm
jacksingleton has quit [Ping timeout: 246 seconds]
<sprin>
I'm trying to add support for a client session id header, as discussed yesterday. I need a little help on the patch though, I can't get the header through.
<asheesh>
I personally do want (as a grain owner) to own the title that other people see.
<asheesh>
I am pretty seriously suddenly tired so I might ramble some.
<jacksingleton>
If we do go that direction, it would be nice for SandForms to be able to access the name that the owner has given the grain. We would show it as the title of the form when users fill it out
<asheesh>
In your case, fwiw, it seems to me you are OK with the name that SandForms sees to be the user's "petname" not necessarily the owner-created name.
<asheesh>
But this means that the "petname" would be exposed to the author of the app, which might be bad depending on the properties the pet name wants to provide.
<jacksingleton>
yeah I think it would make more sense to keep the owner-created name
<asheesh>
Interestingly I guess for your case, you could implement it in a way where the owner-created name flows from the owner's view into the other users' views.
<jacksingleton>
all non-owners (currently) are responders to us, and the owner will probably want to control the title that they see
<asheesh>
Like when the owner does a rename, this does an RPC into the grain, which then saves that in Meteor-land so it can reliably display it later.
<asheesh>
Is one possibility.
<asheesh>
FWIW I think in your case the recipients will never rename it, so I don't know that you care whose title gets shown, owner or recipient.
<jacksingleton>
yeah it's not a huge deal
<asheesh>
"Document-like apps, i.e. most centrally Etherpad, have shared mutable titles implemented by the app. There is a standard protocol to ask a grain “what's your title”, or for the grain to push out a title value which is cached" -- https://github.com/sandstorm-io/sandstorm/issues/1087
<asheesh>
This seems kpreid-approved capabilities-pure and also like it would suit your needs.
<asheesh>
jacksingleton: Would it suit your needs if a rename operation within the grain's UI would change the name people see in the Sandstorm top bar?
<asheesh>
So then the mutation occurs within the app UI, and gets pushed out to Sandstorm when it gets changed?
mnutt_ has joined #sandstorm
<asheesh>
Howdy mnutt_ , thanks again for your pull request feedback.
<jacksingleton>
asheesh: will have to read not sure exactly what you mean
<asheesh>
Having said that, jacksingleton, presumably if someone changes the grain title from within Sandstorm's UI rather than the app's UI, then you'd lose sync in my current proposal.
<jacksingleton>
oh I'd assumed that the app couldn't have the ability to change the title arbitrarily
<jacksingleton>
that would work well for us and would match Google Forms behavior
<jacksingleton>
(kind of)
<ocdtrekkie>
Stack Overflow reminds me why I should avoid pretty much all communites with downvote buttons.
<jacksingleton>
*downvotes that irc message ;)
<asheesh>
Also in theory the grain title is unbilled storage on Oasis.
<asheesh>
Arguably a good reason to make it either readable or writeable by the app but not both. But that's kinda weird.
isd has quit [Read error: Connection reset by peer]
<asheesh>
sprin: Your patch is interesting; I suggest turning it into a pull request and pinging @kentonv to get his attention.
<asheesh>
Even if you say "Not for merging, just for feedback" in the title.
<asheesh>
I am going to wander off for a while. jacksingleton , crazy as it may seem, #1087 may be your only hope, so comment there etc.
<jacksingleton>
see ya!
<asheesh>
Hey uh jacksingleton
<asheesh>
Do you want to submit an OSCON talk proposal about Hacker Slides/Sandstorm?
<asheesh>
Ooh, or (better) about SandForms?
<asheesh>
You can add other people as co-presenters down the road to help other people on the team get their own name more well known too.
<jacksingleton>
sorry I didn't comment earlier, but I did see it. looks awesome
<zarvox>
:D
<zarvox>
I figured you were probably super busy and didn't have the time to go through the build/test/release process, but I'm glad it's on your radar
<jacksingleton>
yeah it might be after thanksgiving by the time it's merged and published
<zarvox>
cool, thanks for the update :)
<jacksingleton>
thanks for the PR! its gonna make the app _so_ much more useful
<jacksingleton>
b
<zarvox>
I was actually super excited about writing it because 1) once upon a time Chadni wanted a copy of my slide deck, and I had to make a copy of the grain and share that with her
<zarvox>
and 2) because this was my first time using pycapnp, and it seems pretty reasonable and I feel empowered to write more with it in the future
<ocdtrekkie>
Once it's merged, I can post actual slides from my old Sandstorm talk.
<ocdtrekkie>
Rather than an Etherpad grain of the Markdown.
<ocdtrekkie>
:D
<zarvox>
:D
<zarvox>
What other features would you want out of Hacker Slides, if any?
<jacksingleton>
hmm there's a decent amount of bugs / small features on github. an accessible editor mode is next on my list
<jacksingleton>
new feature wise, the most exciting next step would be collaborative editing, possible with sharejs
<zarvox>
another thing that would be cool is split presenter view (current slide, notes, next slide preview)
<jacksingleton>
revealjs has that built in - but it might not be working in the currently published version due to incomplete sandstorm-files.list
<jacksingleton>
yeah just checked, that will start working with the next release. you press 's' while in present mode :)
<mnutt_>
awesome that hackerslides is getting web publishing, but I’m curious if it would be almost-as-good to enable a view-only share mode?
<mnutt_>
I suppose in one case you have a lot of sandstorm-provided security while in the other there is only a very thin layer provided by the app itself respecting permissions.
joshbuddy has quit [Quit: joshbuddy]
isd has joined #sandstorm
simonv3 has quit [Quit: Connection closed for inactivity]
<jacksingleton>
mnutt: hmm good point
<jacksingleton>
roles for sharing would definitely be useful, especially if we ever get to collaborative editing
joshbuddy has joined #sandstorm
<jacksingleton>
the publish feature is really nice because you don't really want to be in a Sandstorm iframe when presenting with Revealjs (because it wants fullscreen mode). although I suppose we could request fullscreen mode from sandstorm
joshbuddy has quit [Client Quit]
jadewang has joined #sandstorm
<sprin>
lol, the sandstorm buildbot is a cat named garply?
<asheesh>
Ya. It's a real cat, fwiw.
<sprin>
heh, with its own g+ page. and it's huge.
<sprin>
mnutt_: thanks for the eyes on the patch. Still not working as expected though.
<kentonv>
garply's not fat he's big furred
kentonv has quit [Quit: Leaving]
jadewang has quit [Remote host closed the connection]
jacksingleton has quit [Ping timeout: 240 seconds]
mnutt_ has quit [Quit: mnutt_]
joshbuddy has joined #sandstorm
isd has quit [Quit: Leaving.]
itscassa|away is now known as itscassa
fonfon has joined #sandstorm
joshbuddy has quit [Quit: joshbuddy]
asmyers has joined #sandstorm
fonfon has quit [Ping timeout: 272 seconds]
fonfon has joined #sandstorm
decipherstatic_ has quit [Remote host closed the connection]
fonfon_ has joined #sandstorm
fonfon has quit [Ping timeout: 255 seconds]
tobald has joined #sandstorm
simonv3 has joined #sandstorm
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]
amyers has joined #sandstorm
asmyers has quit [Ping timeout: 246 seconds]
tobald has quit [Ping timeout: 255 seconds]
tobald has joined #sandstorm
NOTevil has joined #sandstorm
tobald has quit [Quit: Ex-Chat]
mnutt__ has joined #sandstorm
gillisig has joined #sandstorm
amyers has quit [Remote host closed the connection]
amyers has joined #sandstorm
fonfon_ has quit [Ping timeout: 252 seconds]
kecolus has joined #sandstorm
fonfon has joined #sandstorm
dwrensha has quit [Quit: ChatZilla 0.9.92 [Firefox 42.0/20151029151421]]
bb010g has quit [Quit: Connection closed for inactivity]
fonfon has quit [Ping timeout: 252 seconds]
simonv3 has quit [Quit: Connection closed for inactivity]
mnutt__ has quit [Quit: mnutt__]
simonv3 has joined #sandstorm
mnutt__ has joined #sandstorm
jacksingleton has joined #sandstorm
<asheesh>
Howdy mnutt__
<asheesh>
I'm reading your comments on #1201 (path.md) and wanted to ask if you'd be willing to take a stab at suggesting alternative text. If not, that's fine, but a boy can dream.
<asheesh>
I agree with your remarks, fwiw.
funwhilelost has joined #sandstorm
<sprin>
Are there any docs explaining Sandstorm internals? I have a decent idea of the major pieces, but it would be nice to read more.
<asheesh>
In theory those are supposed to live here https://github.com/sandstorm-io/sandstorm/wiki but I've focused on documenting interfaces for building apps, not the internals of Sandstorm, so far.
<asheesh>
The most straightforward way is to make a bundle, then 'sudo sandstorm update' _within vagrant-spk_ to that bundle.
<sprin>
ah, understood
<sprin>
so my vagrant box will be updated to the sandstorm bundle I have built on my host machine
<asheesh>
Ya
<sprin>
cool
<zarvox>
Yeah, and then when you run "vagrant-spk dev" or "vagrant-spk pack" it'll add the sandstorm-http-bridge from that sandstorm bundle you made
<sprin>
right, thanks!
<asheesh>
This does limit some of the 'reproducibility' benefit of vagrant-spk but not 100% of it, and I think it's the most Zen-ful way of doing it for now.
<asheesh>
In the long run your patches will presumably get upstreamed.
<asheesh>
BTW (a) this is an interesting thing to watch as you get stuck on things; sorry about times where more docs could have helped you, and (b) wow am I impressed that you have the wherewithal to get this far.
<sprin>
Heh, thanks. I will try to keep a list of areas where docs would have helped. I'd be happy to contribute said docs as well, once my understanding is more complete.
<zarvox>
Strictly speaking, sandstorm-http-bridge changes have to be backwards-compatible with the WebSession interface, so while we don't achieve binary reproducibility, we do achieve functional reproducibility :)
<sprin>
Right. And I suppose as long as the bridge only adds new capabilities, rather than remove some, updates to the bridge/web session shouldn't break old SPKs.
funwhilelost has joined #sandstorm
<zarvox>
Indeed!
<zarvox>
So the source in your repo is forward-compatible with newer Sandstorm releases.
<zarvox>
Some day we may add breaking changes, but when we do, we'll do so in a different apiVersion
<zarvox>
(for instance, I suspect the Content-Security-Policy stuff will require an apiVersion bump, or we'd break too many existing apps)
<sprin>
neat, I can see my changes to the bridge now.
<asheesh>
Great, sprin!
<sprin>
so security policies, such as whitelisting response headers, should happen in the proxy, not the bridge, correct? since the bridge is "untrusted" as it lives in the grain?
amyers has quit [Ping timeout: 240 seconds]
<zarvox>
Correct.
<zarvox>
Proxy is the sanest place to implement that. supervisor is also capable of implementing platform policy for capnproto things like sturdyrefs and membrane requirements, but for more webby things like whitelisting response headers, the proxy is the right place to implement
<sprin>
great. My response whitelist changes seem to be coming together.
<sprin>
It appears node has ES6 enabled? That's convenient.
<zarvox>
Meteor 1.2 added support for it!
<zarvox>
and we bumped sandstorm to use Meteor 1.2 like five days ago :D