
Sandstorm App Market - petethomas
https://github.com/sandstorm-io/sandstorm-app-market
======
kentonv
Eep, this is just a link to our github repo, where we've been hacking on for a
while. We were actually preparing for a launch next week, but we're not quite
there yet.

(Hope our actual launch isn't marked as a "dupe" of this... :) )

~~~
dang
I only just saw this. What we've done in the past is bury the premature post
until you're ready to launch your own work. I'll do that here, although it's a
little late, and we won't count it as a dupe.

~~~
kentonv
Thanks!

------
danr4
I'm extremely excited by the prospect of personal server management. I dream
of the day when "the cloud" will consisy of just a bunch of servers sitting in
everybody's houses - sort of like a safe - and we will be in physical control
over our digital assets.

This will happen one day, and I hope more will follow Sandstorm's path.

~~~
state
Wouldn't you rather it be in a data center somewhere? I mean, so long as you
could still own the data...

~~~
kentonv
Of course, if you're using Sandstorm, you can easily move between a home
server and a datacenter as your needs change. The most important thing is that
the app developers and the physical server host are different entities, so
choosing an app doesn't lock you into a particular host.

~~~
yarvin9
Privacy advocates may still envision a world where most people keep their
personal servers in data centers as a sort of snooper's Disneyland, because a
global adversary could just trawl the whole machine room and get everyone's
data.

Physically, this is true. But politically, a well-designed personal server
ecosystem is more robust than it looks against this attack.

The key is, as Kenton points out, server mobility. The server that's your
whole network identity has to be able to migrate easily, even automatically,
between hosts public and private.

One way to think about how mobility makes a personal server more private --
even against a global adversary -- is the epidemiological concept of "herd
immunity."

For any global network, the percentage of users who demand _absolute_ privacy
is small. It works better to host your machine in the cloud. But the costs and
pain points of closet hosting are acceptable for this specialty market.

What's not acceptable is a situation in which the pro-privacy users form a
small isolated network which can only talk to itself, losing on Metcalfe's
law. Instead they need to be externally indistinguishable from normal users.
Moreover, they need to be able to switch back and forth from absolute to
relative privacy -- cloaking and uncloaking, as it were.

Normal users care only about _relative_ privacy, ie, security against all non-
sovereign adversaries. Excellent relative privacy is available from an
ordinary data center. "Linode hacks" happen, but less and less often.

But actually, just as the privacy-conscious users can blend into the herd of
normal users, the normal users benefit from the small minority of privacy-
conscious users.

Any global adversary has to assume that anyone with something to hide has
probably hid it already. So cost-effectiveness concerns decrease the
adversary's motivation to search in data centers. Why would anyone with
anything to hide, not hide it at home? Home searches are much more difficult.

Moreover, most people computing at home probably have nothing at all to hide
-- they are just normal people who care about privacy. So as long as they
stick up for their digital rights, the global adversary remains politically
quite weak.

~~~
kentonv
Agree with all of that.

A related and somewhat more tangible point: Having the majority datacenter
users using the _same platform_ with the _same apps_ as the pro-privacy users
means that the pro-privacy users will have a much better selection of apps to
choose from. Whereas today, non-SaaS apps are rather neglected due to their
inability to reach a large userbase, but those non-SaaS apps are the only
things the privacy-critical users can use.

------
edward
There was a talk about Santstorm at Debconf. (258M)

[http://meetings-archive.debian.net/pub/debian-
meetings/2015/...](http://meetings-archive.debian.net/pub/debian-
meetings/2015/debconf15/Sandstormio_A_webnative_package_manager_with_many_lessons_from_Debian.webm)

------
jewbear48
The biggest issue with Sandstorm is there is no decent sharing options. You
can share by link but not to account. I would love to replace google apps with
this, but I need to be able to give people a folder view of all the stuff I've
shared with them.

~~~
kentonv
This is something we're actively working on! :) "Share by identity" (i.e. to a
Sandstorm user, or a Github user, or a Google account, or an email address,
rather than by secret link) is high on the todo list. "Folders" are something
that will be naturally enabled by the Powerbox, which allows apps to connect
to each other -- a "folder" could actually be a very simple app whose purpose
is to hold a set of capabilities to other grains, implicitly giving anyone who
access the folder access to the contents.

(FWIW, back when I was at Google I spent a couple years working on Google Docs
sharing, so I have a pretty good idea of what is needed here. Just have to
write code.)

------
neumino
I had a hard time before to understand their catch phrase/what they were
doing. Improving privacy and control is really what they provide, making the
Open Source web apps viable is more for marketing purposes. That somehow
doesn't resonate well with me (I had to go one of their meetup to get a better
picture of what they are doing).

That being said, they really do something cool if you spend some time looking
at it. They tackle security issues with a good approach IMO.

~~~
kentonv
Thanks for coming to the meetup.

Making it easier to run open source apps really is the reason I started this
project, not marketing.

(Everything I wrote in this blog post is actually what I think:
[https://blog.sandstorm.io/news/2014-07-21-open-source-web-
ap...](https://blog.sandstorm.io/news/2014-07-21-open-source-web-apps-require-
federated-hosting.html))

------
haberman
> In addition to improving privacy and control, this is the only way to make
> Open Source web apps viable.

What about client-side web apps? Like Chrome apps? I've been working on an
open-source web app with the intention of deploying it as a client-side Chrome
app that is capable of syncing to many popular services (Dropbox, Google
Drive, etc) for cloud storage.

~~~
kentonv
Hey Josh,

For apps that fit the model, a client-side approach can work well. There are a
lot of limitations, though, that make it not ideal for a lot of apps. An
incomplete list of issues:

\- Basically all existing apps with server-side code would need to be
rewritten to fit in this model. (Sandstorm can run arbitrary Linux binaries.)

\- A large class of apps fundamentally need to be running even when you aren't
present. E.g., a mail server.

\- Sharing with other users, or connecting to other app instances, is tricky
at best when there's no server to mediate.

\- Real-time collaboration requires much lower latency than you can get when
syncing through Dropbox and the like. You could maybe pull it off through
WebRTC but it's much easier to use a server.

\- Access control is really hard to enforce without an app-aware server. E.g.
if you want to give users permission to comment on your doc but not edit it,
how do you do that with dropbox permissions?

\- Limited sandboxing: Generally you can't e.g. prevent the app from secretly
phoning home to its developer, at least given the security model currently
provided by e.g. Chrome.

PS. offtopic but can you merge this PR? :D
[https://github.com/google/protobuf/pull/710](https://github.com/google/protobuf/pull/710)

~~~
haberman
Makes sense!

I am particularly interested whether your security model could support the
following: I'm working on an accounting app, and want to support letting the
app automatically pull transactions from the user's bank accounts, mint.com-
style. So the app needs to be able to log into the bank's websites as the
user, probably using a real web browser. But I (as the developer) don't want
to have access to the user's credentials or have the app capable of phoning
home to me.

I also want users to have confidence that they can use third-party
contributed, bank-specific plugins for pulling this data, but be guaranteed
that these plugins can't steal their data or their money. A slightly difficult
problem, given that once you have a bank login, you can probably use it to
move money around. But curious if you have an answer to this!

The tight security of the app model is compelling, given how sensitive my
users data would be.

> PS. offtopic but can you merge this PR? :D

I totally had a long-ish reply typed out but must have closed my browser
before I hit "submit" \-- d'oh! Sorry, will get to that now.

~~~
kentonv
Yes, absolutely, that sounds like a perfect fit for Sandstorm's security
model. We are still working on some of the details, but the user will be able
to ensure that the app can, say, talk to bankofamerica.com but not any other
web site. You could also have each "bank connector plugin" be in a separate
grain, so only that grain has outside access, and then a security-paranoid
user only needs to review the connector code to make sure it doesn't do
anything nasty, rather than reviewing the whole app. The core app would only
have permission to talk to the connectors.

Of course the next question is: will any user actually understand how to set
this up? I think with the powerbox UI, it will actually be quite reasonable.
It would look like this:

\- User installs the base app, which initially has no permission to talk to
the outside world.

\- User clicks "add an account", causing the app to make a powerbox request
for an object implementing "BankAccountConnector".

\- The user doesn't have any of those yet, so Sandstorm would guide the user
through finding a matching app on the app market, installing it, and setting
it up. It's not hard to imagine a reasonable UI here: You see a list of
matches like "Bank of America Connector", "Wells Fargo Connector", etc.

\- As part of installing an app, the user will be able to see who the author
is, look at reviews, and (if they are so inclined) click through to code.

\- Once installed, the connector app prompts for the user's bank credentials
and then makes a powerbox request for "access to bankofamerica.com" (or
whatever). Sandstorm asks the user if the app may access this site, and the
user confirms.

\- Everything now resolves and the user is returned to the original app, which
now is able to pull data from their bank account.

This is, of course, still very vaporware right now, but that's the vision, and
there honestly aren't many open questions about how it will work, just code to
write.

~~~
haberman
Cool -- that's a really compelling story! And I presume the two apps (the main
app and the connector app) can send messages to each other?

The only part of this that seems short of ideal to me is: I want the connector
to use a real web browser to talk to the bank's website, for several reasons,
but chief among them is that if the website asks the user something
unexpectedly (like a security question), or something doesn't work, it's easy
for the user to see what is going on. That is one aspect of the client-side
approach I liked: the browser running the accounting app is the same browser
being used to actually fetch the data. Do you have an answer for this?

~~~
kentonv
> And I presume the two apps (the main app and the connector app) can send
> messages to each other?

Yep. Through Cap'n Proto RPC -- or HTTP layered on top of Cap'n Proto RPC.

> I want the connector to use a real web browser to talk to the bank's website

Interesting. That does add complication, but it seems doable. Perhaps the
connector grain could act as a proxy, embedding the bank's UI in an iframe,
where the iframe src of course doesn't point directly to the bank but points
back to the connector grain in proxy mode.

FWIW, we definitely want grains to be able to embed each other's UIs in
iframes (with proper permissions), which might play a part in this.

~~~
haberman
> Interesting. That does add complication, but it seems doable. Perhaps the
> connector grain could act as a proxy, embedding the bank's UI in an iframe,
> where the iframe src of course doesn't point directly to the bank but points
> back to the connector grain in proxy mode.

You're saying MITM the user's HTTP connection? I can't imagine how that would
work with SSL?

This might be too tricky to actually be feasible, just dreaming here!
Hopefully it is useful to help you imagine cool scenarios and possible
requirements.

~~~
kentonv
> You're saying MITM the user's HTTP connection? I can't imagine how that
> would work with SSL?

The browser wouldn't think it's talking to bankofamerica.com. The browser
would think it's talking to your sandstorm server. The user is willingly
letting the grain MITM the connection so that the app can get their data out.

There would certainly be complications, though.

------
jerrac
After clicking around the demo and skimming most of the docs, I have a couple
questions.

First, I'm still unclear on how urls work. For example, can I host a multiple
wordpress blogs at multiple domains? Like jerrac.tld, foobar.tld, and
example.org?

What if I also want to have other apps on those domains?

Also, how do I view a wordpress instance as an anonymous user? I couldn't
figure it out.

Second, how do multiple users work? For example, a user that has editor perms
in wordpress and can create Lychee and Etherpad apps, but can't do anything
else.

Third, is it possible for me to install a customized version of an app? Like
if I commit the crime of hacking wordpress core, could I get that to install
on my Sandstorm instance?

Fourth, has anyone looked at adding Drupal 7 and 8 to the available apps?

~~~
kentonv
So, to start, note that Sandstorm is not primarily targeted at hosting web
sites. It's more of a replacement for Google Apps (especially Google Docs).
Some of the apps (such as Ghost and Wordpress) can host web sites as a
function of the app, but this is not really the main focus of the platform.
Most Sandstorm apps are intended to be accessed through the Sandstorm shell
interface.

> First, I'm still unclear on how urls work. For example, can I host a
> multiple wordpress blogs at multiple domains? Like jerrac.tld, foobar.tld,
> and example.org?

Yes, you can create multiple Wordpress instances and connect them to different
domains. Note that publishing content to domains is something that only the
Wordpress, Ghost, and Hacker CMS apps do currently.

Most apps are designed to be accessed embedded in the Sandstorm UI, where they
get free authentication, authorization, document management, sharing, etc.

> What if I also want to have other apps on those domains?

You can always set up nginx in front.

> Also, how do I view a wordpress instance as an anonymous user? I couldn't
> figure it out.

The dashboard contains instructions for publishing content to your domain.
(Though you can't actually do this under the demo -- you can only get a
randomly-generated domain.)

> Second, how do multiple users work? For example, a user that has editor
> perms in wordpress and can create Lychee and Etherpad apps, but can't do
> anything else.

You can invite users to your Sandstorm server. Once invited, a user can
install apps and create grains. Each user installs apps for themselves -- the
admin does not choose the apps for them. Different users on the same server
can actually have different versions of an app installed. (Of course, when
they have the same version installed, Sandstorm will de-dupe behind the
scenes.)

You can share grains you create with other users by clicking the "share"
button in the top bar. Some apps -- including Wordpress -- offer you the
ability to share different access levels here.

> Third, is it possible for me to install a customized version of an app? Like
> if I commit the crime of hacking wordpress core, could I get that to install
> on my Sandstorm instance?

Absolutely. All the tools for building packages are open source and you can
directly upload packages to your server without going through the app market.

> Fourth, has anyone looked at adding Drupal 7 and 8 to the available apps?

Not yet, but it'd be cool if someone did. :)

------
isawczuk
I love the idea. I see x86_64 limitation, are you planning to add support for
Raspberry Pi?

~~~
kentonv
While I think it would be pretty cool to be able to run on raspi, there is a
fundamental problem that this would mean developers need to ship "fat" app
packages compiled for multiple architectures. With good tooling this could be
relatively easy, but for the time being we've decided that our efforts are
better spent elsewhere.

Note that a lot of server-style apps actually don't perform so well on raspi.
People seem to like to write servers in interpreted languages that are slow
and ram-hungry, and server infrastructure tends not to target ARM (e.g.
MongoDB last I checked). Of course, this will all improve in time, so
eventually it will make a lot more sense to target this...

------
azeirah
Awesome, I was planning on packaging my sandstorm app for the new appstore
today anyway!
[https://github.com/Azeirah/brainstorm](https://github.com/Azeirah/brainstorm)

------
tacone
I like the initial apps selection :)

By the way, this is a model (click-install) employed by countless hosting
providers. From that point-of-view, I don't see a clear value proposition in
this project, but still wish you good luck!

~~~
mnutt
You can currently click-to-install Wordpress, Drupal, etc on these hosting
providers, but I think the real Sandstorm value is in the sandbox model. In
order for host-your-own webapps to take off there will need to be active
marketplaces, and any time you get enough activity there will be bad actors.
We currently rely on Wordpress being trustworthy, but Sandstorm gives us much
better controls to ensure it does what it says it will.

Sandstorm also gives a standard interface for writing apps, where you don't
have to worry about authentication or user management. And in the future I can
imagine apps exposing their capabilities to other apps in the same way your
mobile device can have multiple mail readers, browsers, etc.

~~~
tacone
Thank you, I missed that. So the value proposition lies in the sandboxing, and
being open source.

~~~
kentonv
It's also easier to use: Most "one-click installs" basically give you a VM
with the thing running with a default config, but you usually still need to
SSH in to maintain it, edit config files, etc. Sandstorm is intended to be
easy enough that a non-technical user can install and use apps.

------
spacelizard
I just installed Sandstorm yesterday and I like what I see so far -- hope I
get some time to submit some pull requests. It's looking like a great option
for smaller companies that want to stick to free (libre) software.

One feature that I think would be cool is if there was a way to associate a
custom subdomain with a grain rather than the auto-generated stuff like
"xh37vmw0h5276mj7h5eh.blah.company.com". Being able to host at
"docs.company.com" makes link sharing a lot nicer for everyone!

~~~
kentonv
Thanks for the feedback!

Generally when sharing you send a link like
"sandstorm.company.com/share/xh37vmw0h5276mj7h5eh" \-- the random hostname you
quote is actually an implementation detail that you weren't meant to see. :)

Once a user has opened a sharing link once, the grain will appear in their
"shared with me" list, so they can find it again by going to
sandstorm.company.com. We will soon support sharing by other mechanisms that
don't involve sending a secret link, too.

~~~
spacelizard
The use case I am thinking of now seems to be more appropriate for apps like
GitLab where sharing URLs from within the app might be useful, for example
sending someone a link to a file like this:

[https://d85snt1c8mqgrfxcd2o1.blah.company.com/gitlab/repo/bl...](https://d85snt1c8mqgrfxcd2o1.blah.company.com/gitlab/repo/blob/master/package.json)

Another issue with this is because of the navigation being done with frames,
those URLs are somewhat hidden from the user. I have some thoughts on this,
but they may be worth saving for the issue tracker as this appears to be an
issue with the GitLab port and not Sandstorm itself.

~~~
kentonv
Sandstorm provides an API to the app through which it can update the URL in
the address bar -- adding an arbitrary path after the grainId, which will then
be passed back to the app if the URL is re-opened. Lychee and MediaWiki use
this, for example. It sounds like Gitlab should too -- that would be a good
bug to file.

------
jedisct1
That was bound to happen :)

Congrats to the Sandstorm team for their awesome work. Looking forward to a
huge ecosystem with the market!

~~~
kentonv
Thanks for maintaining libsodium! We use it extensively. :)

(E.g. a Sandstorm app ID is actually a base-32 encoding of the ed25519 public
key with which the app package is signed.)

------
ricardobeat
Sorry for being lazy, but can someone explain how this is different from the
other 1-click app hosting companies?

~~~
kentonv
The short answer is that Sandstorm is easier to use (no technical skills
required to install and use each new app; no shells or config file editing),
radically secure, and open source (you can run Sandstorm on your own machine;
it's not just a service).

It's easiest to understand if you try the 60-second demo:
[https://demo.sandstorm.io](https://demo.sandstorm.io)

You can also read about the security:
[https://docs.sandstorm.io/en/latest/developing/security-
prac...](https://docs.sandstorm.io/en/latest/developing/security-practices/)

------
bliti
Wonderful project. Some stupid questions:

\- Will I be able to access the apps from outside the dashboard (regular url)?

\- Is there a paid support version for self hosting?

\- Any quick tutorial for contributors?

\- Where do I sign up for updates?

~~~
kentonv
> \- Will I be able to access the apps from outside the dashboard (regular
> url)?

Sometimes.

Technically, a Sandstorm app can publish content to a domain outside of the
shell (as Ghost, Wordpress, and Hacker CMS -- blogging apps -- do).

However, in general, this is not the way that Sandstorm is intended to be
used, and not a use case we intend to focus much effort on. Apps on Sandstorm
generally remove their own code for login, sharing, file management, user
management, etc., and instead integrate with Sandstorm's facilities for all
these things (apps written explicitly for Sandstorm never write all that code
in the first place!). This has a lot of huge advantages in terms of usability
and security when the app is running inside the shell, but it generally means
the app is no longer suitable for running outside the shell.

Also worth noting is that running "webscale" apps is explicitly not a goal of
ours. Lots of infrastructure targets the "I need to run 1 app on 1000
machines" SaaS use case, but we're aiming at the "I need to run 100 apps on
one machine (or a small number of machines)" personal/business-internal use
case.

> \- Is there a paid support version for self hosting?

We haven't officially reached that point yet... but if this is something
you're interested in, please drop us a line (sales@). :)

> \- Any quick tutorial for contributors?

[https://github.com/sandstorm-io/sandstorm/wiki/Get-
Involved](https://github.com/sandstorm-io/sandstorm/wiki/Get-Involved)
(possibly a bit stale)
[https://docs.sandstorm.io/](https://docs.sandstorm.io/) (pretty new!)

> \- Where do I sign up for updates?

There's a box to join our email list in the front page banner:

[https://sandstorm.io/](https://sandstorm.io/)

~~~
bliti
Thank you. The technical explanation was very helpful.

------
magicfractal
Please please do an ARM release for the raspberry pi :D

~~~
ocdtrekkie
There's another comment above where kentonv explains why they don't, and why
it would be difficult. But beyond that, I don't think a Raspberry Pi is a
great choice for this sort of application. If you really want something
similar, I think there are now x86_64-based micro-PCs that might work.

------
nutate
y'all are doing awesome work. can't wait for the official launch when it's
ready. but it's clearly pretty darn ready now. :)

~~~
kentonv
Thanks! But it's going to be _so_ much better next week... ;)

------
binaryhex
what are the advantages of using SAM over Amazon/Google cloud services ?

------
izx
[https://youtu.be/CJrVZCbKxsE](https://youtu.be/CJrVZCbKxsE)

you couldn't help but think of this also..

~~~
WaxProlix
dududududu

