imslavko has quit [Quit: Connection closed for inactivity]
joshbuddy has quit [Quit: joshbuddy]
joshbuddy has joined #sandstorm
torrorist has quit [Read error: Connection reset by peer]
paroneayea has quit [Read error: Connection reset by peer]
paroneayea has joined #sandstorm
natea has quit [Quit: natea]
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
elee has quit [Ping timeout: 265 seconds]
fonfon has joined #sandstorm
fonfon has quit [Remote host closed the connection]
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
jadewang has quit [Remote host closed the connection]
gopar has quit [Remote host closed the connection]
mort___ has joined #sandstorm
mort___ has quit [Quit: Leaving.]
prosodyContext has joined #sandstorm
mort___ has joined #sandstorm
joshbuddy has quit [Quit: joshbuddy]
erikoeurch has joined #sandstorm
mort___1 has joined #sandstorm
mort___2 has joined #sandstorm
mort___ has quit [Ping timeout: 256 seconds]
mort___1 has quit [Ping timeout: 255 seconds]
kenton has joined #sandstorm
kentonv has quit [Ping timeout: 250 seconds]
landspite has quit [Quit: Leaving.]
landspite has joined #sandstorm
pixelport has joined #sandstorm
mort___2 has left #sandstorm [#sandstorm]
<XgF>
dwrensha: for gj, and specifically 'multiple response' promises, you might want to look at Dart and their Stream<T> abstraction. It turns out it's applicable to all sorts of events
<XgF>
E.g. connection.listen().each((socket) { ... })
natea has joined #sandstorm
<dwrensha>
Stream<T> = Promise<(T, Stream<T>)>
<dwrensha>
I think you could construct something like that on top of gj
<XgF>
Hmm? Im not sure what you're trying to get at there
<XgF>
Stream doesn't normally contain promises
<dwrensha>
how do you use a stream? You kick it, and it gives you the head element and a the rest of the stream. Hence Promise<(T, Stream<T>)>
<XgF>
Quite often I .map or .reduce them also :)
landspite has quit [Quit: Leaving.]
<XgF>
It also saves building infinity promises
<dwrensha>
What happens when a stream hits an error?
<dwrensha>
Like, you've got a stream that's accept()ing incoming sockets, and accept() fails on one of them.
<dwrensha>
Does it throw an exception? who handles it?
<dwrensha>
The way it might work with promises is that .each() would take a TaskSet as an argument, which lets you specify what to do when an error is hit.
<XgF>
stream.onError(handler); if you do map or reduce, for example, by default errors just pass straight through
<dwrensha>
"pass through"? Does that mean "get ignored" or "propagate up"?
<XgF>
If you map a steam, you get a new steam which the error propagates to
<XgF>
If you do .each (i'd forgotten this bit) you get a future which completes on end of steam or exception
mort___ has joined #sandstorm
paroneayea has quit [Read error: Connection reset by peer]
paroneayea has joined #sandstorm
natea has quit [Quit: natea]
natea has joined #sandstorm
natea has quit [Client Quit]
erikoeurch has quit [Ping timeout: 264 seconds]
natea has joined #sandstorm
erikoeurch has joined #sandstorm
mort___ has quit [Quit: Leaving.]
heliostatic has joined #sandstorm
erikoeurch has quit [Quit: Leaving]
gopar has joined #sandstorm
pixelport has quit [Ping timeout: 252 seconds]
pixelport has joined #sandstorm
<eldios>
hey folks
<eldios>
seems that downgrading to the available 4.0.1 kernel on Linode fixed the hanging VM issues
<eldios>
now I just have to remember to put it back to latest when 4.0.5 will arrive :)
erikoeurch has joined #sandstorm
joshbuddy has joined #sandstorm
<ocdtrekkie>
Just looked in my browser cookies folder.
<ocdtrekkie>
Sandstorm leaves a LOT of random cookies in there. :P
jadewang has joined #sandstorm
heliostatic has quit [Quit: Be back later ...]
heliostatic has joined #sandstorm
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]
<paulproteus>
This would make a great Sandstorm app in my opinion.
<ocdtrekkie>
I may accept failure on trying to get X-Sandstorm-Username to work in this. My poor JavaScript talent is not getting me very far.
heliostatic has joined #sandstorm
heliostatic_ has joined #sandstorm
heliostatic has quit [Ping timeout: 250 seconds]
erikoeurch has quit [Ping timeout: 246 seconds]
pixelport has quit [Quit: Leaving]
heliostatic_ has quit [Quit: Be back later ...]
heliostatic_ has joined #sandstorm
bb010g has quit [Quit: Connection closed for inactivity]
<kenton>
paulproteus: interestingly, all sandstorm email apps already implement disposable email addresses due to the way SMTP support works right now
<kenton>
paulproteus: I don't think they currently do forwarding. The best way to implement a forwarding app would be using the raw cap'n proto interfaces. It would take probably like 10 lines of code, honestly.
heliostatic_ has quit [Ping timeout: 265 seconds]
asmyers has joined #sandstorm
amyers has quit [Ping timeout: 250 seconds]
heliostatic_ has joined #sandstorm
bb010g has joined #sandstorm
asmyers has quit [Ping timeout: 245 seconds]
<dwrensha>
oohh I should use niscu in ShareLatex
<XgF>
:< mongo
<dwrensha>
nevermind, I think that I already do. Just trying to figure out why the database gets so big so quickly
<jeffmendoza>
basic Q: how do you host a blog on sandstorm? with a standard url
<dwrensha>
jeffmendoza: there should be in-app instructions in Ghost, WordPress and Hacker CMS
<ocdtrekkie>
jeffmendoza: Currently, you set up a redirect to the public URL generated by the blog app. blog.jacobweisz.com is just a redirect to the public URL for my Ghost.
<jeffmendoza>
the public url being <hash>.mysandstormserver ?
<dwrensha>
I don't know if "redirect" is the right word. You use a CNAME record
<jeffmendoza>
can you setup an https cert for your public name?
<kenton>
jeffmendoza: currently any SSL is configured at nginx, so you'd have to make it work there, manually.
<jeffmendoza>
ah ok, thanks
<kenton>
but currently web hosting is entirely read-only, which means SSL is not as important as in other contexts
<kenton>
(but obviously, still nice to have)
<kenton>
s/web hosting/web publishing/
<maurer>
kenton: It's still important, even if the information you're serving doesn't need to be secure. Serving a site over a non-SSL connection can result in rewritten javascript to steal cookies etc.
<kenton>
maurer: with static content why would you have cookies? :)
<mcpherrin>
kenton: Javascript can use & set cookies
<maurer>
kenton: The site doesn't need to use the cookies, just the domian
<maurer>
*domain
<mcpherrin>
I guess you could make the cookies JS only, then they wouldn't get sent.
<kenton>
the web publishing apps we have generally aren't designed for hosting JS apps that store any data, just truly static content
<maurer>
kenton: It doesn't need ot be a js app to insert js into the page
<maurer>
*to
<kenton>
maurer: but if the page isn't a JS app and is static content then there's nothing to steal. The biggest threat is basically modifying the page content, which usually isn't interesting enough for someone to set up a MITM attack to do it.
<kenton>
to be clear, I am in favor of SSL everywhere (see sandstorm.io, blog.sandstorm.io, etc. which are served only via SSL)
<kenton>
but I'm saying, in this case, it's not as important as other cases
<kenton>
maurer: also you can only steal cookies that weren't marked SSL-only. But if you have an active MITM, you can do that pretty easily regardless.
<zarvox>
ocdtrekkie: you could have the backend read the headers, and render them into global variables in a <script> tag in the base html template, maybe?
heliostatic_ has quit [Quit: Be back later ...]
heliostatic_ has joined #sandstorm
<zarvox>
ocdtrekkie: just pass req.headers["x-sandstorm-username"] as a variable into the three places templates get rendered, methinks
<kenton>
zarvox: asheesh-bot (as executed by me) points out you said "just". :P
<ocdtrekkie>
Heh
<zarvox>
hahahah, my apologies!
heliostatic_ has quit [Ping timeout: 264 seconds]
<ocdtrekkie>
The amount of soup to wade through in these "modern" web apps kills me. In addition to JavaScript, I have to contend with Node and Express and Jade and Socket.io. I honestly have no idea where to shove what to pass stuff through this thing.
<ocdtrekkie>
kenton: That should be an actual IRC bot. :)
gopar has quit [Quit: Leaving]
<zarvox>
ocdtrekkie: mind if I pick your brain at some later point about what all you did to get scrumblr running under Sandstorm? There's the source changes, obviously, but there's also probably some host things like installing node/npm/system libs that you did that vagrant-spk might benefit from having useful defaults for.
gopar has joined #sandstorm
<ocdtrekkie>
zarvox: Absolutely.
<ocdtrekkie>
I think it was pretty straightforward though.
<ocdtrekkie>
I use the regular spk tool, so once it's running locally (npm install/update/etc.) spk init, the shell script for this one was two lines, and that's mostly it.
<ocdtrekkie>
jparyani fixed the redis config though, that might be useful.
<ocdtrekkie>
Which was apparently (I don't remember these things) mostly to tell Redis to use /var, and that'd be a good thing for vagrant-spk to be able to do.
paroneayea has quit [Read error: Connection reset by peer]
paroneayea has joined #sandstorm
<zarvox>
mmm, redis is a dependency I hadn't hit yet in my packaging adventures! thanks!
<XgF>
Redis is scary because memUsage > data
<kenton>
XgF: that's the common case on Sandstorm. :)
<XgF>
kenton: Right, but that's a rule for Redis
<kenton>
should fit right in
<XgF>
If you have 1GB of data in there, it'll use >1GB of RAM
<XgF>
Redis will refuse to start if the size of your database exceeds the amount of RAM it can allocate
<kenton>
luckily a Sandstorm grain usually has, like, 1kb of actual data.