<dtzitz>
hey paulproteus heard about sandstorm on a podcast, playing with it now, nice thing is I am pretty comfortable with meteor and apparently they play well together
<paulproteus>
Yeah, totally dtzitz!
<dtzitz>
anyway, is there a way for me to get a sandstorm app on my laptop exposed to the rest of the world? I can't seem to figure it out
<paulproteus>
You'll need to configure port forwarding on your home wifi router, if you're behind one.
<paulproteus>
That's the main obstacle.
<paulproteus>
Have you done something like that before?
<dtzitz>
ahh, i am out at a hack night type thing
<dtzitz>
maybe I should just do what everyone else does and throw up a VPS
<paulproteus>
I think that is possibly true. One other thing you could do:
<paulproteus>
You could make your Meteor app into a SPK file via the tutorial, and then you could use oasis.sandstorm.io to host a public instance.
<paulproteus>
Then you wouldn't have to maintain a VPS.
<paulproteus>
And if you want to let others spin up their own instances, you could submit the app to https://apps.sandstorm.io/ == the Sandstorm App Market (free of cost)
<dtzitz>
true, let me see...
home has quit [Quit: Leaving]
<dtzitz>
paulproteus, maybe it exists currently but do you see people being able to charge for their apps? or that would be outside the scope of sandstorm app market?
<paulproteus>
We're hoping to add in-app purchases in the not-too-distant future as the first way to let people charge for things.
<paulproteus>
We definitely do want to be building somewhere where people can charge for things.
<paulproteus>
It's a matter of time, etc., is all.
<dtzitz>
so will sandstorm work in things like paas?
<paulproteus>
Sandstorm sort of _is_ a PaaS, so it's what you'd run on a VPS/Linux VM, and then you'd run your Sandstorm apps on it.
<paulproteus>
It's a security-hardened, single-sign-on PaaS which is focused on letting end users create instances of apps, rather than having an IT person have to run commands or configure complex things.
<dtzitz>
ahh word
<paulproteus>
That's what it is behind the scenes. In practice people end up using it like Google Apps For Your Domain, where non-techies can have a bunch of different types of collaborative documents or online things, and accounts are always shared between them.
hedgehog has quit [Ping timeout: 246 seconds]
jacksingleton has joined #sandstorm
mnutt has joined #sandstorm
<dtzitz>
paul, sorry got busy talking with some folks here I have to run, looking forward to playing with this a bit more at home where I own the network
<dtzitz>
thanks for the help
<paulproteus>
Have a great evening/day wherever you are!
<paulproteus>
No worries at all.
<dtzitz>
just happen to be in FL, it's really nice this time of year
eternaleye has quit [Ping timeout: 265 seconds]
dtzitz has quit [Ping timeout: 260 seconds]
mnutt has quit [Quit: mnutt]
simonv3 has quit [Quit: Connection closed for inactivity]
Triplefox has joined #sandstorm
jacksingleton has quit [Ping timeout: 240 seconds]
larjona has joined #sandstorm
soulshake has left #sandstorm [#sandstorm]
larjona_ has joined #sandstorm
larjona has quit [Ping timeout: 255 seconds]
jadewang has quit [Remote host closed the connection]
<luckre>
dwrensha: OK weird, my image was a small png
<luckre>
dwrensha: works on chrome, failed with firefox
<dwrensha>
interesting!
<dwrensha>
indeed, I see what you mean
<dwrensha>
weirdly, in Chrome the URL shows up as "blob:https%3A//..."
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 260 seconds]
mnutt_ has joined #sandstorm
jadewang has joined #sandstorm
dwrensha has quit [Remote host closed the connection]
dwrensha has joined #sandstorm
jadewang has quit [Ping timeout: 265 seconds]
Aric has quit [Quit: Connection closed for inactivity]
larjona has joined #sandstorm
tdfischer_ has joined #sandstorm
indiebio has joined #sandstorm
zarvox_ has joined #sandstorm
decipherstatic has joined #sandstorm
pod has quit [*.net *.split]
zarvox has quit [*.net *.split]
indiebio_ has quit [*.net *.split]
decipherstatic_ has quit [*.net *.split]
citruspi has quit [*.net *.split]
tdfischer has quit [*.net *.split]
maurer has quit [*.net *.split]
fkautz has quit [*.net *.split]
pod has joined #sandstorm
maurer has joined #sandstorm
<ckocagil>
has anyone written a passport.js strategy for sandstorm logins?
<ckocagil>
I'm currently writing one, maybe we should share it
home has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 244 seconds]
citruspi has joined #sandstorm
fkautz has joined #sandstorm
NOTevil has joined #sandstorm
bb010g has joined #sandstorm
mnutt_ has quit [Quit: mnutt_]
mnutt_ has joined #sandstorm
jadewang has joined #sandstorm
NOTevil has quit [Quit: Leaving]
jadewang has quit [Ping timeout: 250 seconds]
NOTevil has joined #sandstorm
home has quit [Ping timeout: 265 seconds]
NOTevil has quit [Quit: Leaving]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 244 seconds]
<paulproteus>
These qemu VMs take ~400 seconds to boot.
<paulproteus>
That apppears to dominate the time spent in installer-tests.
<paulproteus>
If I don't mind chewing up ~1.6GB of swap on misc, one thing I could do is leave the VMs perma-suspended, and "vagrant resume" (1 sec) them rather than "vagrant up" (400 sec) them when I need to run an installer-tests run.
simonv3 has joined #sandstorm
<paulproteus>
...I will go give misc 3GB of swap now.
<paulproteus>
Also seemingly the machine had a 2GB swapfile in /mnt/miscdb/swapfile that it wasn't using, but a 1 GB swapfile in /root/swap.img that it was using. I'll consolate onto /mnt/miscdb/swapfile
<paulproteus>
Doing a reboot to make sure my changes stick.
<paulproteus>
Also I totally want a crazy-fast canary or dev channel in which to consume the new UI.
<paulproteus>
win 48
<paulproteus>
...
mnutt_ has quit [Quit: mnutt_]
<ckocagil>
note to self: don't try to port apps written in dynamically typed languages unless you have to
eternaleye has joined #sandstorm
mnutt_ has joined #sandstorm
jadewang has quit []
home has joined #sandstorm
simonv3 has quit [Quit: Connection closed for inactivity]
<maurer>
paulproteus: <sarcasm>Just configure travis to post master to canary on successful build/tests pass
NwS has quit [Quit: See you in Isla de Muerte!]
isd has joined #sandstorm
<isd>
I'm *sure* this has been asked many times, but I'm not finding it anywhere: is there any support for the use case where I want an app to just act as a publicly accessible web-page and want a semi-rememberable name?
<kentonv>
isd: only specific apps support that, specifically Wordpress, Ghost, and HackerCMS (all of which are specifically for web site publishing)
jadewang has joined #sandstorm
<kentonv>
most apps rely heavily on Sandstorm to do things like access control which only really work if the app is inside sandstorm
<kentonv>
isd: what particular app did you want to use that way?
<isd>
I'm kindof in the market for something to host git repos, preferably with an issue tracker. The last time I tried gitlab on sandstorm it was pretty horrible in this regard.
<isd>
Looking at gogs now, but it looks like it doesn't deal with it beautifully either...
<paulproteus>
Yeah -- it'll have analogous structural issues.
<paulproteus>
We want shortname.yourdomain.com (or something like that) to work as a way to reach an app instance, but that's not implemented yet. We call that "Share by shortlink".
<dwrensha>
would it help if GitLab allowed you to set your repo to "public"?
<isd>
That's kinda what I was looking for. Is there an open issue for this that I can follow? I didn't find it when I looked.
<dwrensha>
(currently you need to log in to be able to see anything at all)
<paulproteus>
isd: I don't think so. I can go file that bug now, though.
<isd>
dwrensha: it might "help," but it still wouldn't be good enough to use.
<isd>
paulproteus: cool, thanks
<kentonv>
hold up here, this is a complicated question and we're proposing trivial solutions that probably don't work
<isd>
There should at least be an issue stating the problem. Doesn't necessarily have to have a solution in-hand
<kentonv>
isd: Presumably you are not satisfied by a redirect, right? You want the app to actually be served from the domain you map it to?
<isd>
kentonv: yeah, would be best if it could still look sensible even once actually there.
<kentonv>
sorry, what does "look sensible" mean?
<paulproteus>
URL remains human-readable?
<isd>
Still have a readable url. with a standard gitlab setup, each repo is just user/repo, issues are (soemthing like) user/repo/issues/...
isd has left #sandstorm [#sandstorm]
<kentonv>
ah, I see
isd has joined #sandstorm
<isd>
ack, closed the window by default.
<paulproteus>
np all we said was "ah, I see"
<isd>
but yes, remain readable, sorry for the lack of specificity
<kentonv>
isd: ok, now do you also want people to be able to log in on this domain without ever interacting with Sandstorm?
<kentonv>
or is it just the "public view"?
<paulproteus>
Another question - is it OK if they see some public view by default, and for logged-in-required operations, interact with the Sandstorm top bar to sign in?
<isd>
I think I'd be fine with interacting with sandstorm for log in, as long as once logged in the usage proceeds as normal.
<isd>
There's also the question of CLI access, but gogs seems to have a somewhat sensible solution to that.
<kentonv>
so, the thing is, basically you're looking for a standard web app hosting platform where users interact directly with the app
<kentonv>
and Sandstorm might support that someday
<isd>
pretty much.
<kentonv>
but it's not really our focus
<kentonv>
because we don't have much to contribute there that isn't already done by others
<paulproteus>
I am unsure of that kentonv fwiw but we can discuss that once we get to the end of the 1.0 roadmap anyway (-:
<paulproteus>
So basically I agree with you.
* XgF
points out the sandboxing features of Sandstorm as a contribution :P
<isd>
I'm not sure I think that's true. I think having the auth separated to some extent makes sense.
<XgF>
Though for Sandstorm a single user's repos would make sense
<isd>
and I can't think of anything else that makes setup work well, or isolates things correctly...
<XgF>
I *love* that with Sandstorm I need to do *no* server maintainance other than the occasional reboot (automatic packate updates configured for host distro, etc)
<isd>
exactly.
<XgF>
But TBH once Sandstorm has this public view type stuff working, taking say the gogs-sandstorm build and modifying it into multi-repo/multi-user mode shouldn't be much work I think
neynah has joined #sandstorm
<kentonv>
hmm
<XgF>
(Maybe even an app could specify that it supports multiple modes, which woudl change the permissions model, etc?)
<kentonv>
it's a departure from the model that Sandstorm is trying to build, and I'm worried that it's a distraction and will cause increasing tension with other things. But maybe there is a way to design it that gets the best of both worlds...
<XgF>
Even for the grain-per-thing model, nicely named public grains are useful
<kentonv>
like, the Sandstorm ideal is fine-grained grains, but I think mapping grains to domain names encourages course grainularity
<kentonv>
and cross-origin auth is complicated
<XgF>
I feel this is part of where something like nested grains comes in?
<kentonv>
but if the goal is just to have a nicer URL, would https://<my-sandstorm-host>/<name-i-choose> be reasonable? E.g. https://example.sandcats.io/gogs ?
<kentonv>
I guess in theory it would be neat to build a web site by "mounting" grains to various paths, but that'll take a while to implement.
<kentonv>
should the grains still be nested in iframes? Without that, you lose the sandboxing.
<kentonv>
the client-side sandboxing, that is
<XgF>
For this kind of thing I wouldn't even object to the normal iframe
<XgF>
(with the header and all)
<kentonv>
you mean the top bar?
<XgF>
yeah
<kentonv>
hmm
<XgF>
Interacting with an app (such as Gitlab or Gogs or such) is different from interacting with a "website"
<kentonv>
but if they are in iframes, where does the iframe point? Cross-domain iframes are often crippled by privacy rules, but if it's in-domain that means you need a wildcard on this domain as well.
<XgF>
Maybe the "horrible but practical" answer is... another layer of iframes?
<kentonv>
not sure that helps. If the top frame is domain x, then iframes on domain y will often be prevented from using cookies / local storage
<paulproteus>
Even for subdomains?
<kentonv>
subdomains are OK
<kentonv>
but they have to be subdomains of the top frame's domain
<kentonv>
and if we're talking about using a Sandstorm app to serve a site on some other domain...
<kentonv>
XgF: yup
<XgF>
Maybe we just need to say that "Setting up things on another domain Is Complicated"?
<kentonv>
let's imagine there's some way to work around the third-party cookie issue. I bet we could find a hack at least for authenticating the Sandstorm session, and then basically tell apps "don't use cookies / local storage" (which they mostly shouldn't anyway, since every session has a new origin).
<kentonv>
in that case I think it's at least intriguing to think about building a web site by mapping paths to grains
<XgF>
Do cookies/local storage work at least for the current browser session?
<kentonv>
IIRC they are just completely ignored when third-party cookies are disabled.
<isd>
I very much like the idea of mounting grains to paths.
<kentonv>
even if every git repo is a different grain? :)
<isd>
I'm not sure having each repo be a grain is great either. on gitlab.com I can view all of the issues I'm involved in on multiple repos in one place
<kentonv>
we do intend to create ways to accomplish that without requiring everything to be in one grain
<kentonv>
something like, you have a grain which is your personal "issue hub", and repo grains connect to it
<kentonv>
you could even then aggregate issues from separate gitlab instances on separate sandstorm servers, ideally
NOTevil has quit [Quit: Leaving]
bb010g has quit [Quit: Connection closed for inactivity]