One major caveat is that because of Sandstorm's draconian security (I mean this in a good way), a handful of ntfy's features won't work because they use special headers. Mastodon works so I'm assuming they use the json API. One of my tasks is to go through major services and test them.
Another one is protected topics. "Users" use auth headers (there's a GET string option, but the Android app source code indicates that it opts for headers). Sandstorm does give you the benefit of randomized API URLs that you can revoke, which protects you from random actors, but any service (Mastodon, Matrix, etc) you connect to will need to see that URL so they may in principle snoop on easy-to-guess topics.
What would you say the main points are for sandstorm?
Is it about hosting apps on different domains and using a powerbox between them? Or is it something more? Why does sandstorm use capnproto for instance?
In our framework for instance, instead of capabilities, we implemented "invites", which people can send to each other. If an invite grants you readLevel access to a document, you'll be able to see it even before you log in and create a user account. But if you want to get the full access to write etc, you'll have to create a user account and accept the invite as that user.
Well, first and foremost, Sandstorm uses Cap'n Proto because Cap'n Proto was built, first and foremost, to enable Sandstorm. :) Though of course, now it also powers Cloudflare Workers and a bunch of other things.
So access to apps or documents by users, as well as those apps and documents being able to reach out to other resources, is all generally wrapped in capabilities.
I think as a self-hosting platform, the biggest advantages of Sandstorm is that we force developers to provide a no-config-file, no-sysadmin-required experience, so Sandstorm is probably the only self-hosting platform currently intended to be used by people who are not tech people. This naturally flows into some other things: If you don't have a sysadmin running it, it needs to be really secure (capabilities) and very good at self-managing it's own performance.
So Sandstorm apps do not consume any resources unless you are accessing them. Everything is spun up and closed down on demand. And the platform's security model not only means vulnerabilities in apps mostly aren't exploitable and apps don't need to be patched, but Sandstorm strives to safely allow non-technical users to install and run potentially even malicious apps without risk.
I'm your example it sounds like invites are a form of capability based security, which is what sandstorm uses.
I'm not an expert, but my understanding is that sandstorm takes all of the system calls from your apps, and uses capn proto to serialize those calls to the powerbox. The powerbox then checks to see if that operation is allowed for that user, and if so it executes the call, and serializes it back to the app (which then displays it to the user, for example).
Sandstorm uses CapnP because it's technically sound, battle tested, and efficient.
You could just make http requests back and forth (that's kinda if the default for web apps) but there is latency overhead and way more surface area with http.
Oh this would be really handy, I'd love to run it on my Sandstorm server!