[HN Gopher] Sandstorm: Open-source platform for self-hosting web...
___________________________________________________________________
Sandstorm: Open-source platform for self-hosting web apps
Author : srgpqt
Score : 405 points
Date : 2023-06-05 05:41 UTC (17 hours ago)
(HTM) web link (sandstorm.io)
(TXT) w3m dump (sandstorm.io)
| evolve2k wrote:
| What's involved to get additional open source "apps" into the
| store?
|
| I was considering Mattermost over Rocket Chat, but it's not
| currently supported/listed.
| zenhack wrote:
| Have a look at the packaging tutorial:
| https://docs.sandstorm.io/en/latest/vagrant-spk/packaging-tu...
| gitgud wrote:
| Happy to see this project still going. Loved the concept and
| tried it for a while, but building apps for it was very
| complicated at the time, which made it much less useful. Looking
| forward to giving it another shot.
| ocdtrekkie wrote:
| Probably the biggest revolution in app packaging is there is
| now a tool that helps automate enabling an app to request
| outside network resources. It used to require you write some
| Cap'n Proto and all, now you just need to include powerbox-
| http-proxy in your app package, more or less.
| srgpqt wrote:
| This project seems like just the thing to kickstart a new era of
| decentralization/federation for the social web, an answer to
| Reddit/Twitter/etc.
| cpa wrote:
| I've tried sandstorm and yunohost but those didn't make me
| confortable enough to use in a production setting. I've been
| using cloudron.io for a few years and it's great. Never had
| issues with data loss or updates.
| smartbit wrote:
| 12*15=$180/year/person for cloudron.io is not the cheapest.
|
| Have you considered or tried nextcloud?
| cpa wrote:
| I'm also using apps such as grafana, prometheus, gitlab... So
| nextcloud by itself wouldn't cut it. I'm willing to pay (it's
| $15/mo per server, not per user) because I want something
| reliable that I won't have to spend a lot of time on. And
| also because we're a company, not just a random enthusiast :)
| mawise wrote:
| On the other side of things, I've started using
| https://www.pikapods.com/ they follow the docker model but are a
| paid (~$2/mo) hosting provider focusing on open-source self-
| hostable apps. Seems to me like an easier path for getting non-
| techies to 'selfhost' their own apps.
| ssddanbrown wrote:
| Pikapods have provided my software for a while. Have not had
| much feedback from users yet, but no bad feedback is a good
| sign I guess. The person behind PikaPods was very receptive to
| my concerns that their website mentioning of "upstream revenue
| share" could be misleading (didn't apply for my project), and
| they quickly took action to improve things.
| xorcist wrote:
| I have used Sandstorm quite a bit in the past for smaller
| clients. It's remarkably sane and works as described. Sometimes
| it could be a little slow with getting updates, but I don't know
| if that's still a thing.
|
| The space of Linux distros specifically for self-hosting data has
| always been a little fragmented, which is a shame since it's
| really useful for the intended audience. A bit like Linux distros
| in general, perhaps.
|
| Maybe if one of the bigger distributions, like Debian or Fedora,
| got behind one system it would improve. But that's also how we
| ended up with Flatpak and Snap, so it could be either way really.
| johackim wrote:
| There is an alternative : https://github.com/ethibox/ethibox
| mcint wrote:
| It's worth mentioning https://YUNoHost.org.
|
| I've done plenty of manual self-hosting. I explored sandstorm for
| a year or two in the mid 2010s. It worked as promised, but the
| complexity of integrations, fraying, showed.
|
| I switched to yunohost 6 years ago. I almost entirely don't think
| about it. I use a few services, wallabag and Uptime Kuma. Tried
| Nextcloud, HedgeDoc /HackMD/CodiMD, and Monica PRM because it was
| so painless to give them a go.
|
| My initial motivation for exploring it, came from the hope it
| could install NextCloud. My attempts at installing OpenCloud and
| NextCloud, with scripts that would make non-idempotent changes
| that fail on a second run after first pass fixes, left me sensing
| an unfriendly forced upsell environment.
|
| I have had to do some manual fixing to complete an upgrade or
| two, but it has workflows for backups, and some stringent, but
| fully automated configuration, sanity checking. I don't worry
| about the complexity.
| ocdtrekkie wrote:
| My understanding is YunoHost makes absolutely no attempt to
| isolate apps from one another, it just helps you install stuff
| on a Linux box. Unfortunately that means a single flaw in a
| single app compromises your entire server.
| Gigachad wrote:
| It's was designed predocker and is a pretty old school setup.
| I remember they had issues updating Debian because the new
| Debian had a new php version which caused issues for some
| apps.
| navanchauhan wrote:
| Some effort has been put into adding systemd hardening per
| unit basis.
|
| Every app is run by a special user created to do just that.
| This app user only has permissions for the app and data
| folder.
|
| (I don't have much security/hardening experience)
| rapnie wrote:
| Yes, Yunohost makes installs very easy. But if something
| isn't working right then you got extra layers to deal with. I
| don't know how Sandstorm deals with this, but Yunohost taking
| care of the install and upgrade procedures means that you are
| bound to the Yunohost integration's version of the software.
| For instance when installing Discourse via Yunohost this
| version lags behind significantly. And also Yunohost disables
| the Discourse upgrade process, while it offers a superior
| experience.
| cycomanic wrote:
| I tried out Yunohost and I do like it in principle, however
| what really started to annoy me was that they decided to roll
| their own sso, and my impression is that it's not very good
| (there are some threads on the forum criticising it for being
| quite a mess IIRC). The issue is that because of this it
| doesn't always play ball with apps which allow for SSO
| functionality, e.g. the seafile desktop app does not work with
| yunohosts SSO. I wish they would just switch to an established
| system like authentik, authelia or keycloak. There were some
| issues about this in the tracker but I think the suggestions
| were shut down pretty quickly.
| madacol wrote:
| For me, the biggest blocker for using Sandstorm has been the
| inability to run on ARM https://github.com/sandstorm-
| io/sandstorm/issues/2083
| hgsgm wrote:
| Sandstorm's value prop is such that if you wanted its benefits,
| a one time purchase of a low end micro PC shouldn't be the
| blocker.
| neets wrote:
| It's worth mention umbrel, https://umbrel.com/
|
| Once umbrel is setup apps are are just as easy to update and
| install as an iPhone. I also appreciate how it has a dependency
| system so apps can build on one another. Umbrel is more for
| personal homelab rather than sharing with friends, there is no
| public endpoint you would want on the clearnet, you need to VPN
| in, but that also makes it more secure.
| scooke wrote:
| I use several of these options (cloudron, caprover, easypanel,
| yunohost) because one of them has an app that the others don't.
| Umbrel has let me get a Nostr account and relay up and running,
| for example.
| ssddanbrown wrote:
| Just keep in mind that Umbrel itself is not open source, since
| they prevent commercial use/distribution.
| jesterson wrote:
| Is it something operational or it's all on pre-order?
|
| Fancy website hints on prevalence of form over substance,
| although perhaps it's just me. People who are concerned about
| privacy and big corporations don't need fancy rotating boxes,
| rather clear and concise explanation of the matter.
|
| Just my 2 cents
| garganzol wrote:
| I installed Umbrel on a VM. It demonstrates a few interesting
| ideas, but at the same time a form over function is
| everywhere with nothing fundamental to compensate for that.
| So you are kind of right.
| sverhagen wrote:
| That website is a very impressive piece of work, but it's also
| massive friction, if I may say so. "Get up and running in 30
| seconds." Pf... can't even get to what they're "selling" in
| that time. Scroll, scroll, more scroll. A nice, to the point
| pitch would be nice. Same for Yuno, which people are touting in
| other threads here, no one seems to be getting to the point
| "any time soon" on these pages. Sandstorm is probably the best
| of the bunch at that, but even there I didn't quite get it
| until I came to the discussion here on HN.
| anderspitman wrote:
| I have to agree, the scrolljacking on this site is beautiful
| and horrific.
| nunobrito wrote:
| Umbrel is OK. Worked good for me, indeed is relatively easy
| and a huge amount of apps for install. Mostly related to
| bitcoin.
| brynjolf wrote:
| It is hard trying it figure out what path to choose.
|
| Do you just run Docker or do you combine it with Docker Compose?
|
| Do you instead opt for Proxmox in combination with Podman?
|
| Maybe you opt for something simpler like this tool; Sandstorm.
|
| Or even more complex of a setup with a K8 cluster with combined
| with Gitops.
|
| It is interesting and a lot of really good tools to chose from
| but it is not obvious to me.
| electroagenda wrote:
| Sorry for the silly question but I don't get it.
|
| Is this a remote server where you can install and use web apps
| from third parties?
|
| Or can you actually build a web app there so that users can
| employ it? Something similar to Digital Ocean.
| orblivion wrote:
| It's a platform that you install on your own server, at home or
| on a VPS (Digital Ocean, etc).
|
| The installation is a few simple CLI steps. From there
| everything is in the browser, including the admin. Each user,
| once logged in, can install whatever apps they want from the
| app store. Or they can upload their own if they want. This is
| safe because everything is containerized. Apps have to be
| specially designed (or retrofitted) for Sandstorm, though.
| retrocryptid wrote:
| So... this is a company that sells a service that lets you run an
| app on 127.0.0.1?
| davidy123 wrote:
| I saw "semantic model" and got excited, but that's at the "grain"
| level.
|
| The idea of applications has been stale for a long time, it just
| takes a long time for people to get there.
|
| Microsoft doesn't want it to happen quickly because they like
| selling Office as a package, but they're slowing decomposing it.
| OLE was a micro step, now with a cloud graph model and AI they're
| going much deeper.
|
| Ultimately, your "table" can be generated from data in a
| "spreadsheet" or "database." And your AI can interact with this
| data precisely. At a certain level, you really shouldn't need to
| care where something was generated or viewed. It's data. But the
| more strongly it's "typed," the more accurate everything becomes.
|
| Yes there's some hype over AI, but it is just incredibly useful,
| even the most basic and stumbling step of importing your
| documentation to an app or browser based AI to answer questions.
| Anything that doesn't include it as a first class consideration
| is last epoch, in the same category as Visicalc, 1979.
| Unfortunately, that includes the vast majority of Open Source.
| KDE was way ahead of this, but they stumbled. I hope they can
| catch up. Local, Open Source AI needs to leap ahead or computing
| is going to collapse.
|
| So the first step is to give all the data a schema, ideally a
| domain-relative one so it's interoperable. See Linked Data.
| RonnieOwnsLexus wrote:
| so essentially if i have a VM, i can just install the apps i
| require and then use them for my business. This sounds great but
| then I need to make sure i am monitoring and debugging it if
| something breaks ?
|
| Also how does sandstorm makes money then ?
| rapnie wrote:
| > Also how does sandstorm makes money then ?
|
| It doesn't. It is an open source project. Originally Sandstorm
| was offered by a startup, but they stopped [0] in 2017. You can
| make donations though [1].
|
| [0] https://sandstorm.io/news/2017-02-06-sandstorm-returning-
| to-...
|
| [1] https://sandstorm.io/news/2021-06-17-sandstorm-community-
| fun...
| haolez wrote:
| Suppose I'm willing to build an ecosystem of internal tools for
| my company. Can Sandstorm make my life easier in this kind of
| effort? Or is the added complexity simply not worth it? I'm
| curious about how I'd deal with data sharing in my enterprise if
| each user has a set of data "grains".
| antifa wrote:
| I've had pretty good experiences with https://yacht.sh/, which
| only does docker containers.
| monkeydust wrote:
| Looks like Caprover https://github.com/caprover/caprover which
| has been around for a bit, have used in past. Any notable
| benefits over it?
| hgsgm wrote:
| Fromctheb readme, Caprover is developers developers developers
| developers.
|
| Sandstorm is for users/admins to deploy many apps together.
| asim wrote:
| When an idea like this strikes but doesn't take off there's
| definitely an element of "before it's time" but it's also really
| hard to get people to adopt opinionated development models unless
| it's part of a bigger language ecosystem or brand which can offer
| the scale of opportunity like an app store.
|
| There's been attempts to do this without the opinions e.g deploy
| docker containers but the reality is we do actually need a
| cohesive vision for the end user for anything like this to take
| off. Catering to the developers alone in the self hosted model is
| very hard. And I know Kenton tried hosting too. It's just a tough
| business all around.
| negative_zero wrote:
| Super cool idea but sadly seems to have been slowly dying over
| the last few years :( (unless something has changed recently?)
| zenhack wrote:
| The biggest change lately is probably:
| https://zenhack.net/2023/01/06/introducing-tempest.html
|
| But yeah, Sandstorm has been in a state of "not dead but not
| moving fast" basically since the company went under; things
| picked up a bit in 2020, and I got oriented-enough on the
| codebase during that time to keep it floating along, but, per
| the post, it's never been easy going.
|
| Anyway, I wish I were answering this question in 6 months time,
| when I'll be able to show off a variation of Tempest that is
| relatively usable and can do a few tricks that Sandstorm can't.
| yoz wrote:
| Just spent ten minutes delightedly reading your updates on
| this. It looks fantastic! I'm really excited to watch what
| happens next, and wish I had time to contribute.
|
| Are there primary areas in which contributions would be most
| valuable, especially from those without Golang
| experience/skills?
| zenhack wrote:
| I suppose that depends on what your skill set _is._
|
| At some point the project would greatly benefit from some
| attention from a UI/UX specialist -- I'm doing my best, but
| it's not what I'm an expert at. Though right now I'm mostly
| focused on getting enough stuff to work for it to be of
| interest, and someone fussing with the UI might just be
| distracting.
|
| Doing app packaging for Sandstorm might be the most
| accessible way to help for someone who's not a Go dev --
| Tempest will of course benefit from more apps when it's
| ready to run them, and it'd be a high impact thing for the
| community _right now._
| negative_zero wrote:
| I've book marked Tempest :) Looks promising. Wish you luck!
| tudorw wrote:
| always interested in self hosted solutions, not tried
| sandstorm and up for giving it a go, however if I was
| starting a small fairly simple personal project with no need
| to scale can I get wheels on it with Tempest, or should I
| consider building on sandstorm then porting?
| ocdtrekkie wrote:
| All of the dev tools use Sandstorm, and Tempest is not at
| this point, "complete". But if you were to build something
| on Sandstorm today, you can be reasonably confident it will
| work with Tempest.
| rapnie wrote:
| Tempest [0] looks very interesting. What is the current state
| of the project?
|
| [0] https://github.com/zenhack/tempest
| ocdtrekkie wrote:
| Currently Tempest can run a lot of Sandstorm apps. However,
| a lot of functionality one would expect or need is not
| implemented yet. It will be a bit before it can replace a
| Sandstorm server. But it's architecturally different in
| some fundamental ways which will make implementing new
| features that Sandstorm never had much easier.
| kev_emu wrote:
| Another twist on self hosted web apps is peergos. Uses a
| capability based system for access and sharing. End-to-end
| encrypted and P2P.
|
| App Examples - github.com/peergos/example-apps
|
| API Docs - book.peergos.org/features/apps.html
|
| Disclaimer: I work on the project.
| explorer83 wrote:
| I unfortunately don't have the availability to test their
| solution. But I love the vision. I hope they pull through.
| nunobrito wrote:
| There's an online demo on their page. Just click and try out
| everyting.
| tibbydudeza wrote:
| NextCloud and OwnCloud already exists.
| garganzol wrote:
| NextCloud and OwnCloud are productivity suites (the analogy is
| Microsoft Office), while Sandstorm is an operating environment
| (the analogy is Microsoft Windows).
| c0balt wrote:
| This looks exciting and definitely something to look out for as
| an option fkr self-hosting.
|
| Similiar and a little bit more mature is also YunoHost,
| https://yunohost.org/, or for professional environments, UCS
| https://www.univention.com/.
| fbartels wrote:
| The one big plus for ucs is their samba server, but it's not
| the right choice if you are looking for an appstore to install
| apps from.
|
| My personal favorite is Cloudron, as they have an app concept
| that only needs minimal human maintenance. And you could even
| combine it with an LDAP server like ucs for the user
| management.
| the_common_man wrote:
| https://cloudron.io is a viable alternative.
| arek_nawo wrote:
| This looks really interesting. Having the ability to self-host
| various open-source apps is great, though, for me at least, it's
| always a bit stressful. Without a lot of dev ops experience I'm
| not always confident in my setup and the upgrade process. Having
| a tool that simplifies self-hosting would certainly lower the
| "mental barrier" for more people to do it.
| [deleted]
| anderspitman wrote:
| This is, in my opinion, the biggest gap in the market.
| Selfhosting shouldn't be any more difficult or less secure than
| running an app on your phone.
| arek_nawo wrote:
| I'm a bit split on this. As an OSS enthusiast I'd certainly
| like for self-hosting installation and maintenance to be
| easier. However, from the business perspective, I also see
| this as just one less reason to use hosted services - which
| will degrade sustainability of many open source projects.
| anderspitman wrote:
| Not sure I'm understanding you correctly. Can you share an
| example of what you mean?
| Gigachad wrote:
| Unfortunately you are probably still better off using
| commercial hosted services. None of these projects really
| seemed to have the resources to properly deal with the security
| you need for an internet hosted service
| arek_nawo wrote:
| After a closer look - I must agree. On the other hand, with
| more projects implementing bash scripts or using Docker for
| easier installation, maybe there's a way to make self-hosting
| easier without such dedicated apps.
|
| Hosted services will always offer more convenience. If the
| price is fair, they are likely better options in general.
| sunshine-o wrote:
| I feel like we are always getting into the same trap with those
| self-hosting platforms. It is the same problem we faced with the
| Linux Desktop & Mobile. A lot of cool visions, but fragmented
| efforts, limited app ecosystem & low adoption. We already have
| Sandstorm, Umbrel, Start9, Yuno, etc. but none of them had the
| success they deserved.
|
| I'm wondering if taking something like Fedora CoreOS/IoT,
| Cockpit, linuxserver.io images & develop a nice GUI &
| documentation on top wouldn't have much greater chance to
| succeed. People who will try to self host & will most likely
| stick to it are already familiar with tech & willing to tinker
| anyway.
| orblivion wrote:
| Does this fit your description? https://www.freedombox.org/
| This is heavily coupled to Debian.
| prox wrote:
| Engineers love engineering, they love their own engineering
| when it comes to open source/free time projects, and they tend
| to not like the legwork of publishing, polishing and making it
| ready for public consumption. (Which is a lot of work on its
| own)
|
| Engineers and QA/useability/marketing people tend not to mingle
| in these projects. I am broken record at this point, but
| Blender and Godot tackled this problem.
|
| Take sandstorm, it looks like a informative website but _just
| looking at it_ I see a ton of friction installing it. Whether
| or not that is true, but the optics are against it.
| orblivion wrote:
| That's a useful bit of feedback. Indeed I would actually say
| that installation is quite simple as such things go. And
| maintenance is dead simple, it updates itself in the
| background.
| PurpleRamen wrote:
| I would say containers, and especially docker, turned out to be
| the best solution for this space. We just need some good non-
| commercial tools for getting the fancy nobrainer app-managment.
| Everything existing now is ever commecial or still too
| complicated for the laymen.
| wiml wrote:
| I used this for a few years at a previous job and really liked it
| -- it didn't get a ton of adoption by other people there, though,
| unfortunately. It had a bunch of cool ideas and seemed well
| implemented. I'm sad that it didn't work out as a commercial
| endeavor.
| rapnie wrote:
| I like how they use capability-based security [0] and use Cap'n
| Proto protocol. This is another technology that is slow to get
| broad adoption, but has many things going for when compared to
| e.g. Protocol Buffers (Cap'n Proto is created by the primary
| author of Protobuf v2, Kenton Varda).
|
| [0] https://sandstorm.io/how-it-works#capabilities
|
| [1] https://capnproto.org
| Timon3 wrote:
| I recently evaluated different protocol libraries for inter-
| language IPC. The state of Cap'n Proto is sadly quite a bit
| worse than Protobuf. Many languages either don't have an
| implementation, or it hasn't been updated for several years.
|
| But it's such a good system, I wish we could use it.
| rapnie wrote:
| Some language implementations are under active development,
| like C++, Go and Rust. Others not so much. As language
| support comes, these are major ones. Let's hope they can
| drive the ecosystem forwards into more popular use.
| Timon3 wrote:
| I don't think it's going to happen with only a couple
| languages with good support. Messaging is fundamental
| enough that you don't want to swap libraries if not
| necessary, which means I won't choose it if the languages
| our products use are not well-supported. Just as a couple
| of examples:
|
| - Node (& JS in general) have three implementations.
| One[1] mentions in the README that it's a hacky wrapper,
| the interface isn't final and the implementation is slow
| - for 9 years now. Another one[2] without support for RPC
| hasn't been updated in 4 years, and the last one[3] for
| 10 years.
|
| - Lua[4] has been updated sporadically over the last
| couple of years, but the README mentions it ONLY works
| with LuaJIT v2.1, not with current Lua versions.
|
| Currently it's hard to justify using it in a long-term
| project, considering how much broader the language
| implementations for Protobuf are. They also aren't
| perfect, but there is a lot more buy-in.
|
| [1] https://github.com/capnproto/node-capnp
|
| [2] https://github.com/capnp-js/plugin/
|
| [3] https://github.com/jscheid/capnproto-js
|
| [4] https://github.com/cloudflare/lua-capnproto
| rapnie wrote:
| A tough road ahead, I agree. Currently there is other
| work going, by the Spritely Institute [0] non-profit.
| They are working on standard specifications fo the Object
| Capability Network (OCapN) [1] and Cap'n Proto may align
| with that. Spritely's object capabilities vision [2]
| looks very promising. Their open standards approach is
| very early stages still [3].
|
| [0] https://spritely.institute
|
| [1] https://github.com/ocapn/ocapn
|
| [2] https://spritely.institute/static/papers/spritely-
| core.html
|
| [3] https://ocapn.org
| Timon3 wrote:
| That's awesome, thank you for sharing those links! An
| open, shared standard with non-profit backing is sorely
| needed. I'll cross my fingers for them!
| lrem wrote:
| Cap'n Proto suffers from trying to improve upon something
| good enough. It's a real pity, have such a tech without org
| weight behind it.
| ocdtrekkie wrote:
| I mean, Cloudflare has some org weight. Just not Google
| monopoly weight.
| hgsgm wrote:
| Google doesn't have a monopoly on serialization formats.
| hgsgm wrote:
| Do you know who created Sandstorm?
| anderspitman wrote:
| Sandstorm was (is?) way ahead of its time. Fortunately a lot of
| its ideas live on (a la capnproto). My understanding is the
| achilles heel is the amount of effort required to integrate and
| update apps, since each app needs to be rather invasively
| modified to work with the centralized authorization framework.
| Also the general difficulty of managing a VPS or port forwarding.
| But once integrated it's really slick and secure.
|
| The overall UX is very similar to my vision of the future of
| selfhosting. It should be as easy as installing an app on your
| phone, then going through a quick OAuth2 flow to set up a tunnel
| on a domain, and you're up and running.
| closewith wrote:
| The issue for me with Sandstorm is that it's great until some
| service/app you need is missing or broken, and then you're back
| to manual self hosting. I always find that self hosting even
| one app is the pain, self-hosting more isn't that bad (once you
| have your box setup).
| ocdtrekkie wrote:
| I think the answer is that packaging apps for Sandstorm is a
| bad hack, as ripping out the auth system and design granularity
| is all hard for an existing application. The best Sandstorm
| apps are _written for Sandstorm_ , and in those cases, the
| granularity and built-in authentication make it way _easier_ to
| write an app. I wrote a Sandstorm-native app in less than an
| hour.
|
| But if you built your entire application assuming you're
| shipping it via Docker, untangling the sheer amount of
| redundant garbage you need to pare down to a single-document
| app that accepts outside authentication and security, ends up
| being a ton of work to package and then maintain it long-term.
|
| Ideally, I think having apps not made for Sandstorm originally
| is mostly just a strategy to get enough people operating on
| Sandstorm's model for people to build Sandstorm-specific apps
| in earnest.
| robertlagrant wrote:
| I think making apps that have a very clean separation between
| external security code (e.g. "the claims in the JWT") and
| internal security code (e.g. "the app's own internal
| understanding of security, regardless of provider") is always
| a fantastic idea.
| hanniabu wrote:
| Why not just make it be a docker launcher instead?
| ocdtrekkie wrote:
| Then it would be as poor of a user experience and have as
| many security problems as one of the literally dozens of
| self-hosting tools that are just Docker launchers.
| anderspitman wrote:
| Can you share links to the major ones (I'm aware of a
| couple like yunohost and cloudron)? What are the most
| important UX issues in your opinion? Disclaimer: I'm
| working on a docker launcher for selfhosting and want to
| solve some of the current problems.
| ocdtrekkie wrote:
| Umbrel is another relatively popular one, particularly
| with the crypto space.
|
| The biggest thing is the lack of integration. Some of
| them have patchy SSO integration options, but most won't
| tamper with the app in any meaningful way, so even if you
| have login integration, you have to log into each app on
| a server, and each app is subject to that app's
| capabilities for things like sharing.
|
| You end up hosting a bunch of disjointed and separate
| services. Sandstorm feels much more like hosting Google
| Docs and it's barely ever used support for third party
| apps/document types.
|
| Sandstorm requires aggressive app packaging work but the
| payoff is significant: Apps do not have independent
| authentication at all, logging into Sandstorm gets you
| into all of your applications, and every file can be
| shared using the same process with other users or the
| public trivially.
|
| In fact, because we break apps into "grains" or
| documents, we can do crazy things like allow you create
| Collections which comprise of documents made with
| different applications and then share that as a single
| unit with others. So I can take a couple specific
| Etherpad documents, a Wekan board, and a WordPress, put
| them into a project collection, and then share that with
| a collaborator with one link.
| ignoramous wrote:
| > _Umbrel is another relatively popular one, particularly
| with the crypto space._
|
| Impressive that Umbrel's popular because IIRC it doesn't
| take security as seriously as say Sandstrom. You'd think
| the crypto folks would at least care about that, if
| nothing else?
| ocdtrekkie wrote:
| Umbrel pivoted. When it launched it actually _was_ a
| Bitcoin miner, and then they added other apps, and then
| made the Bitcoin miner optional. And yeah, I don 't know
| the details about the internals but a friend of mine was
| not thrilled with their approach. I think one specific
| point was that they don't support using HTTPS on the
| local network at all.
| kentonv wrote:
| I wrote a blog post answering that:
| https://sandstorm.io/news/2014-08-19-why-not-run-docker-
| apps
|
| Oof... 9 years ago.
| fractalnetworks wrote:
| Check out fractalnetworks.co if you are looking for something
| similar that is still under active (commercial) development.
| zenhack wrote:
| Is! We're not dead yet! (see my other comment
| https://news.ycombinator.com/item?id=36193093).
|
| I don't think app packaging could be said to be the achilles
| heel -- how much work it involves depends a lot on the app
| (some things are very easy, others can be painful), but it is
| certainly not the case that Sandstorm didn't take off because
| packaging was too hard.
| orblivion wrote:
| Packaging existing apps tends to be extra work, since you
| have to retrofit things (like user accounts). But creating
| brand new apps can actually be less work, because it has
| things built in (like user accounts).
| testernews wrote:
| "Was", what's left of sandstorm anymore besides a couple
| weekender coders whose $dayjob is at cloudflare these days?
| Doubt CF has anything like 10%/20% time like GOOG.
|
| Sandstorm the business was shut down 6 years ago
| https://sandstorm.io/news/2017-02-06-sandstorm-returning-
| to-...
|
| And Sandstorm Oasis the hosting service was shut down almost
| 4 years ago https://sandstorm.io/news/2019-09-15-shutting-
| down-oasis
|
| This codebase is basically abandonware at this point and
| can't be trusted for anything serious these days. If CF
| brought this on as an official product (and renamed it), it
| would go a long ways to build back trust
| kentonv wrote:
| FWIW, the most-active Sandstorm developers over the past
| couple of years, such as zenhack (to whom you replied) and
| ocdtrekkie, are not Cloudflare employees, and never were.
| (They were never Sandstorm employees either.)
|
| For my part, I am indeed mostly focused on Cloudflare
| Workers today and don't have much leftover energy to spend
| on Sandstorm. This has nothing to do with Cloudflare
| telling me how to spend my time. I make my own choices. I
| still love what we were building with Sandstorm, but what
| can I say, Workers has been a lot more successful and so I
| am drawn to focus my energy there.
|
| Note that Cloudflare has no affiliation with Sandstorm,
| other than employing some of the former team members.
| Cloudflare did not acquire Sandstorm itself.
| omginternets wrote:
| The Go implementation of capnp is alive and well, too. I
| highly recommend it: https://github.com/capnproto/go-capnp
| bullen wrote:
| Packaging should always just be zip.
|
| Security can just be a OTP: https://github.com/tinspin/rupy/b
| lob/master/src/se/rupy/http...
| drapado wrote:
| How do you compare to Yunohost? I find the app selection of
| Yunohost larger and broader
| macrolime wrote:
| Sandstorm is much more secure, that's the main difference.
| bdn_ wrote:
| I'm not too familiar with either's privacy/security
| practices, what makes Sandstorm more secure than
| Yunohost?
| kentonv wrote:
| https://sandstorm.io/how-it-works
|
| Sandstorm implements a capability-based security model,
| where not only does each app run in a strong sandbox, but
| a new instance of the app is created for each _document_
| (or whatever the app 's logical unit of data may be).
| Sandstorm itself enforces that each document can only be
| accessed by the people with whom it has been shared,
| regardless of any bugs that might exist in the app
| itself. All communications between the user's browser and
| the app go through a proxy implemented by Sandstorm which
| applies this authorization regime.
|
| Apps cannot even talk to each other or the internet
| without specifically requesting access, granted by the
| user. The UX model for these requests is designed to flow
| naturally for the user, by deriving the user's intent to
| permit access from the action they took that caused the
| access to be needed. For example, say the user wants to
| embed a chart into a document, where the chart editor and
| document editor are separate apps. The user clicks some
| sort of "embed" button in the document editor. Now they
| are presented with a chooser where they can pick which
| thing they want to embed. If they make a choice, there is
| _no need_ to separately ask the user if they want the
| document to have access to the chart -- of course they
| do. Sandstorm works by having the system implement the
| "picker" UI directly, so that Sandstorm _knows_ the user
| made this choice, and can automatically provide the
| implied authorization.
|
| All this actually makes apps easier to write since they
| don't have to deal with authorization and user management
| themselves, and as a result there are a lot of neat
| unique apps for Sandstorm written by various people in a
| short amount of time. However, the down side is that
| existing off-the-shelf apps that _do_ already feature
| their own user management and authorization are somewhat
| laborious to port to Sandstorm.
|
| Yunohost takes a more traditional model of just running
| each app and letting it figure out its own authorization.
| jrm4 wrote:
| "Security" really ought not going to be much of a selling
| point, since _no one_ is particularly good at it these
| days; I 'd be shocked if this thing could actually point
| to meaningful, as opposed to theoretical, security
| advantages.
| omginternets wrote:
| I understand where you're coming from, and I would
| encourage you to get familiar with object capabilities,
| as it is one of those big pieces of hitherto-ignored low-
| hanging fruit.
| ocdtrekkie wrote:
| Sandstorm is really good at security. I would absolutely
| encourage you to download a copy and try to identify an
| exploitable security vulnerability. As a Sandstorm user,
| I'd really like to know about it!
| jrm4 wrote:
| I suppose I'm talking about marginal differences. As in,
| I'd be surprised if Sandstorm can strongly outdo, e.g. my
| own Docker + Nginx proxy manager+SSL stuff?
| ocdtrekkie wrote:
| You will be surprised then. Sandstorm utilizes
| capability-based security to grant access to
| applications, each app is only ever running when an
| authorized user attempts to launch the app, and each
| document within a given app is isolated to it's own only-
| run-on-demand container.
|
| The core difference here is that for all intents and
| purposes app vulnerabilities are almost wholly mitigated.
| The only significant type of app vulnerability which
| Sandstorm cannot prevent is privilege escalation within a
| single document, where you've shared limit access of a
| document with a user, say read only, and due to an app
| vulnerability, they've figured out how to edit it.
|
| Since all documents are private solely to the user who
| created them initially, and the process isn't even
| running until that particular user tries to open it,
| there's effectively no attack surface for Sandstorm apps
| most of the time. When they are spawned, they're spun up
| at randomly-generated ethereal subdomains, and authorized
| solely for access by the web browser that launched them.
| the_common_man wrote:
| One can choose something like cloudron which provides
| isolation via docker
| ocdtrekkie wrote:
| Cloudron is pretty cool, and Docker containers definitely
| help, but there's a huge security difference between what
| Docker provides and what Sandstorm does. One of the
| biggest differences is that most plain Docker-based self-
| hosting platforms isolate at the app level. Sandstorm
| isolates individual documents, which often means
| Sandstorm apps are protected from their own internal
| flaws as well.
|
| Also, Cloudron is not open source and you need a
| subscription to use it generally. This has led it to be
| more successful of a business venture, of course, but is
| a big downside for software freedom.
| goodpoint wrote:
| docker was never meant as a security tool. Proper
| sandboxing needs to be done in the applications.
| asmor wrote:
| What would an application do that is more secure than
| namespaces+cgroups? Containers absolutely are a security
| tool (especially if you configure your capabilities and
| don't use PID 1), one with a security tradeoffs compared
| to real virtualization, sure, but you're not going to do
| that on a VPS.
|
| Docker (or Podman) is just a tool that sets up some linux
| primitives for you. One with a track record and volume of
| users that'd make me trust it over things that
| specifically advertise themselves as "security sandboxes"
| (i.e. firejail, who had some extremely funny basic
| exploits to get root from their SUID'd binary). You can
| even pair containers with user namespaces now and get the
| fakeroot equivalent of containers.
| goodpoint wrote:
| > What would an application do that is more secure than
| namespaces+cgroups?
|
| You need to understand how sandboxing work.
|
| > Docker (or Podman) is just a tool that sets up some
| linux primitives for you. One with a track record
|
| A pretty poor track record.
| asmor wrote:
| > You need to understand how sandboxing work.
|
| That's pretty much my job. Can you be more concrete with
| what you're talking about instead of this passive
| agressive "you don't know what you're talking about"
| tone?
|
| Flatpak and Snap are pretty much using the same
| primitives as containers, they just don't like using the
| word because of existing connotations. Mandatory access
| controls are neat, but nobody actually uses them unless
| the default doesn't disturb them or they have a
| compliance requirement.
|
| > A pretty poor track record.
|
| Modern containerd, after having been split up from
| Docker/Moby, has a better track record than most other
| sandboxing tools. I mentioned a laughably bad one that
| the Arch wiki and many HN users still seem to endorse.
| emacsen wrote:
| > What would an application do that is more secure than
| namespaces+cgroups?
|
| Object capabilities, which is what Sandstorm/Cap'n Proto
| are based on, provides much more security than Mandatory
| Access Control systems while also providing a much
| simpler method for getting there.
|
| Sadly the literature on OCAP is fairly poor, often being
| either too low level or too abstract.
|
| The tl;dr is that OCAP systems work by assuming an
| application has no functionality whatsoever, and then
| must be passed (not sandboxed but passed) functionality,
| either at start time, or when the application requests
| it.
|
| The easiest way to understand it is imagine if instead of
| being able to open a file on the filesystem by path, you
| had to specifically be passed the file descriptor by the
| OS, possibly before runtime.
|
| Another way to think about it is thinking about the
| OAuth2 capabilities that you can grant an application.
| You authorize an application to have certain
| capabilities, and then the client is handed back a set of
| API tokens or addresses. Those are the only way it can
| exercise those capabilities.
|
| It's not being sandboxed, it simply doesn't have any
| additional way to get access.
| asmor wrote:
| That seems interesting and like a technically correct way
| to go, but also I can see nobody adopting it on a general
| purpose operating system and thus rendering it useless.
| Getting developers to use portals already is hard enough.
|
| Thanks for actually answering the question.
| vmfunction wrote:
| I have tried for a client who wanted to install open source app
| in server with sandstorm about 3 or 4 years ago, it is just
| very slow at the time. Hope they improved that since.
| openscript wrote:
| For the services at home I use https://www.runtipi.io/. I'm quite
| happy with it.
___________________________________________________________________
(page generated 2023-06-05 23:03 UTC)