pouledodue has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jadewang has joined #sandstorm
jadewang has quit [Remote host closed the connection]
joshbuddy has joined #sandstorm
jadewang has joined #sandstorm
amyers has quit [Ping timeout: 265 seconds]
pouledodue has joined #sandstorm
<phildini>
oh hey. I just got an email from some guy named Kenton Varda about some thing names sandstorm. This seems cool. ;)
<kentonv>
I hope I didn't screw anything up in that email!
<phildini>
so far it looks good.
<phildini>
It would be nice if it spelled out how further communications from Sandstorm Inc. (or whatever) would be received, especially vis-a-vis downtime.
<phildini>
This is a totally minor nit, though.
<paulproteus>
(-: phildini
<phildini>
After reading the privacy policy and ToS, some notes. 1) It's very nice that you're trying to make them easy to read. Thanks. 2) It's implied that you _can_ look at the grains hosted on the Sandstorm hosting, and lays out when you might, but says nothing about notifying the user that you've done so.
<phildini>
Whatever your feelings about warrant canaries and the like, this was the one thing from the ToS that made me go "hmm."
<phildini>
I recognize that there are lots of reasons to _not_ want to let the user know, or where you legally can't, just expressing the thing that stood out.
jadewang has quit [Remote host closed the connection]
<kentonv>
Yes, you're right, I honestly hadn't thought of that but we should totally have a provision saying we'll notify you if we're legally permitted to do so
jadewang has joined #sandstorm
<kentonv>
as for warrant canaries, I am highly skeptical that they can work
<kentonv>
they seem like one of those hacks that a programmer who doesn't understand law would come up with
<phildini>
sure. I think they're more "protest against stupid govt" than "effective countermeasure against stupid govt" but ymmv.
<kentonv>
I am honestly not sure if "protest against stupid govt" is a good business move. >_>
mort___ has quit [Ping timeout: 246 seconds]
<maurer>
I'd argue that if you need something similar to a warrant canary for protection of your stuff, perhaps you should run your own sandstorm instance
<maurer>
I obviously don't speak for sandstorm, since I don't work for them though
pouledodue has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jadewang has quit [Remote host closed the connection]
pouledodue has joined #sandstorm
<erikoeurch>
the content of grains could be encrypted though, right, if an app supports it?
<paulproteus>
erikoeurch: Ya, tis true.
<paulproteus>
You do typically end up having to trust the JS that Sandstorm sends you, and have to store the key somewhere.
<erikoeurch>
paulproteus, but all of that is fairly easy to inspect, right?
<kentonv>
erikoeurch: We plan to encrypt eventually, but keep in mind that the decryption key necessarily has to be present on the server when the app is running.
<kentonv>
there's really no way for the user to know for sure that the server is not saving a copy of said key
<kentonv>
I think paulproteus is referring to the idea where you don't even trust the app servers, and instead use end-to-end encryption from Javascript. Most apps won't be designed that way, though.
<maurer>
kentonv: even with end-to-end js based encryption, you still have the issue of the server shipping malicious js. I know some people have discussed "js pinning" for sensitive apps, but I don't think anything has really materialized
<kentonv>
maurer: Yes. I think you'd want to handle decrypted data in a browser extension (or similar) rather than in JS served from the app.
jeffmendoza has joined #sandstorm
<erikoeurch>
kentonv, right, see what you mean. Well, then there may not even be much of a point in encrypting the data at all? Except for protecting from leaks / hacks
<kentonv>
erikoeurch: Protection against passive leaks, which are in practice much easier than active leaks. For instance, if someone breaks into the data center and steals a hard drive.
<kentonv>
or a rogue employee (if we ever get big enough to have rogue employees) who exploits prod access to dump the master storage.
<erikoeurch>
fair enough!
<erikoeurch>
so every grain would then have its own encryption key?
<kentonv>
yep
<erikoeurch>
great, really like these grain units :)
<kentonv>
:)
<XgF>
kentonv: One of our formerly-programmer lawyers says that engineers are the worst for 3/4ths understanding the law and then getting the remaining 1/4th completely wrong
<XgF>
(Because in general engineers and programmers have most of the skills necessary, but none of the knowledge/expertise to understand the intricacies properly)
<kentonv>
XgF: Indeed. I think the problem is that engineers want to see law as code and the courts as a computer. They don't want to believe that human judges use, you know, human judgment.
<kentonv>
or at least, one big part of the problem
<kentonv>
so then they come up with "hacks" based on literal, pedantic interpretation of the law, and judges are like "um, no"
<XgF>
kentonv: That's certainly half of it
<erikoeurch>
If I'd like to create let's say a Mailpile grain on Oasis in order to let a family member use it, would that be doable in a good way without them having a Sandstorm Oasis account? I would want to give away ownership of the grain so only they can authenticate and use it.
<kentonv>
erikoeurch: There's currently no way to do that without still having access yourself.
<erikoeurch>
will it be possible later on?
<kentonv>
Hmm, not sure. I don't think it easily fits into the model. And putting on my business hat, I would prefer if your family member paid for their own account. :)
<kentonv>
but I'll think about it
<erikoeurch>
kentonv, I realize it's not a straight-forward thing, and I also think it'd be easier if they actually got a Sandstorm account, just thinking that the older family members would not like to go through the process of having to get an account, dealing with payments etc
<erikoeurch>
On second thought, giving away ownership to grains would be a bit risky. The creator (whose resource quota is being used) must still have the rights to delete the grain, so the new owner can't be sure the grain will still exist for any certain period of time...
<kentonv>
yeah...
<erikoeurch>
Unless some kind of complicated "sub-letting" agreement with sub-quotas etc were set up, but that would be a lot of trouble for little benefit (especially for Sandstorm the business :) )
<zarvox>
or ownership transfer
<zarvox>
For some reason I now always think of things in terms of Rust's ownership/borrowing mechanics :P
<erikoeurch>
but if the complete ownership was transferred, the original creator must still be responsible for the resource usage, right?
<erikoeurch>
since the new owner could be a random person with no agreement with Sandstorm
<kentonv>
I think when we implement ownership transfer, the recipient will become responsible for the storage -- and won't be able to accept if they don't have quota
<zarvox>
I guess you could only transfer grains to an invited user
<erikoeurch>
So a Sandstorm account + subscription seems necessary
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 264 seconds]
<augustl>
hey again folks. I was asking about something yesterday but the conversation derailed so I'll try again :)
<augustl>
I want SSL and I have a cert for *.augustl.com, so I want my WILDCARD_HOST to be *-sandstorm.augustl.com
<augustl>
but does DNS have support for wildcars, so that a dns query to e.g. asdf-sandstorm.augustl.com will resolve to my servers IP?
<dwrensha>
augustl: you can set up a wildcard DNS entry for *.augustl.com
<augustl>
ah, why didn't I think of that :)
<augustl>
does DNS have presedence so I can have somethingelse.augustl.com pointing to another server, and have *.augustl.com point to my sandstorm server?
<kentonv>
yes, that works
<kentonv>
FWIW, DNS itself doesn't actually have any concept of wildcards -- it's the server that implements them.
<maurer>
Just to check, rpc.capnp is still the definitive documentation on the capnp protocol, yes?
<kentonv>
so technically the answer is "depends on your server"
<augustl>
nice :) So I can't have multiple sandstorm instances on say *-sandstorm.augustl.com and *-sandstorm2.augustl.com, but that's OK for me ;)
<augustl>
kentonv: ah, that's interesting, I'll look up the docs for my DNS provider then
<kentonv>
augustl: you can have multiple sandstorm servers if they're both behind the same nginx. :) (We actually do that for alpha and demo.
<kentonv>
)
<kentonv>
maurer: yep
jadewang has joined #sandstorm
<augustl>
should BASE_URL be set to my front-end SSL URL?
<kentonv>
augustl: yes, it should be the URL the user sees in the browser.
<augustl>
kentonv: I see, thanks
bb010g has joined #sandstorm
mcpherrin has quit [Ping timeout: 264 seconds]
<warren>
paulproteus: ping
<paulproteus>
pong
<paulproteus>
I plan to ping the MatterMost people today! I can do so right now. (cc: kentonv jadewang )
<paulproteus>
Let me do that right now, brb. : P
<warren>
oh, had a non-mattermost question
<paulproteus>
Ah OK
<paulproteus>
But anyway I'm digging up all the context needed to do that; feel free to ask me anything else.
<phildini>
zarvox: your comment on that doc is so long, I can't see all of it.
<phildini>
;P
<zarvox>
oh dear. Hrm.
<zarvox>
phildini: I was attempting to note that CSS is a global namespace, and that comes with its challenges and fragility, and http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html paints a pretty compelling argument for an alternative approach, depending on how critical we find theming.
<zarvox>
You also get much more explicit style inheritance if you represent your styles as JS, and can do dead code detection when a variable is no longer used, and so on
<phildini>
when someone suggest putting their CSS in JS through something react-like, I basically don't believe they ever intend to have more than 3 people working on the code.
<zarvox>
that's kinda funny, because at Facebook that's how they support a lot of people working on the code!
<paulproteus>
zarvox: That's fascinating.
<phildini>
hmm... my understanding of Facebook is that not many people work on any one part of the code, and that the subteams are pretty tight. (two-pizza teams, etc).
<phildini>
I will fully admit to having an incomplete or outdated knowledge of facebook.
<zarvox>
Isn't that how most development should be? Encapsulated so that most people don't have to worry about most of the code?
<zarvox>
I'm tempted to toy with switching from Blaze templates to React, if only for the ability to have all the relevant code for a component in the same file.
<phildini>
you're accepting an abstraction layer when you do this, however. yes, less/sass do some compilation, but I'd argue javascript -> css has a lot more things that could go wrong that sass -> css. If your entire team buys into that abstraction, great! I'm not convinced by it yet.
<zarvox>
Fair enough. I'll point out that javascript + templates + CSS are potentially moving parts than just JS (or even JS + JSX), and that I suspect none of us are experts at Less or Sass yet, but we all are functional at JS.
<zarvox>
I suppose the proper way to figure it out would be to do an experiment and see if we hit issues with the approach, or if it works well for us!
<paulproteus>
I'm at least +0 on us doing further unusual web dev things that might turn out to be great.
<dwrensha>
yay, I have received a purple Sandstorm shirt!
<zarvox>
:D
<phildini>
sure. in your approach, would you be doing server-side or client-side rendering?
<zarvox>
We're already full-on Meteor, so it's all client-side already.
<zarvox>
The templates get passed to Meteor's template engine, which renders the DOM client-side.
<zarvox>
With React, you get the bonus of also having renderToString for unit tests!
<phildini>
Does the sandstorm security model (I guess I really mean the sandstorm shell) even work without JS? or is progressive enhancement not a concern?
<paulproteus>
No progressive enhancement, semi-sadly.
<zarvox>
It does not work at all without JS.
<paulproteus>
All JS all the time.
mcpherrin has joined #sandstorm
<zarvox>
Well, the security, strictly-speaking, is done with origin sandboxing, so that works regardless of whether JS is on or not. But actually using the interface is a JS-only endeavor.
<phildini>
then a large part of my concerns probably don't matter. :) If the tech doesn't work in a progressive-enhancement way then there's no real downside to doing everything client-side.
<phildini>
(Maybe potential future designers having to learn js if they want to make the changes themselves? idk)
<zarvox>
That ship has very much sailed at this point, though.
<phildini>
all of those are semi-surmountable with (you guessed it) more javascript, but for my money react is a little more interesting when it's rendered server-side and sent to the user.
<zarvox>
For our frontend, anyway.
<phildini>
sure. slightly sad as someone who always wants to fight for all users of the web, but sure. it probably makes sense for sandstorm.
<zarvox>
I am also a fan of React's serverside rendering. One of the most impressive demos at ReactJSconf was the example app that works with or without JS turned on.
<dwrensha>
hm, I just noticed that our UiView webkeys have twice as much entropy as our frontendRef webkeys. jparyani, is there any particular reason for this?
<jparyani>
hmm no reason that I know of
<dwrensha>
Random.secret() vs Random.id(22)
<jparyani>
ah random.id is so that the ids are actually ascii
<jparyani>
wait actually so is Random.secret
<jparyani>
I'm not sure then. I think the idea was that users may actually see these keys in some scenarios, and 128 bits of entropy was good enough
pouledodue has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<jparyani>
yep
<jparyani>
and it tries to leave out confusing characters like 1, l, and I
achernya has joined #sandstorm
mcpherrin has quit [Ping timeout: 250 seconds]
pouledodue has joined #sandstorm
<paulproteus>
Howdy pouledodue
<pouledodue>
hi
<erikoeurch>
zarvox: but with React, would you get rid of templates in terms of moving parts? Isn't it just a matter of where you put the html? I haven't used React, just seen a few sample code snippets...
<zarvox>
with React, usually you try to make your components' render() a pure function of their props, but you'd keep the styles in the same component, and then it's easy to see which fields they reference, prune unused styles, etc.
<erikoeurch>
zarvox, seems handy, especially when it comes to styles, which I feel is the only real pain in developing with Meteor (not that Meteor makes it any worse than plain web development though)