ocdtrekkie
twtxt.net
No description provided.
No description provided.
@prologic@twtxt.net Yeah I have two options for static hosting I like: One is a Dropbox like file store, drag-drop files and theyâre statically hosted, the other is a GitWeb instance where you can just push updates to it for static hosting.
@prologic@twtxt.net The green banner tells me you need that registration CAPTCHA. ;) https://git.mills.io/yarnsocial/yarn/issues/962
@carsten@yarn.zn80.net Another good option to bear in mind is the DomainConnect protocol, depending where you buy your domains: https://www.domainconnect.org/
It supports basically an open standard protocol of updating your DNS from a local script, and they provide both a Python script and a .NET app to do it.
@prologic@twtxt.net Thereâs a few places users will tend to prefer a monolith (social networks and feed readers come to mind), but anything document-based it makes a huge difference. The biggest downside is that since âstarting the web serverâ happens every time you open an document, apps have to start very very fast. Itâs why we prefer SQLite over MySQL heavily, for example. Also, MySQL has a lot of overhead per-database, which makes file sizes annoying large, for example.
From a size, isolation, and performance standpoint, a lot of your small Go apps fit very well in the model already. :)
Thereâs some interesting impacts here: If you donât share a document with anyone else, thereâs really zero way any vulnerabilities in the app itself can be exploited in any way, itâs not even running unless you open it via Sandstorm. So itâs safe to use these apps basically forever even without security updates.
The other big one is performance: Since apps are only running while youâre accessing them, thereâs no performance cost to having a lot of different apps âinstalledâ on your server. The cost of installing an app on your server is the storage, and CPU/memory is only impacted on demand.
In a normal Docker setup, a flaw in Etherpad could lead unauthorized users to access documents they shouldnât be able to, or of course, edit documents without permission, including documents they werenât supposed to have access to. Since Sandstorm spins up Etherpad containers on demand, if a user doesnât have access to a document via Sandstorm, the server isnât even loaded/running anywhere, and nobody can access it. When we do spin it up, the authorized user gets a container with⊠only the one document they have access to. A flaw in Etherpad could let a read-only user exploit their way into editing, but only, again, for the one document they already had access to.
Also, Sandstorm spins up these containers on ethereal randomized subdomains, and requires a unique authorization cookie on your browser to access them when theyâre up. So theyâre also very difficult to access even when theyâre spawned without authorization.
If you consider an application like Etherpad, which by default, one would run and have dozens, hundreds, or thousands of documents, and you might host it at etherpad.yourdomain.com. And itâs always running, and itâs data is always available, and itâs using system resources. Additionally, you might want to share some documents with people, so people might have access to your Etherpad instance, but maybe only read-only, and only to some documents, or whatever.
Essentially the key concept is to move as much of the management of security and access to the platform, and not the individual application. Sandstorm assumes the applications might be insecure, or even actively malicious, and so we want them as inaccessible and locked down as possible all the time.
With a platform like YunoHost without virtualization, an RCE in an app could compromise everything on your server. A Docker-host like Cloudron or Umbrel, an RCE in an app could compromise all of the data in that app. More often than not, an RCE in a Sandstorm app grants zero ability to compromise anything at all. This means Sandstorm very rarely cares that apps have any good security practice at all: In most cases it just doesnât matter.
So, @prologic@twtxt.net, I feel like I should convince you that your self-hosting solution you build should use containerized documents (Sandstorm calls them âgrainsâ for kind of good reasons, but documents is usually applicable). This would have twofold benefits: 1. Your platform would be more secure/better. 2. Apps you build for it would probably be reasonably straightforward to also run on Sandstorm.
This is why Iâm moving a bunch of my âsitesâ to basically internal-only apps on my Sandstorm server. I never really needed anyone else to have access anyways.