kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
frigginglorious has quit [Quit: frigginglorious]
<abliss>
So, has anyone managed to successfully work with Yarn before? I'm having a really hard time.
<abliss>
my options seem to be (a) run 'yarn build', which takes like 20 minutes, each time I touch a js file (it seems to have no incremenality?)
<abliss>
or (b) use 'yarn start' which takes 20 minutes to start, but then tries to serve a fancy self-updating thingy. but its webserver doesn't seem to work very well at all.
<abliss>
I keep seeing my browser hang forever after the first load, seemingly because it refuses to open more than 8 connections to the server, and the yarn server seems to have 8 dangling ones that never close
<JacobWeisz[m]>
I really wish I had a handy way to search all Sandstorm app packages' source so I could like search for yarn and know if it's been used in an app.
<abliss>
i didn't mean yarn in sandstorm. i meant yarn at all.
<abliss>
yarn appears to be a tool for compiling static pages. so there'd be very little reason to use it in sandstorm.
<isd>
I believe yarn is an alternative to npm (compatible with the same repository format).
<isd>
I seem to remember at the time the big ideas were things like reproducibility and integrity checks. I think npm does some of those things now.
<abliss>
egad, what i was assuming was buggy behavior is probably due to it actually trying to serve a 37MB bundle of javascript
<JacobWeisz[m]>
That's a lot of JavaScript
<abliss>
indee
<abliss>
d
<abliss>
ok, random question. Suppose a Matrix grain is running and exposing an http api. in order to access that http api, we need a bearer token (or a username/password, but let's assume that doesn't work). but also suppose that a Riot app wants to talk to that Matrix grain through its http api. and Riot/Matrix already have plans for the Authorization header.
<abliss>
Would it make sense to have the sandstorm gateway accept an alternate X-Sandstorm-Authorization header, so that the server and its client can continue to use the Authorization header unimpeded?
<abliss>
i guess the more i think about it, the less this makes sense. We wouldn't want multiple users logging into a single Matrix grain, using their own passwords inside the Matrix admin database
<abliss>
woot,
<abliss>
i got a hacked-up riot to talk to a grain-hosted matrix backend!
<JacobWeisz[m]>
😲
<abliss>
next random thought... for porting apps which already support SAML login, would it make sense for sandstorm to expose SAML endpoints for its authed users?
<JacobWeisz[m]>
That's similar to Cloudron's approach, where they use LDAP as their app integration, basically.
<abliss>
ugh... the emacs capnp-mode doesn't do any indentation management??
xet7 has quit [Remote host closed the connection]
_whitelogger has joined #sandstorm
<isd>
Someone who uses emacs should fix that.
<isd>
Not sure I know enough about saml to judge.
<JacobWeisz[m]>
My understanding is LDAP is a lot simpler than SAML. Possibly less secure but in the sandbox that might not matter.
<isd>
Oh god, just expanding the acronym sends chills down my spine. "Security Assertion Markup Language"
<isd>
I hadn't actually previously looked up what it stood for.
<kentonv>
SAML is hopelessly overcomplicated and every implementation is slightly different in potentially incompatible ways.
<kentonv>
It could maybe make sense to build a SAML bridge that runs inside the app's own sandbox, and just reads the Sandstorm headers
<kentonv>
but I would think in most cases it's easier to patch the app itself to read those headers
<kentonv>
I don think LDAP is an answer here because LDAP doesn't interact via the browser... LDAP only gives you a way to check username/password pairs against a server
<kentonv>
so you can't say "please tell me who this user is already logged in an in their browser"
<isd>
Yeah, that's more or less what I expected to hear.
<isd>
I think a more compelling path is to write integration libraries for various frameworks. We already have one for meteor that makes this mostly transparent
<isd>
You could do the same for most misc. frameworks that have pluggable auth systems.