
Cloudron: A platform for self-hosting web apps - nebulon
https://cloudron.io/blog/2016-08-24-introducing.html
======
api
This seems like a much more minimal version of what Sandstorm does.

Sandstorm is more interesting in many ways, but it's oddly high friction to
get going with it. I installed it, got its config page, and was excited to get
it running, but then I discovered that you can't just have normal password
auth. You _must_ authenticate using a third party service like Google or via
one of their 'enterprise' options like LDAP, etc. This seems really really
strange for a 'decentralization' oriented project, and I just didn't move
forward with it because... huh? I just wanted to log into the thing and use
it.

~~~
kentonv
Sandstorm founder here. Thanks for the feedback. This is a bit off-topic for
this thread (apologies to Cloudron), but I wanted to clarify that one of
Sandstorm's authentication options is "e-mail", i.e. authenticate using any
e-mail address. While technically e-mail is a "third-party service", it is
decentralized and ubiquitous.

There are two reasons we don't like plain username/passwords:

\- They are notoriously insecure. If you're running a server with passwords
you usually want dedicated staff to deal with account hijackings, which self-
hosted servers obviously won't have.

\- They are not global identities, i.e. someone else's Sandstorm server cannot
authenticate the same identity. So if you transfer an app to a different
Sandstorm server (something we aim to make easy), all the identities would
have to be replaced with new ones local to the new server, which will probably
confuse the app.

With that said, we have been thinking about other ways to solve these problems
and we might introduce a plain old username/password option in the future.

~~~
api
Thanks for the response!

I gave up pretty fast on the e-mail option since I had to set up a mail server
and it was painful... we use Google for e-mail and it could not use that, and
setting up anything else is a many-step time sink.

I did not want sandcats.io but to use this on a private (ZeroTier) intranet.
Even for your enterprise offering, which we might be willing to pay for, you
still don't have a clear and simple way to auth. For enterprise I have to set
up LDAP or other complicated nasty things.

My personal rule for UX:

Each step that must be performed to set something up cuts the adoption rate in
half. So if you have an audience of 1000 and 4 steps, 63 people will end up
trying your product.

That's not hard science, just a rule of thumb I use to impress upon myself and
my team how important UX and zero-config is. It does have some basis in logic.
Think of each step as a bit in an integer for 'cognitive load.' Each
additional bit increases cognitive load exponentially, not linearly, since the
_total_ setup involves the specification by the user of N bits of information.

~~~
ocdtrekkie
I'd highlight that there's multiple options here that require less steps, like
using Sandcats, or passwordless email login, but that you've specifically
decided none of those options are acceptable. So you're specifically looking
for the most complicated use case you can come up with, and then complaining
there's nothing simpler. ;)

I do like your rule, regarding people "trying your product", but I don't know
if it really applies to setting up a server, because setting up a server of
your own is probably the worst way to try something you aren't sure you want
to use.

I'd suggest that anyone looking to "try" Sandstorm should be looking at
Sandstorm Oasis, which is managed hosting you can try for free. (Along with
being an easy place to see "live demos" of any of the apps on it.) If you try
it on Oasis, and decide it fits your needs, you're much more likely to
implement the additional steps required to configure it how you want it on
your own hosting.

I don't think I'd ever personally put in the effort to set up something self-
hosted until I already had "tried it".

~~~
api
To me the whole value prop of Sandstorm is the idea that we can run our own
absolutely independent cloud server. External dependencies for auth or hosting
(e.g. relaying everything through sandcats.io) bring us to "well why not just
use Google?"

~~~
ocdtrekkie
And as much as Sandstorm helps, running a reasonably secure absolutely
independent server is going to take some manner of work. ;)

While there are definitely platforms that work with just a username and
password, they are arguably drastically less safe in that scenario.

~~~
api
The whole idea of Sandstorm is to drastically reduce that work.

~~~
ocdtrekkie
And it certainly does. I daresay you will not find a self-hosting platform
that requires less work to implement but is equally as secure.

------
ocdtrekkie
nebulon, I feel you buried the lead here. I came in here and was like
"Cloudron already offered self-hosting on AWS, what's this announcement/blog
for?"

You guys went open source! THAT'S AWESOME. But you didn't mention that until
the bottom of the blog. :( You should highlight that news better!

Congrats and welcome to the open source world! :D

~~~
nebulon
Thanks for the hint about messaging. I guess we haven't seen it as a huge PR
thing for us, as it is more like the natural thing, coming from an all open
source environment anyways. We just had no time/focus to do it till now and
until recently the code itself it was pretty useless as such for others. With
the AWS self-hosting only the first step is done to help people use it in
their own way.

~~~
ocdtrekkie
I think it's a big deal because most decentralization folks and self-hosters
wouldn't take a closer look at a platform that wasn't open source. So you get
a chance to get that second look when you push that news.

And things going open source usually does well on HN as a headline.

