...but yeah, now that let's encrypt does wildcards it'll be easier to do it on your own domain. I'd like to see sandstorm have some nice integration for this in the future.
(sandcats still works of course, and is still a good option to get started if you don't want to mess with DNS and certs right off the bat).
The (free) sandcats domain/service didn’t die with the paid service/business? I had just assumed it had.. if it’s still around and still free that’s very cool.
Yes, I have no plans to shutdown sandcats. I do have plans to rewrite the server side to use Let's Encrypt and Cloudflare Workers* in order to make it easier and cheaper to operate, but even with the current implementation it's no big deal to keep running.
It still exists, and there are no plans to get rid of it. Same with other community infrastructure, e.g. demo.sandstorm.io has been moved off of oasis and still runs as well. It's only oasis that's shut down.
Thumbsup for sandstorm - my conpany is extensivly using it with a small team and external clients.
For those who dont know what it is:
Single Sing On with an App Store. Better explained:
You create one account and then can create/edit/share/copy projects of completely unrelated software
. So lets say you create a gitlab installation, 3 etherpad projects, 5 wekan (trello clone) boards and then share them with your team/client/family by just adding their email adresses - awesome tool!
Sandstorm is also an extremely security-oriented way of running packaged apps. It uses an advanced sandbox that has defeated many kernel zero-day vulnerabilities. It utilizes the Cap'n Proto serialization + RPC protocol, another security-oriented project of Kenton.
Security is critical for a platform for self-hosted apps. One vulnerable or malicious app shouldn't be able to compromise your entire platform. Docker-based solutions don't provide this.
I imagine I've completely misunderstood it, but to me that sounds like pulling Docker images and running them on something like a Kubernetes cluster. The Docker images have to meet a contract, with a type of UI, authentication endpoints, etc.
I think the biggest cause of this is just how Sandstorm really wants you to use it for authorization, which means that authorization needs to be scoped at the app instance level. There are good reasons for this. However, for standalone use, app instances need broader scope than what you usually want for authorization.
If not for that mismatch, one could just wrap most existing apps that support pubcookie authentication in a layer that translates Sandstorm APIs into HTTP.
I hope we never stop trying to find a solution to what just _has_ to happen some day: everyone should have their own server.
If I make an app, I can safely assume that the user has a bank account, an e-mail address, etc. What would happen to the app economy if we could also assume that the user had a server? Imagine all the apps that would be made possible if the app makers didn't have to pay for and scale a back-end service!
Sandstorm.io, https://solidproject.org by Tim Berners-Lee, many people have tried, hopefully someone will succeed.
My parents can understand something like a physical box that sits next to their router.
They just need to start specializing rather than being a "jack of all trades, master of none." For example, being a best-in-class way to host a Matrix server. Become a best-in-class Google Photos alternative, etc.
I think it'd be really nice to offer Sandstorm in a pre-built box someday. I run Sandstorm on an Intel NUC which is a little overkill for the task, personally, but the form factor is pretty nice.
I think it's hard to sell people on a cloud box that can't do everything people want to do on the cloud. One missing app can (and sometimes does) make or break someone's interest in a platform.
Why does that "have" to happen? This is a genuine question, because as a user I'm fairly happy with SaaS services, especially when they're built on open protocols or have a good export (meaning I can switch easily).
Unfortunately, it's unlikely that we (at least in the US) will find the political will to change the law that says if you give your data to a third party, it is no longer protected by the fourth amendment and doesn't require a warrant to obtain.
So self-hosting your own data seems to be the only way you can keep your data protected by the fourth amendment.
Not everyone feels all their data needs that kind of protection though. And it doesn't really apply to some services, for example, everything I do on GitHub is already public anyway.
A good example would be things like a todolist app and other personal things. It would be nice to make an app like that without having to also scale an entire set of servers and just have the syncing etc be provided by the user of the app instead of by me.
Something like that could even be integrated into iCloud if it becomes popular. Then your "user provided server" would probably only work with other Apple products, Apple style. But for many users that would probably be good enough.
And you wouldn't be limited to having only one of these "user provided server thingies", either.
As someone working on something that i think is somehow related to both Sandstorm and Solid(at least in some of the key goals), i've turned into a distinct path.
The most reasonable thing to do, of course is something like Sandstorm did. You get the technological 'status quo' of the web and mix it into a self-sustained, autonomical node.
I think that when you need to have this level of autonomy, the design meant for the web doesnt solve this very well.
This is the reason why i think both Sandstorm and Solid didnt 'hit the nail' yet, because we need a couple more "iterations" to solve this in a more satisfying way, and it goes deep down into the architectural choices.
Having said that i think Sandstorm, Solid, DAT and IPFS have the right mindset, and the sort of meditation that are pointing us to a future.
The real danger here, is that the web on its own will get trapped by the mobile walled gardens of both Apple and Android were you dont have any choice of distribution or reach without saying yes to a digital overlord that can terminate your channel within the digital realm over any bogus reason presented.
And unfortunatelly our legislators are still not prepared to deal with our current digital citizenship and to make the proper stand on our civil rights.
Without a proper solution, we are heading to a dystopic digital feudalism, and this is one of the reasons why im also working hard to launch something that will at least try to make this dark looking future not so unavoidable.
(And thats why i have a utter respect for projects like Sandstorm and Solid)
I repeat; The web stands no change and will become a "channel" within a bigger internet ecosystem, and a symptom of this is the web being embedded as a app platform for mobile and in the near future desktop apps.
The web has a great future as a application platform, but this free, utopian world where we have a more free and descentralized way to share information is losing a lot of ground, and if we dont keep some great values the web stand for in new tech incarnations, we stand no chance to keep all this.
> If I make an app, I can safely assume that the user has a bank account
Sure, but that doesn't mean you assume that the user operates their own bank. They have some third party they trust to hold their money for them. There are risks to that, but in practice it turns out those risks are much less grave than the risks associated with everybody holding their life savings under their mattress.
This is why I've always been skeptical of the "everyone should have their own server" vision: servers require administration, administration requires technical skills that most people will never have, and even lots of those that do have them aren't necessarily skilled enough to be able to keep them reliable and secure. For all those people, having some professionals at a third party deal with that stuff will yield better results than DIY will. There are risks here too, but it'll probably be easier to mitigate them via regulation than it would be to teach everyone in the world to speak Unix.
(The one way out of this trap would be if we could come up with some kind of server that did not require administration -- that had guaranteed 100% uptime, that never required security updates, that scaled automatically to meet any level of demand, that didn't have physical parts that wear out over time, etc. It's telling that the closest thing we have to that today is less a server and more something like AWS, which... requires trusting a third party.)
The key thing is the user has somewhere they can actually run your app; it doesn't necessarily have to be their own box, it could be one provided by a friend or a hosting provider. That said:
> The one way out of this trap would be if we could come up with some kind of server that did not require administration
To a large extent this is actually a goal of sandstorm.
I'd contest some of your requirements though: /Nobody/ has 100% uptime, even AWS. And most individuals are not in a position where an outage is going to cost them millions. It might suck, but people trudge through worse problems with their PCs; no reason a personal server ought to be different. So I think the bar is a bit lower than you suggest; I think it's possible to get a server to the point where it can be "administered" by someone who's capable of "administering" a laptop.
We're obviously not there yet; you still need to set up a Linux box before installing Sandstorm itself, and we don't really have a great Story wrt backups yet. But Sandstorm itself is already mostly fire-and-forget; it auto-updates itself, our security track record is rock solid, and I can't remember the last time I had to do anything that felt like sysadmin work for my Sandstorm box. There are a couple things I think still need to happen:
1. We need an automatic backups & recovery story.
2. We can't require the user to install Linux first; we'd need a "sandstorm distro" so folks can do the whole business together. The OS should be hardened by default and self-update with Sandstorm, as well as integrate with the admin panel for scheduling reboots.
3. Ideally, there'd be hardware you could buy that's just already running the sandstorm distro.
Good point! This is why the e-mail analogy works. You _can_ host your own e-mail, and nobody has to know that you do, you can just do it. But most people settle for a 3rd party.
It should be the same with whatever someone comes up to as a "bring your own server" solution imo. I'm completely fine with having to do more manual work to set up my own box at home or something like that. Maybe I'll install it on Azure or AWS instead. Or just source it out completely. Would be nice to at least have the option :)
I think the key is to fully commoditize the maintenance, largely by ensuring that users' server state (documents, photos, server app config, the works) is portable between commercial providers and DIY servers. Even better if you can maintain highly available copies on multiple providers.
I worked in that space for a while but I came to the conclusion that pretty much no one wants to run/manage their own servers. Outside of a small number of privacy-centric hackers, the benefit just isn't worth the hassle.
That argument held for many technologies in the past. e.g. to figure out your location, you had to be able to operate sextant. In the early days of the automobile you had to have considerable mechanical skills to keep one running. Cameras required special skills. And not very long ago, you needed quite a bit of skill to run a computer. Now almost everyone carries a computer in their pocket, which conveniently doubles as camera and sextant and more.
A server is also a mashup of functionality. I can’t see any reason why it cannot be made as easy as a smartphone sometime not too long from now. And making things easy and inexpensive enough can also create a market, even if there didn’t appear to be one.
I guess that for most apps a Raspberry 0 or something similiar would be sufficient and to make it easier on the consumer side it could be built-in into the wifi-router[0] to avoid the necessity of having additional device.
On the other hand another approach would be to use more client-side processing[1] in the existing environment. This would not completely remove the need for the server on app maker side, but could possibly offer a significant reduction of the resources needed.
The third approach could be to change the billing model only, where processing would be done on a (very small and short term) cloud instance run by the mobile operator and the customer being billed for usage of that. In other words have computation-as-a-service as a part of mobile operator service. This would also have quite complicated privacy implications.
[0] And if the router-route would be taken, it would make things much cheaper since the routers CPU could be used. Even if additional cores would be required this is still much cheaper than having a separate server-device. Also much better energy-wise since for most of the time the server cores could be off/stand-by and a small process on router-cores would wake them up only if needed.
[1]Given how diverse client-devices are it's not that easy to have client side processing on all platforms. I wonder if WASM will make client-side processing more common.
You still have to make the back-end service, no matter where it runs. That's the expensive part. The cost of servers is always a rounding error in the budget everywhere I've worked compared to the cost of human labor to program them.
I was just about to mention them. Urbit is one of those technologies I sincerely hope takes off, they've got one of those "just-crazy-enough-to-work" ideas if the rough edges can be polished.
I loved sandstorm and used it extensively a few years ago; it was amazing to single-click install instances of apps like; "Wekan", "Dokuwiki", "Wordpress".
The reason I stopped using it was development... It was amazingly hard and confusing to develop a "hello world" application for Sandstorm.
Sandstorm had a great GUI and workflow for users, but it seemed like new developers on the platform were ignored... which reduced the growth of the platform and eventually killing it
Glad to see it's being revived though and maybe I'm smart enough to make my own Sandstorm-Compatible app now!
We are definitely very interested in improving app development and new contributor onboarding with Sandstorm. If you do revisit it and hit difficulties, please reach out on IRC or the mailing list!
I just installed it. I've been wanting to play with Sandstorm for a while for two reasons: 1) seemed like a lot of people were excited about it and 2) I could not figure out what it was.
Regarding 2) I wondered: was this the "new heroku." Or, better than zeit? Or better than docker?
I still don't know.
After installing it, I went to the marketplace and looked at the set of apps. Looks like there is button to quickly install piwik (alternative to Google Analytics). It worked really well. There is a spreadsheet app. A git server.
But, I can do basically the same thing by going to the marketplace in Google Cloud Compute and choosing GitLab, or Wordpress, or whatever.
Sandstorm looks ugly. I know that does not mean it is better or worse, but GCE certainly looks more professional when I install one of their marketplace apps.
So, what am I missing about Sandstorm? If I choose apps like GitLab or Wordpress where there is a documented and easy way to migrate my data so that I can easily move off GCE and over to another provider. Then I feel that my lock-in risk is mitigated, but is there something else that Sandstorm gives me here that I'm missing?
> But, I can do basically the same thing ... what am I missing about Sandstorm?
The big difference, in my mind, is that each app is integrated with a permissions/capabilities model and strongly sandboxed by individual instance or document. Sandstorm itself handles logins, and handles capabilities to access documents; then e.g. there's no way that Etherpad can accidentally leak your doc to someone else unless you've granted a Sandstorm-level permission to that person.
It sort of flips from the "walled-garden app" model, where the app is the boundary and individual docs and users are within the app, to the traditional "computer with filesystem" model, where the user login and the file with permissions are system-level concepts. (Except instead of "file", they call it a grain, and it's a separate instance of Etherpad or Gogs or whatever.) That's also what makes this more than just Docker containers -- deeper integration into the app.
That also gives you flexibility to have a bunch of different instances of a single app, and IIRC, they have functionality to import/export those instances in a well-defined format from one host to another.
At least, that's what I remember from playing with it 4 years ago. In any case, I got the impression that the model was much more secure, and flexible, than just "install Gogs on vanilla Linux".
This is such a great comment. Tying together all the different login systems and making it work with a bunch of different systems behind those authentication systems is such a pain in the ass. Maybe Sandstorm tried to promote that as the key benefit at some point and it didn't resonate, but their site right now says "Sandstorm is an open source platform for self-hosting web apps" which does not differentiate it at all.
If I knew that I could create a private walled garden with a bunch of disparate apps that are all connected, that I would have been excited about. That's hard work they did, and it is a shame they don't promote that up front. I'm confused who they think they are talking to, since "open source apps" would only appeal to developer/sys-admin people anyway.
I suppose I don't know what self-hosting means. Does that mean NOT GCE, so DigitalOcean or Linode? Or, running my own server? Aren't those just all VMs in the end?
If I look at Cloudtron, I see Gogs (git), Wordpress, GitLab. etc. If I go to GCE marketplace, I see those same things. Both of these sites have a button where I can install those apps easily.
What does the addition of "self-hosting" mean for me?
I run Sandstorm on a desktop tower in my office. If the network goes down I can still access it, which is surprisingly handy. If I wanted to, I could run it on my local workstation and not use a server at all.
For most people, paying for a VPS is the easier and cheaper route maybe, but for some of us, that flexibility and total ownership is a much better option. I suppose it mostly boils down to who you trust more: Google Cloud, or your own skills. (and time/patience)
Adding to my own comment: self hosting also means that you can install the software on your own premises if you wish to. Or on some VM you rent at any VM provider.
That's always a fair point, but you can at very least pick your poison (hosting provider), and it's very portable to switch between them. Or if you want to, set it up on your own physical machine. I don't know enough about network security to run a publicly facing server from home, and I don't think I'll take the time to learn it any time soon. However, I may well end up running it at home at some point soon in a way that's only accessible from home, for truly private things like contacts. A nice in-between could be a community center intranet. (Though setting up auth within an intranet isn't easy yet)
To your point, I'd be curious if the data selling/using policies of Linode vs Google Cloud are different.
I went to Cloudron for my selfhosted needs. It works great. But years before I was using Sandstorm, and it was always rock solid. Would love to come back to Sandstorm in the future!
It would be very important to describe and make it much easier for the community to ship self hosted Sandstorm packages.
If the failure of Sandstorm has shown one thing, it's that people will not maintain forks of software if the layer you're integrating with is too complex.
I'd much prefer if Sandstorm just shipped with an IdP and contributed OIDC implementations to downstream projects.
We've definitely had varying levels of success with this. Sometimes an app has a switch or two for being on Sandstorm and a .sandstorm directory in their repo, and you can more or less "vagrant-spk pack" it and it's good to go. One of the things we're interested in with vagrant-spk updates is ensuring the flow to update old apps is a lot smoother.
Others have a fair bit more difficulty, but I think it comes down to market share: If a lot of their users are on Sandstorm, they're going to care about maintaining a Sandstorm package. If the Sandstorm project isn't as widely used, people aren't going to be that excited to do all the extra work for packaging.
Wekan has Sandstorm packages as part of the release pipeline: Every single release is submitted to the Sandstorm app market, actually. But Wekan is both considered a core app for Sandstorm, and has been available on Sandstorm since it's very early days as a project, so the group of users using Wekan on Sandstorm has always been pretty healthy.
I know exactly one non-cannonical project that maintains a reliable out of the box experience for snaps, Nextcloud. And that's because they use and package it themselves.
Yet I'm never quite sure if I'm about to shoot myself in the foot installing any other snap.
Same with Sandstorm. When I ran Mattermost for a bit I was initially shocked how seamless and fast it worked, followed by immediate disappointment that apparently just a handful of versions had been patched and it was lots of major versions behind by now.
That's sounds more like "here are a bunch of new features coming soon" rather than reviving the project.
Will anything significantly change in contribution activity going forward? Are there again some people working full-time on Sandstorm, which is realistically necessary for a project of this size? The announcement doesn't say anything about that.
There's some talk of trying to figure out funding stuff, though none of it is super organized yet. I personally set up a GitHub sponsors profile and a couple folks are donating. I could see us getting organized enough to scrounge up money for at least one person but we'll see.
But, even without that, I do think there's a reason to be hopeful that this is more than a momentary stir. The company shut down so suddenly and without really on-boarding new contributors, and I think much of the problem was that of getting over the hump of "all of the people who've worked heavily on this codebase disappeared at once." I think it might not have stalled in the first place if there were a couple folks outside the company who had been doing regular work on the platform. I still feel like our bus factor is a little low wrt to hacking on core, but I'm hopeful that we can get to a point where there's enough shared knowledge that we won't end up in quite that kind of slump again.
It would be cool to use Sandstorm to host public-facing apps, so content could be browsed without logging in. For example, hosting a public discussion, chat, or wiki with the simplicity of Sandstorm. From what I recall though, Sandstorm security sandboxing makes it difficult/impossible for Sandstorm hosted apps to be visible to the general public. Has this changed? Is my recollection incorrect?
You are not incorrect, and that's definitely something we've talked about addressing, because it's a common request. We have a workable flow for publishing static web pages from Sandstorm, but even that requires manually configuring DNS entries somewhere. We've talked a bit about what would be required to get a dynamic grain available at a well-known subdomain.
There's obviously some security cost to doing that, but it's a cost most people would accept in the context of a grain they want to make easily findable to the public.
I should add/clarify that if you're talking about dynamic grains (active discussions, wikis, etc, as opposed to mere statically published sites), it is also already possible to share those publicly. They're just at weird looking URLs. Hence the interest in a "well-known subdomain" feature to improve that.
I have a self hosting project ready in the wings but I don't know how to make it self sustaining or useful (economically to me as I am poor as it is) if I made the source public. It is also not clear to me how to sell it as a closed source application. Please have a look here: https://wharfie.org/
The main thing you have to figure out, especially if you want to make money on it, is what it offers that existing solutions don’t. A lot of self hosting options exist, and many of them are free and open source.
So why would someone pay for your project? Even a very novel solution like Sandstorm, which six years later has no real equal in the security department, struggled with convincing people to pay for it.
I just want to say thank you to everyone who's worked on this. I've been a believer since the crowdfunding campaign, and a user since Oasis came to be (RIP).
While there are some warts, and development has been slow for a while, the project is fundamentally sound and still quite useful.
The thing that always killed it for me was the utterly bizarre arbitrary federated login requirement in an otherwise self hosted system. It meant it was impossible to use on an intranet, not to mention defeating the self hosted purpose.
Besides avoiding having to manage its own authentication system, one important future direction is federation. So ensuring you can associate accounts as being ‘the same person’ on multiple servers is a significant boon for the future.
As a community, many of our conversations and notes are spread across five or six servers in different people’s control. We’d like a better experience for that long term.
Email login is pretty good now though if you don’t want to deal with Google or GitHub, and now that LDAP and SAML is available for free, intranet is pretty doable with standard conventions known to most IT departments.
Cloudron.io's approach seems far more easier for developers to adopt. Every webapp runs in a Docker container and auth/user management is delegated to a single-sign-on service. But it's not open-source.
In fairness, this did come a bit later; it was there for quite a while before the company shut down, but when I first showed up I had a similar wtf reaction since at the time it was just GitHub and Google. But yeah, that was fixed a very long time ago.
It’s not clear to me the extent to which developers should assume people will be coming from HN and have some background on their project for the uninitiated. This post is almost perfectly devoid of any hooks that might give people a hint of what it is, but on the other hand, for a “not dead yet” post, probably the people who will be most excited do in fact know what it is.
Given that this article does not exist alone, but rather within the context of the broader website, readily available by means of the ever-present header with links, I believe it is safe to assume that any reasonably intelligent but unknowing user can do the research on their own.
Additionally, as long as the question "WTF IS THIS??" is not forbidden in the HN comments, even those lacking the domain knowledge, or a sufficiently useful description on the site itself or a useful Wikipedia page, I think the extent to assume is fairly low.
That is, I think it's safe to assume the internet, and its users, exist, and that the reader is sufficiently intelligent to make use of the resources available to them, when writing a post to publish online, if it's not intentionally an introductory post
It's the infrastructure for self-hosting web apps. So, on top of Sandstorm, you could get a Dropbox-like app, or a Google Docs-like app, or a Flickr-style app, hosted on a box that's in your living room or on your own server in a colo. So instead of uploading your photos to Flickr and sending Flickr links to your family, you would upload your photos to PicShare.StevesHomeComputer.com and send those links to your family, keeping all of your data in your control and not subject to Flickr shutting down one day.
It makes sense for some services that are fundamentally user-fragmented (File backup/Evernote/Flickr) but less sense for things that require multiple users to be credentialed like social networking, since social networking structurally benefits from everyone being on the same service.
Right now it's just Free Software that you install on your own server. Any pricing involved (for normal users) had only ever been a high storage space account on Oasis, a sort of example server that was run by Kenton, the original creator of Sandstorm. However Oasis is basically shut down now, because really the whole point is self-hosting anyway. (I say "for normal users" only because there was once a business plan involving potentially getting companies to pay for premium services, iirc)
Nowadays it's a community project, still getting security updates from Kenton. Spinning out some sort of non-profit funding situation, probably unaffiliated with the initial company, is plausible. Right now it's all speculative though, which is why you won't see anything about it on the site.
At a brief glance, this appears to be a coin-based / blockchain-dweb app ecosystem. Which is absolutely massively different, though a relative handful use-cases overlap (and blockchain apps do indeed cover some of those quite nicely).
I don’t see a purpose to this in an era of Docker. They say their mission is to make it easy to host your own web apps, and provide some security around those apps, but Docker makes this easy as well and also provides a small amount of insulation around containers.
I have spend at least 15 hours trying to self host things with docker with little success. Its not nearly as easy as people make it sound. You don't just "docker run ..." and away you go. You have to spend ages reading the manual for each app, creating configuration files for the app you want to host and then mounting them in to the container, then you have to set up a database, reverse proxy, certificate renewal, and then you have to network it all together.
And then half of the time the docker containers you need aren't built for ARM so your RPI home server cant run it without building it all yourself or finding an alternative container that is built. And then docker has no built in update mechanism so you have to constantly manually check that nothing you are using has any updates.
The only time docker actually is simple is when you use one of the "all in one" containers that has everything you need but then it binds to port 80 and 443 and now thats the only app you can run.
Docker could be used in combination with a sandstorm style tool. The real value in Sandstorm was meant to be that you didn't have to configure everything, you just press "install" and it would be all done for you and kept up to date.
I can heartily recommend you something called Dokku, which more or less takes all the pain out of Docker. I had no experience with this, but got fed up of spiraling Heroku costs. Decided to slap Dokku on a €2.50 pcm VPS, runs like a charm. Multiple containers all communicating with one another, staging, production, failover environments, shared storage, all behind multiple SSL-secured domains.
Dokku is single-server only, however. So if you need a Docker swarm, you'll have to do that yourself :)
Dokku is great for deploying web services using Docker on a single server, especially if you are familiar with Heroku buildpacks/services and prefer to do everything in the terminal.
Another option is CapRover, which is also free and open source. CapRover is a simple interface for Docker Swarm, Nginx, and Let's Encrypt that is designed for deploying web services. It optionally supports scaling web apps across multiple servers, and also includes a web interface which can be used in place of its CLI, if you prefer to manage the system in the browser.
> I have spend at least 15 hours trying to self host things with docker
That only says you haven't spent enough time. Say, 15 hours would be just enough to understand postgres container and figure out the best working configuration for you. Apps on top of it? Good luck spending extra 30 hours.
The thing is docker has never claimed that you don't need to learn about the software you're gonna run. It simplifies only deployment (a.k.a. installing and executing binaries) by providing uniform environment, and by making configuration files more reproducible, but it never reduced the complexity of software configuration.
But that doesn't mean Docker isn't a viable option for simplified server-application deployment. All we need is a set of well maintained recipes. It's just that there are too many recipes out there, unreviewed, untested, unmaintained. If one central party takes the responsibility here, Docker (or any other container solution) can outshoot Sandstrom in no time in terms of both quality and quantity.
I'm afraid you're missing the people Sandstorm is targeted at. People who do want a server, and a variety of services on that server, and the ability to move the server to a hoster or local metal, but have no desire, and thanks to Sandstorm no need, to acquire the skills you are referring to. People for which a server is in support of their workflows, not a goal in itself.
You're right, a Dockerized alternative might be as good or better. But until such a platform exists (I do not count Cloudron because it's closed source now), it is not viable for the people Sandstorm is targeting.
> I have spend at least 15 hours trying to self host things with docker with little success ... reading the manual for each app, creating configuration files for the app you want to host and then mounting them in to the container, then you have to set up a database, reverse proxy, certificate renewal, and then you have to network it all together
Being with 0 experience with Docker and only with bare Linux experience, I'v set myself to set up nextcloud + mysql + nginx-proxy (with some custom config) + letsencrypt via docker containers on arm platform.
Learning docker basics, some docker-compose, I'v got that set up in a few evenings, maybe some 6 to 10 hours total (including first time experience of setting up raspberry pi with external storage). nginx-proxy being hardest part for me, as perfect image that fits arm platform was made available just after fair amount of searching and trying to understand what it takes to make it compatible with arm.
After all, I was really pleased with what I felt how much docker saved time for me. Maybe not really fast, but some productive full working day that is. I'v learned something about a new technology that gave me nice preconfigured webserver with hardened TLS settings etc. I thought, if I'd have to go down the route of manually installing this dependency, configuring this and that, etc - uh, that would surely have taken me longer.
The other side being a joy was - hey, I can host this all on a single raspberrypi, the frontend is isolated from backend and I can still add stuff behind nginx-proxy (and it will be isolated from nextcloud frontend), as my RAM usage is somwhere around 512MB.
Just wanted to share how I feel about Docker when putting my hands on it (single host, swarmless scenario)
Docker is great compared to pre-docker times but it does not go as far as Sandstorm.
If your widget takes 6 steps, and another otherwise equal one takes 1 step, then whether that widget is for users or developers, the choice is a no-brainer.
As a product it was a disaster. What I would do if I was going to turn it into a company:
1) temporarily decrease the # of supported apps.
2) new custom react UI
3) call it project headless. try to discard a ton of code. keep the schemas, fork the services, grpc/capnproto them etc, tear out the good bits of the server sides of these apps. If an app has nothing special in it - discard it.
We all know in the long run this would be the least labor intensive way to execute a project like this. I bet you'd get a huge amount of contributions flowing in too.
The community members working on it right now are focused on improving the capabilities of Sandstorm for fellow self-hosting enthusiasts like ourselves. We’re not building a company, so our priorities are a little different.
Yes. It's particularly reasonable to assume that readers are minimally aware of what they're reading on a "reviving a dead project" blog post IMO - why would you assume readers have no idea what's being revived? Why would they even be there?
More generally, it's a project-specific news section, it doesn't need to introduce itself in literally every post - check the site instead.
> Sandstorm enables non-technical end users to install and run arbitrary software on servers they control. Apps may be downloaded from an app store and installed with one click, like installing apps on your phone. Each app runs in a secure sandbox, where it cannot interfere with other apps without permission.
Concerning the presentation of this article, rather than its contents:
Source Sans Pro 300 is too thin for body text on most platforms. It’s tolerable on Apple platforms with high-DPI displays due to their stroke thickening (where they essentially ignore the font author and do their own thing, though you could also argue that it’s just a form of gamma control), but on other platforms like Windows it’s much too thin, to the point that on many low-DPI monitors it’s genuinely painful to read.
Be very careful in general when using light font weights for body text. 400 is a much safer option.
Now Letsencrypt support free wildcards so perhaps it'll be easier for Sandstorm to get momentum.
Sandstorm uses a new hostname for every session https://docs.sandstorm.io/en/latest/administering/wildcard/#...