Sandstorm App Market(github.com)
github.com
Sandstorm App Market
https://github.com/sandstorm-io/sandstorm-app-market
18 comments
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.
This will happen one day, and I hope more will follow Sandstorm's path.
See MaidSafe.[0]
It's what you describe. They're working on it, hopefully to be released some time this year. You upload something, it gets distributed to random nodes on the SAFE network. Minimum of 4 live copies of your data, and if any of them get taken down, another copy is immediately created on another machine. This completely eliminates the need for hosted servers for most types of apps. You can upload any files, including javascript, which means you can essentially run entire SPA and other applications using this network.
[0] http://maidsafe.net
It's what you describe. They're working on it, hopefully to be released some time this year. You upload something, it gets distributed to random nodes on the SAFE network. Minimum of 4 live copies of your data, and if any of them get taken down, another copy is immediately created on another machine. This completely eliminates the need for hosted servers for most types of apps. You can upload any files, including javascript, which means you can essentially run entire SPA and other applications using this network.
[0] http://maidsafe.net
Wouldn't you rather it be in a data center somewhere? I mean, so long as you could still own the data...
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.
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.
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.
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.
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.
It depends. I'm okay with being in a data center if it's impossible for the data center owners to access my data.
Not personally. I like being able to make my own hardware decisions. But I'm probably weird :)
I wouldn't. Much less if it's in the US.
And what happens when your house burns down? You must have at least two copies ... back to the cloud
"The cloud" could mean anything from a server in colo, to a desktop in a close friend's apartment, to riseup.net, to Amazon, to Google. Right now only a few of those are practical, and even fewer are scalable.
Backups are much more practical to encrypt and put in the cloud than the software you're actively using. Though hopefully the software we're actively using can be encrypted too.
Well, we're still running machines with - NX bit aside - Von Neumann architecture. Software is still data, just the sort of data that makes meaning for computer to execute. Don't see any issues with backing up the software.
I think I've heard of some approaches to conceal the actual algorithm from the computing unit (by obfuscation, or by distributing the actual calculation between multiple units), given that the software we're actively using doesn't do anything secret - and is likely to be a free and open source software, it doesn't make much sense to protect the executable code besides integrity checks.
I think I've heard of some approaches to conceal the actual algorithm from the computing unit (by obfuscation, or by distributing the actual calculation between multiple units), given that the software we're actively using doesn't do anything secret - and is likely to be a free and open source software, it doesn't make much sense to protect the executable code besides integrity checks.
The problem is that if our software on a cloud server has to use our encrypted private data, at bare minimum has to decrypt it, perform operations on it, and re-encrypt the revised data. Which can be resource-intensive.
If the server's capable to decrypt the data, unless you use a trusted HSM that keeps an audit trail, it generally doesn't make sense to encrypt in the first place. Especially with anything resource-intensive. When the server has everything to decrypt the data, the encryption only does the obfuscation, not any strong protection.
Otherwise, if we talk about - just for example - a receiving mail server (MDA) that has encrypted mailbox storage like [1], then it really depends on how much mail you receive. For a typical personal mailbox, where the steady rate is less than an email-per-minute (and usual email size is some kilobytes, not megabytes), encryption overhead is negligible. Such server would sleep most of time anyway.
[1]: https://grepular.com/Automatically_Encrypting_all_Incoming_E...
Otherwise, if we talk about - just for example - a receiving mail server (MDA) that has encrypted mailbox storage like [1], then it really depends on how much mail you receive. For a typical personal mailbox, where the steady rate is less than an email-per-minute (and usual email size is some kilobytes, not megabytes), encryption overhead is negligible. Such server would sleep most of time anyway.
[1]: https://grepular.com/Automatically_Encrypting_all_Incoming_E...
Agreed. I still long for the day where the use of "the cloud" will fade out though, not that it's major issue, but I do think that buzz words contribute to making the whole process more obscure to new comers...
Not sure if you're being sarcastic or... o_O
No. The cloud turned out to be convenient, but a terrible idea for privacy and control of our data. Private clouds are currently deployed by companies for regulatory compliance or paranoia. But in the future they could be installed by individuals.
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/...
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.
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.)
(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.)
In case you're interested, this is something we're working on. Consider subscribing to this issue:
https://github.com/sandstorm-io/sandstorm/issues/701
https://github.com/sandstorm-io/sandstorm/issues/701
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.
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.
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...)
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...)
> 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.
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.
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
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
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.
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.
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.
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.
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?
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?
> 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.
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.
> 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.
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.
> 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.
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.
That's a different use case. A client side web app is supposed to mimic the use case for native apps. While sandstorm seem to mimic the use case for Web Apps. If you are the only user I guess you could try to port it as a Chrome App, but Sandstorm seems to be aiming for something available online to be accessed by multiple users.
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?
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?
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. :)
> 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. :)
I love the idea. I see x86_64 limitation, are you planning to add support for Raspberry Pi?
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...
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...
Awesome, I was planning on packaging my sandstorm app for the new appstore today anyway! https://github.com/Azeirah/brainstorm
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!
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!
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.
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.
Of course, even trustworthy apps have security problems that can expose your whole server -- Wordpress being a common culprit. But apps like Wordpress and Etherpad on Sandstorm has been basically unaffected by upstream security bugs. See: https://docs.sandstorm.io/en/latest/developing/security-prac...
Thank you, I missed that. So the value proposition lies in the sandboxing, and being open source.
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.
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!
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!
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.
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.
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...
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.
https://d85snt1c8mqgrfxcd2o1.blah.company.com/gitlab/repo/bl...
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.
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.
That was bound to happen :)
Congrats to the Sandstorm team for their awesome work. Looking forward to a huge ecosystem with the market!
Congrats to the Sandstorm team for their awesome work. Looking forward to a huge ecosystem with the market!
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.)
(E.g. a Sandstorm app ID is actually a base-32 encoding of the ed25519 public key with which the app package is signed.)
Sorry for being lazy, but can someone explain how this is different from the other 1-click app hosting companies?
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
You can also read about the security: https://docs.sandstorm.io/en/latest/developing/security-prac...
It's easiest to understand if you try the 60-second demo: https://demo.sandstorm.io
You can also read about the security: https://docs.sandstorm.io/en/latest/developing/security-prac...
They have a nice collection of entirely open-source apps? https://sandstorm.io/apps/
A nice option to run your startup/project infrastructure (such as etherpad or project management) without having to trust third-party SaaS companies with your data. And avoid monthly subscriptions from 10 different companies.
A nice option to run your startup/project infrastructure (such as etherpad or project management) without having to trust third-party SaaS companies with your data. And avoid monthly subscriptions from 10 different companies.
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?
- 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?
> - 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 (possibly a bit stale) 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/
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 (possibly a bit stale) 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/
Thank you. The technical explanation was very helpful.
Please please do an ARM release for the raspberry pi :D
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.
Please don't add the burden of testing an additional architecture for app developers.
what are the advantages of using SAM over Amazon/Google cloud services ?
(Hope our actual launch isn't marked as a "dupe" of this... :) )