For massive take-off, Sandstorm is almost-there with making everyone's online world de-centralized.
It's solved half of the problem beautifully -- it's very easy, once setup, to launch any new app on your server.
The other half of the problem is moving of server/data. Right now, either you use their self hosted instance of sandstorm, or setup your own server. There's the hassle of keeping track of data/server. There's pseudo-centralization happening here, given the difficulty of changing compute or storage by a layperson.
However, if sandstorm had built in federated storage (either based on bittorrent filesystem or any other p2p storage), then I no longer worry about losing my data. I simply move my domain to a new "server-provider" or use the main project's own service, and then at a later date can spin up my own compute, or use another provider, and point them to my data on the p2p/federated storage.
FWIW, it's straightforward to see how this could be accomplished with Sandstorm's model, since user data is very clearly divided into grains (app instances / documents) with clear owners, and these grains can easily be transferred between servers. Today, you can click "download backup" to get a zip, then upload it to some other server, and end up with exactly the same grain reproduced there. We plan to streamline this further, to allow mass transfers and synchronizing grains between servers. It's a major goal for us that it should be trivial to move between hosts, so that you're never stuck with a host that you don't like.
Good to know. Just to re-iterate one point, the ideal is that the server does not have a hold over the data (by say withholding download of backup data), or that the data is held tied to a certain server.
Server and data (encrypted) should just be commodities, and the domain DNS is what should describe ownership. That's why I would like the focus to be on federation than easy import/export.
Realistically, if you want to run code on the server, the server needs some control over the data. There are some distributed systems lately that really only distribute storage while all computation happens client-side. That doesn't work well if you want real-time collaboration (the latency is too high) or multi-user permission constraints. Not to mention, it requires rewriting the world. So, I'm skeptical of those approaches. I'd rather make it easy to get your data out when you need/want to.
But it's certainly an opinion that is open to debate.
> To ensure low latency, I'm OK with the protocol allowing a server to cache and render recent data, while a background service syncs to the de-centralized store.
This would be a help for the UI from the protocol, but the ideal IMO should be something that normal SaaS companies/products hold you on for -- they have your data hostage.
I understand that for sandstorm above many not be possible as you'd have to re-write a lot, and this feature does not hold sufficient priority for the relevant code re-write to happen.
That's too bad though -- I was expecting this need of mine to be provided by the project. Still I wish you the best of luck as you're head and shoulders the better option above any of the current SaaS apps for a personal clouds.
Understood. The exciting thing about sandstorm to me was (and is) that it promised a lay-person easy server and cloud data management. To make this viable, the user would only need to pay for compute and storage.
However, compute and storage providers must not be able to hold user data hostage. Yes, the ideal is hard to acheive, but, for example, nntp had shown decades ago that data storage federation is possible. It's about coming up with the right protocol.
To ensure low latencies, I'm OK with the protocol allowing a server to cache and render recent data, while a
background service syncs to the de-centralized store.
NNTP didn't maintain any kind of privacy of data, though. Once you layer that in, the complexities are tenfold.
It's the issue that arose when I was working on Appleseed. People really wanted a fully decentralized social network, but they wanted to maintain the kind of lock & key access that silos provide.
Federation allows you to have a modicum of control over data, but you still have the "message passing" problem, where once you distribute the information across the network, you don't control what people do with it anymore. This exists, to a lesser extent, in a silo as it concerns the users, but with federation, it concerns the hosts as well.
So people want it fully decentralized, but also encrypted, but also available easily, but also secure, but also user friendly with a decent UX (discoverability, speed, etc).
That's a whole lot you have to balance. It is about coming up with the right protocol, but that's a much bigger problem than that sentence broadcasts.
I think most projects start trying to solve all these problems, but then settle on one aspect of it.
I don't think any project balances all of them in any meaningful way, but if any were ever able to pull it off, they'd change the internet as we know it, forever.
I wrote a paper back in 2010 about a proposal for having browsers handle private keys, and a decentralized social network could then store encrypted data, which would be decrypted at the browser level. But in order to maintain that kind of trust, it would have to be baked into the browser directly. A plugin wouldn't be trustworthy enough and wouldn't have the necessary install density, and client-side JS is out of the question.
And then there's the UX question to how users handle private keys. Do you start to expect everyday users who just want to browse their social network to juggle private keys, move them across devices, etc. And what happens when a user wants to search the network? Even if it's possible, I can't think of a way that isn't extraordinarily slow.
But that's one way you could handle encrypted data so that the servers involved don't have any idea what they're storing. Then you could split it into chunks and spread it all over the place.
There's just so many moving parts, and all the projects working on it are underfunded and undermanned to solve just the single aspect they're focused on, which isn't even the whole package.
I'm not saying it's impossible. It's just extraordinarily difficult.
Of the projects I'm aware of (I'm sure there are many I'm not) - the one that seems to hold the most promise of realizing a working set/trade-off of these features is probably ipfs[i,f]. At it's core it's "just" about a p2p content-addressable web - but with a naming scheme and client-side public key based crypto -- it should be possible to build both an "open" and a "closed" web on top of it.
It's not there yet, though. But as I said, of current projects, that have people doing real work, and is in some sort of alpha state -- I think it holds the greatest promise.
Just getting the features there is going to take a while, not to mention stitching together a user experience and user interface that actually makes it usable in an easy and secure fashion for regular users...
[f] The faq repository: https://github.com/ipfs/faq/issues (note a lot of discussion and open questions - ie: not all these have a clear "best answer")
I don't believe built in federation would be a good idea. There should be a reasonable business in hosting sandstorm. I would like a german or european Sandstorm hoster for example. This would mean my data stays within my jurisdiction and my privacy rights can be enforced. Any data which escapes to the US is open since Privacy Shield is a political joke.
The idea of the data staing once place is fine, but that can be where the key resides? The domain information acts as identity and perhaps also the location of the above key.
Businesses can be built on commodity storage/compute. But these cannot be given the keys to the kingdom, which you currently do with any saas service.
Spent the past 2.5 years building a decentralized cloud storage platform (Sia), it's still in the early days of usable, but maybe we can help somehow here?
Today, you need to save all of your metadata or you can't retrieve the files. But it's a lot easier to do a safe/broad backup of 10MB than XXXXGB.
At some point down the road, I think we can have it as simple as 'private key in, your data out' Ina decentralizated netowrk, as your key is used to contact a bunch of hosts in a 1-of-N failure mode (one honest host is all you need to get the right data) to fetch your metadata.
Actually, I agree. We originally used the term "platform". But, we found that people understood more easily when we switched to "operating system" -- and it's not too far off the mark, honestly. Sandstorm is an OS in the sense that Android is an OS. Both use the Linux kernel, but largely control the userspace. (Sandstorm can run along-side your existing Linux distro without interfering with anything, but it doesn't really use any of your distro's infrastructure so this is somewhat of a technicality.)
The problem with "platform", which surprised me, is that a lot of people now think "platform" is somehow synonymous with "cloud service". For example, if you watch HBO's Silicon Valley, you may remember the whole "platform vs. box" debate from this season. It's a frustrating perversion of the word, but it is what it is.
It's actually restricting our thought to an annoying extent that we've overloaded the term "operating system" so much. This isn't Sandstorm's fault -- Windows already has billions of people thinking "operating system" == "desktop environment" so the ship has already sailed.
I would really like a word that describes this set:
+ Unix CLI
+ WIMP desktops
+ Browsers
+ iOS touch interface
+ Android touch interface
+ Emacs (when used for general computing)
Perhaps "user environment" would work?
EDIT: For me at least "platform" doesn't quite fit. I think whatever word is best should imply "single user interface" which platform doesn't necessarily.
My concern with the misuse of the world "operating system" is that I've seen this trend noticably devalues the term in my own operating system projects, which are actual operating systems.
To run it on your existing operating system, you would need to modify the Linux kernel in such a way that makes it unsuitable for running other services.[1] I'm fine viewing it as a specialized operating system built on the Linux kernel.
[1]: It requires that the Linux kernel be compiled with `CONFIG_USER_NS=y`, which has multiple privilege escalation vulnerabilities, disabled by default on most distros[2]. If you turn it on, you are saying "all of the non-root code that I am running is managed by a trusted seccomp monitor process that prevents it from using user namespaces" which effectively means "all of the non-root code I'm running is running inside of Sandstorm".
[2]: Many distros (Debian, Ubuntu, CentOS) actually have `CONFIG_USER_NS=y`, but patch the kernel to make it be run-time configurable via a sysctl flag (the flag set to "off" by default). This doesn't change the fact that turning it on (whether it be via a compile-time flag or a run-time flag) makes it unsuitable for normal use.
Ok, so more distros patch it to be a run-time sysctl flag than I thought.
That doesn't change the fact that turning it on (and expecting to not introduce significant vulnerabilities by doing so) is saying "I'm running a significantly different userland than the standard one."
I wouldn't recommend enabling it on a server that gives out shell accounts to multiple mutually non-trusting users...
... but I also wouldn't recommend operating such a server, period. Linux has too many vulnerabilities on a regular basis for it to be practical -- yes, many are userns-related, but many aren't.
On a single-user desktop, enabling user namespaces is irrelevant. (User-root separation does not matter on a single-user desktop. All your sensitive data is in your home directory.)
On a server machine that runs one service, again, enabling user namespaces has no significant security impact. If you are running multiple services on one machine and relying on UID separation (with no other sandboxing) for defense-in-depth, then, sure, enabling userns adds risk -- but again, disabling userns does not completely eliminate the risk.
If we can't even trust UID separation to work, then the project of secure computing is hopeless. We've been working on UID separation for decades. If we can't get it right after all this time, what hope can Sandstorm possibly have of getting a new system right? Furthermore, abandoning the Unix permissions model requires us to rewrite the world. (a rewrite that, admittedly, Sandstorm has already made some great progress on)
But, I think it is reasonable to trust UID separation and the Unix permissions model. Linux is not that vulnerable. With some diligence, a server can securely provide access to computational resources to multiple mutually non-trusting users, through the mechanism of Unix permissions. And it's really the only hope we have.
> If we can't even trust UID separation to work, then the project of secure computing is hopeless.
Not at all. We have better sandboxing mechanisms now.
> If we can't get it right after all this time, what hope can Sandstorm possibly have of getting a new system right?
UID separation has broken down because the attack surface has grown too large, encompassing:
* The entire ever-growing system call list.
* The huge /proc and /sys filesystems, which let you muck with all kinds of process and system state.
* Devices in /dev, many connected to low-quality device driver code.
* Every setuid-root binary installed on the system.
When the API gets that huge, avoiding bugs across the whole thing gets impossible.
Modern sandboxes work by massively reducing this surface. Sandstorm apps are restricted to a core set of common system calls, do not get /proc or /sys, only get a couple devices in /dev, and cannot use setuid-root binaries. In this situation, security is much easier.
Moreover, we use a capability-based security model to permit apps to talk to each other and the world, rather than an ACL-based one. This model makes it much easier to start from zero and grow, rather than starting from everything being accessible and then shrink.
Android has no kernel (it uses Linux), but most people think Android as an OS.
The original MacOS didn't either (it was a collection of subroutines in ROM that user programs would call into), but was also generally considered an OS.
But unlike Android you can easily install sandstorm.io on different linux distros, in fact I don't even think there is an installable OS image available.
There's a distro that back in the day did not have installable images; they only had a script to install it from an existing distro (I think it was Gentoo, but I'm not sure on that). Given that with Sandstorm, you are essentially replacing the standard GNU et al. userland with the Sandstorm userland (since turning on user namespaces with the standard userland would allow every user to be root), I don't think that it is unreasonable to view Sandstorm that way either.
ROS is Robot Operating System— it runs on top of other operating systems, like Linux, Windows, and Mac OS.
But it's definitely an OS in the sense that it provides tooling, build and distribution infrastructure, plus OS-type services such as message passing APIs, standard plugin interfaces, etc.
So are you saying operating system is a subclass of platform? I guess but that distinction doesn't seem very useful. It seems more like the term operating system has aged. I'd rather call Windows/Linux a platform instead of an operating system and indeed other people do too. Even then, some people consider it a design smell to consider software a platform.
Long story short, semantic arguments aren't interesting and there's no logical argument against calling Sandstorm an operating system.
I'm excited. Today was the first time I tried Sandstorm via their demo serivce, and I must say that I am genuinely surprised and impressed with the level of polish. One click gave me a private gitlab, a collaborative document editor, and even a running instance of browserquest!
This level of polish might just be what it takes to get the masses to host their own digital services. I'm strongly considering setting a sandstorm server up for my family.
One question promptly and prominently pops to mind: Given the focus on non-technical users, How does sandstorm mitigate issues that are caused by NAT and NAT traversal?
> Given the focus on non-technical users, How does sandstorm mitigate issues that are caused by NAT and NAT traversal?
At present... not very well, to be honest. If you use sandcats.io (our dynamic DNS), you do have to open port 443, which means you need to understand router config. It would be cool to automate that with UPNP but we haven't gotten there yet. The prevalence of "hairpin routing" bugs in home routers is also a downer. :/
One idea I'd like to pursue someday is the one taken by IndieBox (no longer Googlable -- the one by Johannes Ernst): have a device which sits between your modem and your internal network, so that it can intercept DNS and make the server available at http://sandstorm or whatever. Then do UPNP to make it externally accessible (if desired).
I wasn't aware of Sandcats.io. Thank you for mentioning it.
While it doesn't address all issues, it does go a long way towards mitigating them. I must also take this opportunity to commend you guys on how transport security is handled; the fact that traffic remains secured end-to-end using a host certificate rather than terminating security at the proxy puts sandstorm well ahead of anything else in this space.
Secure, easy, and open source. I'm sold as both a developer and an end-user.
I saw this last night and signed up for oasis on my chromebook. I created a Jupyter notebook and entered an expression in it. Nice. Then I closed the lid to my chromebook for the evening.
Next morning I opened up the lid, and it helpfully told me it wasn't connected. I waited a bit longer and updated the expression. The cell text updated but after pressing 'play' the result value did not update, leaving my screen in an inconsistent, incorrect state (wrong value for displayed input to function). There was a little sign telling me I wasn't connected.
I had signed in originally with gmail. People are going to expect a similar interaction model to google docs. There was no obvious way to get back online, short of killing the tab... and getting back how? Remember a link? A bookmark?
This doesn't work yet -- not for most people.
Beautiful, beautiful job. Get the rest of the way there please...
The connection problem sounds like it may be a bug in Jupyter, or the Sandstorm Jupyter package, rather than Sandstorm itself. It would be great if you could file a bug on the package: https://github.com/jparyani/ipython/issues
Usually these kinds of issues are solved by a refresh, though that's obviously not great UX.
> and getting back how? Remember a link? A bookmark?
Almost certainly -- and therein lies a problem for you. There is an ambiguity between who owns the tab -- you or Jupyter app? The user of course will think of you and the app as the same thing. If you let Jupyter throw up a message saying 'you're disconnected' the user will infer that they are disconnected from you.
It's not clear the user is wrong btw -- why does a mis-behaving, buggy app, throw me into offline mode? Is it just Jupyter that is offline, or the whole of sandstorm? The message says the tab is. And I can still see components of sandstorm. Of course, I bet if switch to another app it will heal itself -- or will it? Most users won't think of that (or a refresh, or a CTRL+F5, or looking at the debug console for a hint etc.)
So my challenge to you is to explain how the offline/online model works, in a way the user can understand. I suppose big organizations like Google just solve this problem by not hosting buggy apps in the first place. :) :)
It is probably worth your while, from an adoption standpoint, to 'take ownership' of a few key apps and treat their bugs as your bugs -- I would be showing this to coworkers tomorrow if this had worked better, and it probably isn't your fault. They are keen on Jupyter and this is the best delivery platform I've seen for that app. Sharing jupyter notebooks in an enterprise setting could be your killer app -- they contain private data, and a public cloud won't work in many use cases, but most enterprises won't have enough of a constituency of scientists and engineers and statisticians to want to host a notebook server with 'front line' support. We're in the carpet cluster days here...
> 'take ownership' of a few key apps and treat their bugs as your bugs
Actually, we plan to do something like that! Though, Jupyter isn't part of the initial set -- our most popular apps are Wekan, Etherpad, Rocket.Chat, and Davros, so we'll be focusing on those.
That's good to hear and I see why those would be popular. I'm a bit surprised that a kanban board is so important.
I'll put in my vote for replacing Wekan with Jupyter -- it's more strategic to win mindshare outside the closed circle of developers. The average unsophisticated user who just wants apps, your target market, doesn't want their very own kanban board. A photo album yes. I speculate your early adopters are predominantly developers themsleves and that's why it's popular. It does fit my comment about private data being an important use case for you, of course.
Sharing homework assignments or spreadsheets of data would be more strategic for you, imho. It could help you break into the 'educational shared docs' submarket -- every school I know uses google docs right now for convenience. And don't forget homeschoolers, and teachers setting up courseware sites. I would think the educational market would be key for you to gain mindshare and grow beyond the community of early-adopter developers.
Anyway, best of luck. This is some really good work you are doing.
I agree that you raised some valid points but I think your delivery in making those points were pretty abrasive though. At least that's how I interpreted it!
every social community I've seen eventually has to give up the downvote as a tool and just have upvotes or likes, or else they peak when the downvoting gets out of hand. I think HNN passed that point about 1-2 years ago. I see more and more worthwhile comments greyed out and I'm sure good contributers who advocate unpopular languages or discount the latest hotness are now driven away.
I think the HN community is pretty diverse and for the most part attracts people who are genuinely interested in constructive discussions. The folks who blindly dismiss something as being the new "hotness" are probably down voted because they were simply doing that - blindly dismissing without providing any useful feedback.
There's nothing wrong with disagreeing with something, but I think it's important to provide useful feedback and even more important to provide it in a useful way.
I quite like seeing what the new hotness is, and I equally like reading about unpopular languages/projects too. I usually get more insight into those projects when I read through comments because a lot of smart people (probably a lot smarter than me) provide some awesome input. The posts that I see as having been flagged or down voted is usually because the comment was aggressive or completely non-constructive (trolling).
Personally, I'm indifferent in either case. If I don't like or necessarily agree with something I read, or it really doesn't add anything to the discussion, I just scroll down to the next comment. But I'm sure the people who are passionate enough to down vote a particular comment are the same people who will upvote others, and given the broad userbase HN attracts I'd assume that for a person who down votes a comment, there's probably another who upvotes - unless the comment is just a straight up troll then the community usually does a good job at moderating.
I think the up/down voting system works pretty well; it gives the community some ability to moderate a thread so that we can focus on the content that matters. That's not always the case of course, but I think it works most of the time.
Love seeing this on top of HN, in light of recent discussion about securing your own email. I've tried Sandstorm a couple of times and loved it. They're always improving.
Kenton himself seems ready to respond in depth both whenever Sandstorm is discussed on HN, and at times when I email Sandstorm for support.
I'm sure he's got his limits. He is setting a high bar for customer support within the company. I think that's smart.
Innovation does not happen in a vacuum. Talking to customers with an open mind is a great way to learn what they want and spur some creative process within yourself.
We believe in releasing early and often and using feedback to direct development. (Truth be told, this is why the "powerbox" features that we like to talk about a lot aren't totally done yet: user feedback identified many other, more pressing things to improve!)
That said, my dirty secret is that I have a little app that queries HN search every five minutes and gives me a desktop notification whenever Sandstorm is mentioned. :)
> my dirty secret is that I have a little app that queries HN search every five minutes and gives me a desktop notification whenever Sandstorm is mentioned
I guessed that. You were too good at it. Good job making the name unique haha. Just hope there is no anti-real world sandstorm tech that's developed in the future ;-)
I don't think it's dirty. That's a service itself that other companies would do well to follow by implementing in-house or through investment.
I think many companies do track mentions. Few follow through with real engagement. There is a difference between observing and engaging. In these fast times, I imagine it makes a difference.
Perhaps some users would find this intrusive, and I guess it could be done poorly. I think you set a good example (so far.. ;-) )
Google alerts and/or some kind of analytics service can also (to a certain degree) give you an opportunity to answer discussions while they are still active.
I seem to remember someone mentioning the idea that in the future you could "layer" sandstorm's grains such that you had one that was your inbox (running, say, Mailpile) and have a pass-through SMTP grain that was responsible solely for pgp-signing messages. That way you keep your pgp keys safe from any security vulnerabilities in your mail client. I could be misremembering, but it sounded like a cool idea.
I just thought this was relevant in light of the recent discussion about how to protect yourself in the event your google account is shut down. Sandstorm has an email client as well - and you can 100% control your data.
So I've been thinking a bit more about sandstorm recently as I'm planning to build something and need to work out how I want to host/distribute it.
It'll process data for people and I'd absolutely love to be able to write the app "ignoring" multiple uploads, user management, team-like sharing, etc.
I'd be expecting this to potentially be a paid app though. In app billing is mentioned as a "coming soon", is there a roadmap or expected timescale for this? Is it a "we kinda plan this sometime" or "currently in development, releasing soon" kind of phase?
If not, I don't know how well it'd fit on their shared hosting, as the processing might be fairly intensive. Is it reasonable for me to install sandstorm on a server with my app and let people use that? Sort of like the shared hosting but with only my app available? Does that make sense or am I completely misusing the intended overall structuring of sandstorm?
We decide what to do next based on demand, so having someone like you asking us for in-app billing would make it likely to happen sooner. Feel free to email us and tell us about your plans!
With that said, I would expect in-app billing to be at least 3-6 months out, possibly longer if we see more interest for other features first.
However, note that you don't necessarily need in-app billing to sell a Sandstorm app. You could always transact the sale yourself, and then ship an .spk file (Sandstorm package) to the user.
Anyway, please email me (kenton at sandstorm.io) if you'd like to discuss this!
Sandstorm is simple an intuitive which is what a lot of our decentralized projects really need a good helping of. I watched the recent Decentralized Web Summit, and there was so much talk about decentralization, yet so little talk about self-hosting, federation or the projects that are out there doing the dirty work today. It made me sad. People are looking for alternatives to silos, not every one of course, but a lot of people just get overwhelmed with the thought of self-hosting. Sandstorm is helping with that it seems. I wrote more about this here[0] if you're curious.
Does this OS provide building blocks for collaborative applications? Or does every app have to reinvent collaborative editing?
Update: Okay, so I created a flowchart in one instance, then shared the link, and opened it in another tab. Edited the flowchart in one tab, but it didn't change in the other tab. This is imho not how a cloud OS should work.
Almost all Sandstorm apps support real-time collaboration. It sounds like you tested draw.io, which unfortunately is one of the few that currently does not.
Sandstorm does not dictate what tech stack you use -- it supports any server stack that runs on Linux. Supporting real-time collaboration is normally the job of your tech stack. If you use Meteor, for example, you'll pretty much have it by default.
Sandstorm does make real-time collaboration easier to operate at scale through fine-grained containerization: each "document" runs in a separate container as a separate instance of the app. Sandstorm ensures that there is never more than one instance running for a particular document, so you don't have to worry about concurrent writes coming from another machine. Scalability is achieved by distributing the documents across machines.
Sure, but if you have hundreds of people trying to edit the same document, you are going to have a bad time no matter what architecture you use. This is why Google Docs reverts to read-only mode when too many people show up. We could do something like that too: give the app an API to provide some static content as a fall-back when a grain is overloaded.
All the random domain sha1 like domain names are confusing. I also dislike that many of the apps have missing features compared to the actual apps and they get embedded in iframes. I understand all these are done for security.
There's a proposed W3C specification for "suborigins" which would allow isolating webapps at a more fine-grained level than the current host:port combination. It'll probably be a good long while before it gets fully standardized and implemented, though.
Still looks a lot like yunohost[1] and cozy cloud[2] which for some reasons I find more attractive than sandstorm.
Then we have a rather new contender: ArkOS
Without tackling thoughts on each specific alternative (there are a few others I've played with or looked into as well in this space), the biggest thing I've found is that Sandstorm has a novel approach to security. Some of the other app platforms allow all of the code for different self-hosted apps to run right on the server. Personally, for me the biggest concern is that most of these platforms let apps have full network access.
Sandstorm has lagged in certain offerings of apps while the platform makes it possible for them to work, because they've approached this from the point of locking down everything, and then carefully opening up what's needed to do more. (Early versions of Sandstorm, apps could only provide completely self-contained documents, and had no connectivity outside of Sandstorm.)
Some people might prefer the others for the easier ability to run those sorts of apps. Another big potential reason to choose another platform might be that different platforms run on cheaper servers or setups. (Sandstorm doesn't work on most cPanel hosting offerings, nor can you install it on a Raspberry Pi, which is a popular request.)
I think, if anything, it's fantastic that self-hosting isn't becoming a monoculture. We have a variety of options out there, most of them are open source, a lot of them support the same or similar sets of apps.
This is the beginning of the end of the "as a service" era.
I'm not entirely clear if you're saying you prefer both yunhost and cozy cloud to sandstorm (or just cozy) - but at least for cozy.io it doesn't really seem like an alternative to sandstorm, as per the faq: "Currently Cozy supports only Node.js applications.", while as can be seen from: https://docs.sandstorm.io/en/latest/vagrant-spk/packaging-tu...
"The tutorial uses a PHP app as an example. Sandstorm supports any programming language that runs on Linux, not just PHP, such as Meteor, Python, Rails, Node, PHP, C++, Go, Rust, and more. Read about vagrant-spk's platform stacks to see how to optimize your package for your app's programming language."
As for yunohost it looks like it is more comparable - but essentially is a "cpanel on steroids" - a nice way to automate managing classic server applications:
Thank you for mentioning these, I wasn't aware of either -- but I don't think they really are an alternative to most of the use-cases sandstorm excel at.
Arkos seems similar to yunohost, although rather than an easy way to manage Debian, it's an easy way to manage Arch on arm (a curios limitation IMHO):
Let's put it this way, both are part of a larger effort to put the web back in tracks by having more people self-host their data and web services. Then sandstorm uses a third party google service to track visitors while cozy and yunohost use a self-hosted instance of piwik.
One of those is not putting his money where his mouth is...
Sandstorm is made from an ex-google employee while cozy has the founder of the european branch of mozilla in its ranks.
Then there is the AMD64 limitation of sandstorm, while the other offer support for ARM, the de facto architecture for a low consumption personal server.
I think the sandstorm.io website is dense and hard to comprehend, it's not to the point and from the get go I can tell it's pretending to be something it is not (an OS).
Also the sandstorm demo feels clunky to me and I experience random crashes and error messages while trying apps in sandstorm.
In the end my preference goes to yunohost because it's not from a funded startup with a full team which may explain why it stayed simple and within reach.
IMHO ArkOS is closer to freedombox than yunohost, also supporting ARM is the feature not a limitation as it seems obvious that the personal self-hosted server is running on cheap, low consumption embedded ARM. To me a curious limitation is not supporting ARM.
I think I disagree with almost all your points here (or that they are a reasonable criticism/list of things that should be changed with sandstorm) -- but I appreciate you taking the time to respond in such detail. (Modded your comment up FWIW).
Didn't realize that Sandstorm (currently) targets only AMD64 - for others interested, the rationale is here:
I don't really see this as much of a problem - at a later point, if Sandstorm is packaged for something like Debian, it's likely people will work on porting it to Arm. As most of the software is already ported, this shouldn't be insurmountable.
OK so this looks awesome and I had half a dozen ideas for things I'd like to do with it in about 30 seconds. Is anyone using it? Would love to hear from some experienced commentors.
I've been using Sandstorm as my primary document writing and storage location for a while. I've mostly been using the Oasis hosted service (and their alpha server prior), but I've also installed Sandstorm on a couple of VMs for dev and testing purposes. I'm pretty happy with it, and happy with the apps available for it.
There's still some things I'm waiting for, such is the life of using a platform that's still in development by a small team. Some way to organize my grains is the big one left right now. But especially recently a lot of the stuff "down the roadmap" is starting to feel finished. The Powerbox features are getting there. Active Directory integration exists now.
Since somewhere in 2014 when I started playing with it, it's always felt like it was moving forward.
I use it for file storage, photo sharing, etc. An EC2 T2.medium with a gigantic EBS volume attached, and sandcats.io makes it really easy to set up a domain. I've written a couple of apps for it, there are a few things to know about what makes an app work well but the #sandstorm irc channel is really friendly and helpful.
Most unique use case of mine: my phone runs Owntracks which logs location data for walking around the city, vacations, etc. I obviously don't want _that_ on google, but am slightly more comfortable storing it in a self-hosted Sandstorm instance.
Speaking of which, what is the status of Cap'n Proto? I was looking at using it for a side project recently, but it doesn't look great on the surface: there haven't been any updates on the site since March of last year, and that post was to address a security vulnerability.
Cap'n Proto is essentially a sub-project of Sandstorm. Lately, there hasn't been a whole lot of churn in Cap'n Proto land as it is doing what we need it to do. That said, there are a few features I'm becoming increasingly eager to implement, probably later this year. The biggest one is three-party handoff: when Alice holds a capability pointing towards Carol and sends that capability to Bob, then Bob should form a direct connection to Carol rather than proxy requests through Alice. This will be important for improving scalability of the cluster version of Sandstorm, although at the moment it's getting along fine without it.
But yeah, Sandstorm uses Cap'n Proto extensively, so if there's no updates to Cap'n Proto, it's because its biggest user hasn't seen a need to make many changes. :)
Can you explain the "Fine-grained Object Containers" concept a little more?
For example, how is this enforced: "JavaScript running in the user’s browser can talk only to the document container for which it was loaded, no others."
> For example, how is this enforced: "JavaScript running in the user’s browser can talk only to the document container for which it was loaded, no others."
Each grain (or actually, each session on each grain) is assigned a randomly-generated subdomain. These domain names are unguessable, so there's no way for one grain to know another's domain, and anyway same-origin policy generally prevents Javascript from interfering with other domains. (In the future, we plan to further lock down the client side using Content-Security-Policy, although we haven't done this yet.)
> Do apps need to be SandStorm aware?
Yes, apps need to be packaged for Sandstorm, and that usually involves some modifications to the app. However, the modifications are usually mostly deleting code: you delete your user management and rely on Sandstorm, and you delete your multi-document management and instead let the user create multiple grains at the Sandstorm level. Typically, this work takes a few hours, though it varies depending on the app.
(It's also worth noting that apps which target exclusively Sandstorm from the start are much easier to write than normal web apps: User management, document management, security, access control, etc. are handled for you.)
Thanks. I'd poked through the howitworks. What threw me off was the reference to Etherpad, which made me think apps could somehow run on SandStorm unmodified. Makes sense now!
Is there a way to run e.g. an email server on Sandstorm?
Last time I looked it seemed like that would never be supported because it would violate the sandstorm business model, which, as I understand it, appears to be selling very cheap hosting of grains, made possible because only disk resources are used when an grain is not currently in use.
This would seem preclude the hosting of services that need to be running all the time in the background.
Sandstorm's business model is selling enterprise-oriented add-ons and support (e.g. ability to integrate with LDAP/SAML/Active Directory, or (eventually) providing HIPAA compliance, etc.). The hosting service actually exists more so that developers know that their apps are usable by everyone, not just people who run their own server.
There's actually no need for a mail server to be always-on. It could start up whenever a message arrives. Sandstorm is good at this kind of on-demand starting.
We very much intend to support using Sandstorm as your email server. It turns out, though, that e-mail is a complicated subject which operates on a different set of protocols from the rest of the web (SMTP vs. HTTP) and has a whole lot of hairy stuff you need to do to make it actually work (SPF, DKIM, ...). Since there are quite a few options out there already for handling email, we've chosen to focus elsewhere in the short term, but I hope to loop back to email in the coming months.
Yes, it should be possible to run an email server as a Sandstorm grain. Note that you would need to grant the grain networking capabilities so that it could talk to the outside world. Currently, only the admins of a Sandstorm server are allowed to grant such capabilities, but that will change once we've implemented our plans for trusted "driver apps" that attenuate and manage admin capabilities.
A grain can keep itself running in the background by requesting a wakelock from its Sandstorm supervisor process. While the grain holds the wakelock, it does not get automatically spun down, even if there are no users visiting it.
All the examples I see on your demo are web apps (and the documentation seems to be focused on web apps as well).
How well are applications without a web-interface supported?
For example, could I easilly package and launch something like a teamspeak server on sandstorm, or would I need to add some mock web server that kept the real server online?
You would need to add a web UI for configuring the server, as the user won't be able to SSH in and edit config files. (This is by design: forcing users to use shells and text editors is terrible UX.)
Currently, you would also need to request a raw IP networking capability from the user. Only admins of the Sandstorm server are able to grant this capability, for security reasons. So if you are self-hosting Sandstorm, you're good, but you wouldn't be able to run the app on Oasis currently. We are working on better solutions here.
How do app updates work with Sandstorm ? For example, if I host an instance of the Ghost blog. Now, say it updates from version 1.2 to version 2.0 (which means probably a breaking database schema change or something). How would Sandstorm go about updating it ?
A grain's filesystem consists of read-only app data mounted at / and writable grain storage mounted at /var/. From Sandstorm's perspective, upgrading a grain to a new app version just means launching the grain with the new app version's read-only data, leaving the writable /var/ data untouched. The app is then responsible for detecting if any migrations are required and for performing them if so.
Some apps, such as WordPress, already have logic for automatically updating the database when the code changes. Other apps need to add some simple version-detection logic in their startup scripts.
I realise I'm coming late to this thread, but just a quick question. But before that, a big hats off to everyone involved with Sandstorm! Making a complex platform point & click is a huge achievement.
Coming to my question, does Sandstorm have a HTTP server in its app platform? While I'm excited about other apps like file sharing/storage, what I badly want to do right now is to be able to host my site on my own machine using dynamic DNS. Of course I can manually do it by installing Apache, configuring it, updating a dyn DNS provider and so on. But if Sandstorm offers a point & click way to do that, then I'm hooked right now. :-)
If it's a static site, there are several apps on Sandstorm you can use: Wordpress, Ghost, Hacker CMS (which is basically Jekyll + a text editor), or Davros (to which you just upload files, and then publish). Any of these will allow you to connect an arbitrary domain to the page so that visitors see your content only, not Sandstorm.
If you want to publish a dynamic site with server-side logic, that's currently not supported, unless you are OK with it being a Sandstorm app, which means everyone who accesses it will see the Sandstorm UI around it.
Thanks for replying! A static site over SSL on a custom domain will do well right now. Presently I'm using the motley combination of uploading HTML to Github Pages and placing Cloudflare in front (for SSL on a custom domain), but Sandstorm sounds like a more painless alternative that would also mean I retain my data on my own machine. Will get started!
Very cool! Last time I checked Sandstorm, the powerbox system was still in development. Now it seems finished, according to the docs. Is there are more in-deptg doxumentation about the UI flows and APIs?
It's not totally finished yet, but parts of it are finished and will start being used by real apps in the next week or two.
The reason it has taken a while is not because it was hard, but rather because we've been repeatedly pulled away by other, more-pressing concerns, e.g. basic usability issues or features like the activity/notifications API (which turns out very important for people trying to do real work on Sandstorm).
The most in-depth documentation is the .capnp files in the source tree. We will be writing better documentation as the features stabilize (soon).
OS seems a little presumptuous. As does the majority of the "how it works" page. Making wildly ridiculous claims that amount to "microservice are silly" (my paraphrase) when really they've only managed to successfully sandbox applications. Much like Android with its "a user for every app by default."
> Sandstorm takes a wildly different approach [than containerized services]: It containerizes objects, where an object is primarily defined by data
Or... You've containerized the data access service and enforced a per-application sandbox. Plenty of precedent there.
>
Microservices are seemingly designed to match the developer’s mental model of their system. Often, services are literally divided by the team who maintains them.
Good Lord, I sure hope that's not true. Maybe if the non-technical manager designed the system.
> In the Sandstorm model, all of the components (from web server to database) needed to handle a particular grain run on the same machine.
So your container scheduler can optimize for I/O. Again not that far from existing cloud schedulers.
I'm not saying this isn't a powerful model or platform.
I am saying that I'm very disinclined to want to work on such a platform, purely because I'm worried its developers buy into the "everybody else is way off base" attitude, when really they're only doing what many many successful architectures have done before them.
Hi! I'm the founder / tech lead of Sandstorm. I wrote that "How it Works" page (https://sandstorm.io/how-it-works) and designed the architecture it is describing. Before Sandstorm, I worked at Google on infrastructure for eight years. As you may know, Google has been doing containers and microservices for over a decade. What I describe on the page is largely based on that experience.
> Plenty of precedent there.
I've personally never observed a production (non-research) server architecture which containerizes and sandboxes application servers on a per-document level. That is, say, with Etherpad on Sandstorm, every document you create is in a separate container isolated from the others.
I would love it if you could name some specific examples that work this way, as I'd very might like to see what others have done.
I get the grain-per-document thing. Sounds interesting for at least a subset of applications, and disagree with the grandparent that it's common practice.
First question that comes to mind is how the data source is sharded like that. You say in another post that you don't mandate a tech stack. So let's say I want to store my data in MySQL. Are you saying each document literally has its own private database instance?
I have many more questions, but they will depend on your answer to that question. :)
> Are you saying each document literally has its own private database instance?
Yes. Each "grain" (our catch-all term; could mean "an Etherpad document" or "a Gitlab repo" or "a Wekan board", etc.) gets a slice of filesystem to do whatever it wants with.
Of course, MySQL is totally overkill for this task. We generally encourage people to use sqlite instead. But there are a couple apps that do actually run MySQL in the container, mostly because switching to sqlite would have been too much work. There are also several apps that use Mongo, but it turns out Mongo 3's WiredTiger engine is reasonably efficient for small data sets, so it works out.
The model definitely is friendlier to some kinds of apps than others. Productivity apps with clear data boundaries -- Etherpad (document editor), Wekan (Trello clone), Rocket.Chat (Slack clone), Gitlab, etc. -- work very well, and are our main focus. "Big data processing" apps are not well-suited to this model. We're happy to cede those, as there are tons of people doing great work in that domain.
Currently, the whole Rocket.Chat instance is a grain.
However, it would be "more Sandstorm-y" if each channel were a separate grain. For that to work well, though, we need some UI features to emulate what Rocket.Chat already does internally:
* The ability for grains to highlight themselves in the sidebar when there is activity or when you've been mentioned, so that you know to check them. This API actually just launched last week! So now the apps are being updated to use it.
* Some way to create "private message" grains between two people. We haven't done this yet but we have some ideas.
Soon, I hope to see Rocket.Chat add a "single-channel grain" mode where its own sidebar is removed and it relies on Sandstorm's sidebar. This would provide better security for channels which should only be accessible to a subset of people. Probably, the multi-channel mode will stick around too, for cases where you want the same people to have access to many channels.
To be clear: The container shuts down, but the storage stays. Since the data set is small, apps start back up quickly on-demand. Moreover, the storage for app assets (code, binaries, images, etc.) is shared read-only among all instances, so the marginal storage usage of each grain is only the per-grain data, which is usually very small.
First, apologies for my snippy knee-jerk comment. I should have probably taken more time to compose my thoughts. And congratulations on the platform's popularity (at least as far as I can gather from GitHub stars). It seems that it definitely hits a sweet spot for many people as far as ease-of-use. Additionally, I think it integrates a lot of great ideas, some in combinations that thus far are not quite mainstream.
I think what bothered me is actually best described by the current top comment. "How it works," too, seems like mostly marketing hype, and in my personal experience many of its technical claims regarding novelty or distinction are inaccurate and come across as sanctimonious.
As you may guess from my mentioning Android above, that's the most mainstream system that I think obtains the described level of sandboxing while allowing highly-fine-grained access control when the data is to leave a sandbox. For example, if I share a photo from one app to another, it does not gain access to all photos but rather only the one I selected.
The same-origin policy also springs to mind as a great example of application and data sandboxing by default.
Sandstorm does have very fine-grained defaults, which I think is the best, and of course capabilities are the more feasible AuthZ primitive for distributed system [1].
All in all, I think we have many of the same opinions, and I've seen the success of similar models several times in the past. This is probably a good deal of why I find it frustrating and disingenuous when they're described as novel.
Android sandboxes apps, but it does not sandbox documents within apps. For example, when I use the gmail app to connect to both personal and work email, there is nothing stopping an exploit that lands in my personal inbox from reading all my work email. Similarly, same-origin policy generally divides apps (in the form of domains), but not documents -- if I have two Google Docs, and someone XSS's one of them, they can read and infect the other.
Of course, on a phone (or a single user's browser), you usually have only one user, which makes it less clear why apps should be internally partitioned. On the server side, the traditional model is multi-tenancy, where all of Google's billions of users are potentially hitting the same server containers (modulo geography-based load-balancing).
We definitely don't claim that the capability model is new, and I'm happy to acknowledge that many research systems based on a strong capability model implement something like Sandstorm's fine-grained containerization. Mark Miller, one of the (probably, "the") foremost researchers on capability-based security is an advisor to the Sandstorm project -- you'll see him listed on the Team page. Marc Steigler -- who I believe invented the word "Powerbox" -- is also a friend, as are Tyler Close (Waterken), Norm Hardy (KeyKOS), Alan Karp, etc.
The thing is, though, CapDesk and KeyKOS never made it beyond being research systems -- proving a point, but not widely used in the real world. Also, they predated the "cloud services" era.
I would still like to know if there are other examples of server-side fine-grained containerization that I'm missing.
> Making wildly ridiculous claims that amount to "microservice are silly" (my paraphrase) when really they've only managed to successfully sandbox applications
No, you don't understand the Sandstorm infrastructure. Sandstorm abstracts the data from the application via the Cap'N Proto protocol, so the user, not the application, is in full control of the application data. The common data format makes all sorts of interesting isolation policies possible, like containerizing internal application state. There is very little precedent for this sort of feature.
I find this aspect of their docs totally confusing. Cap'N Proto is mentioned everywhere but without context. I went looking for more info on it and it looks like a serialization format like Google Protocol Buffers, but in the Sandstorm docs it's peppered everywhere in a way that makes it sound like magic pixie dust. How does a serialization format solve all these problems?
Not saying it doesn't, just that this needs to be explained conceptually. In reading the docs I can never seem to grasp what the key invention is. How is this different from a Docker host with a gateway?
The repeated invocation of Cap'N Proto also gives the impression that I would have to rewrite my entire app for this, but the number of familiar apps obviously means this isn't the case.
Cap'n Proto isn't really the magic that makes everything work, it's just a communications layer that is designed to facilitate Sandstorm's security model -- namely, Capability-Based Security. Here's some relevant links:
Note that Sandstorm does not require that apps store their data in Cap'n Proto format. Rather, the app communicates to the outside world via Cap'n Proto. Also note that many other protocols -- especially HTTP -- can be layered on top of Cap'n Proto, allowing apps that don't know anything about Cap'n Proto to operate. Here's how HTTP-over-Cap'n-Proto is defined, BTW:
The key advantage of using Cap'n Proto is that it allows Sandstorm to be aware of all of the connections that exist between apps, so that it can tell the user which apps are talking to which other apps and how those apps discovered each other, and give them the opportunity to revoke those connections.
>> Microservices are seemingly designed to match the developer’s mental model of their system. Often, services are literally divided by the team who maintains them.
> Good Lord, I sure hope that's not true. Maybe if the non-technical manager designed the system.
This just seems like a restatement of Conway's Law. Nothing outrageous or egregious about it. It's just how people are.
>> Microservices are seemingly designed to match the developer’s mental model of their system. Often, services are literally divided by the team who maintains them.
> Good Lord, I sure hope that's not true. Maybe if the non-technical manager designed the system.
Of course it is. It isn't even a terrible way to do it - making a team responsible for their own data end to end does decouple their development velocity from other teams.
Good microservices architectures are about data congruity and not team boundaries. Yes, they're hopefully small enough for a single team and may warrant further slicing if they're not, but I definitely would argue strongly against partitioning teams and services into 1:1 relationships. 1:N or 2:N maybe (they should be small enough to quickly learn), but never 1:1.
What about inter-company services? Inter-division? I think your "team:service = 1:N" model above is exactly what happens in many places, and exactly what you seemed to react so strongly to.
It isn't exactly uncommon for a data ownership to be aligned with team structure.
There are trade-off with all approaches, but I think your initial ("Good Lord, I sure hope that's not true.") comment is an overreaction.
In the Sandstorm UI, if you go to "Apps" and choose the app, you'll see a "report issue" link in the upper-right. Generally, these link to the GitHub issue tracker for the app or its Sandstorm packaging.
I found a way to get to the github page of the app.
Added the issue there.
(Open the app in the app store and click on the '</>' icon to go to the github page of the app)
Maybe feedback and bug reporting could be built into the Sandstorm system in a user friendly way, without need for a github account, both for apps and Sandstorm itself?
always wondered by such projects. you have the resources, and you have made analogues of paid services, and that's cool, but what's next? I think you can offer people more than just a free Slack. Do you have any plan to integrate it with commercial products?
If you are asking how they will pay their bills: They offer a hosted version.
If you are asking if commercial software will be available: it already was from the start; draw.io is not open source but could i tefrate right away anyway.
Unfortunately this isn't feasible. Sandstorm requires some modern Linux kernel features to set up its sandbox. Kernels before 3.13 simply did not have the features necessary, and there's no alternative approach we can use to get the same effect. Sorry. :(
* Oasis (managed hosting) was launched less than a year ago.
* That came together with a huge UI overhaul that introduced the sidebar / tabbed UI.
* It also came with the full app market, whereas before we only had a static HTML app list.
* We started offering free SSL certificates for self-hosted servers under sandcats.io.
* We introduced Sandstorm for Work, which integrates with LDAP / SAML (including Active Directory) for login, offers organizational user management features, etc.
* We added app signature verification via Keybase, proving that apps came from the twitter/github/HN user you expected.
* We implemented app update notifications with one-click updates.
* We added signature verification to the installation and update paths for Sandstorm itself.
* We enabled apps to serve WebDAV APIs, which enabled Davros (a file sync app) and Radicale (a CalDAV calendar app).
* The community wrote / packaged 30 new apps, bringing the total to 58.
* We added the ability to link multiple login services to a single account.
* We implemented the Powerbox grain picker, which allows you to share a grain through another app. (This will begin being used in real apps in the next couple weeks.)
* We added unified notifications and read/unread indicators, so you can keep track of activity across your grains.
I am using Sandstorm and I love it. Nothing beats the power of hosting your own private cloud. However, I really wish there was a way around the wildcard certificate requirement. One of these days I am going to shell out $100 for a wildcard cert or I can just hope Let's Encrypt will support it!
For the record, I wasn't thinking of Darude's Sandstorm when I named the project. :)
EDIT: What I was thinking, at the time, was "sandbox in the cloud". But these days I like to retcon the name to be about granularity. Sandstorm's major technological innovation is fine-grained containerization, which is described in detail here: https://sandstorm.io/how-it-works
Grains of sand in a cloud is a sandstorm. Storms and clouds coming in are both said by people a lot. Synonymous in some situations. Some talk about sandstorms. It's believable that the connection was made without knowing... whatever work you're referencing. Never heard of it.
Closest role might be architect. My team is 'technical strategy and incubation', looking for discontinuously better ways of doing things.
Your project has come up a few times, generally during debate about the practicality of capability based security.
Saw you post, checked your profile for email, pinged here to give you option to reach out.
// And yes, my profile mentions I'm hiring, as most of us should be. Per my comments or background or LinkedIn, you'll see I'm a founder / CTO not a recruiter.
It supports too many apps/frameworks - It's too ambitious and not focused enough. Also, not all apps are the same when it comes to scalability - That's a false assumption which pretty much of all PaaS providers make.
There is more to scaling an app than just adding more machines - Services need to be scaled independently of each other based on usage; also, some services should run on their own dedicated hosts, some services require persistent storage also there are needs to be rules to define how services can talk to each other, recover from failures, etc...
Developers NEED some way to specify HOW their services should scale - It can't just be fully 'automatic' - That's not flexible enough.
If you look at typical Kubernetes config files, they are quite long/complex; this is because there are a LOT of factors/variables involved when it comes to running services inside distributed containers and you can't just abstract away from those details without seriously compromising flexibility.
Sandstorm is not a PaaS and is not intended to be an alternative to Kubernetes. It is not designed for running SaaS services intended to scale to millions of users. It is designed for running personal or internal employee-facing services, where there are anywhere between 1 up to maybe 10,000 users. The kind of scaling you describe simply isn't an issue in this domain.
Moreover, Sandstorm takes a completely different approach to scalability called fine-grained containerization. The problems and solutions are really completely different from a Kubernetes-like approach. Read about it here:
Sandstorm is exciting to me for personal reasons. Scalability is not an issue there, because all my apps already need to run on only one computer.
Security and encryption is really important to me. Synchronization as well. Very excited about sandstorm because it seems to fix a lot of the gaps in my current flow.
It's solved half of the problem beautifully -- it's very easy, once setup, to launch any new app on your server.
The other half of the problem is moving of server/data. Right now, either you use their self hosted instance of sandstorm, or setup your own server. There's the hassle of keeping track of data/server. There's pseudo-centralization happening here, given the difficulty of changing compute or storage by a layperson.
However, if sandstorm had built in federated storage (either based on bittorrent filesystem or any other p2p storage), then I no longer worry about losing my data. I simply move my domain to a new "server-provider" or use the main project's own service, and then at a later date can spin up my own compute, or use another provider, and point them to my data on the p2p/federated storage.