ocdtrekkie

twtxt.net

a ferret

Recent twts from ocdtrekkie
In-reply-to » @prologic I think we could use deltachats new decentralising app format for it: https://delta.chat/en/2022-06-14-webxdcintro

@prologic@twtxt.net Intriguing! It downloads on Firefox, but you aren’t actually supposed to download it, you’re supposed to let your calendar subscribe to it. (Sandstorm API URLs aren’t generally supposed to be accessed via normal browsers… there might be user agent code for that, not positive.)

⤋ Read More

Calendaring is hard, so those who actually read the file will notice it’s set as 12 AM in America/Chicago… I should probably edit it to be based around UTC, or James’ time if he does any daylight savings stuff and intends the call to follow it accordingly… but if I amend this, and you subscribe, your calendar will get the updates!

⤋ Read More
In-reply-to » @prologic I think we could use deltachats new decentralising app format for it: https://delta.chat/en/2022-06-14-webxdcintro

@prologic@twtxt.net Host an ICS file people can add to their calendar of choice, which you can edit/update as needed.

Example: Subscribe to https://api-3da23a889bf723786c4367d1f36a1ca2.ocdhost.sandcats.io/.sandstorm-token/H-GeVZmxQN5aN3ArLHe7SDynYB5wEac1bxwq55ugQYB/export.ics in your calendar of choice. I have the current call schedule in it.

⤋ Read More
In-reply-to » Running prologic/static on it will work nicely and consume very little in the way of resources 😅 I use this for all my static site hosting needs 😂

@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.

⤋ Read More
In-reply-to » Problems with my DNS were preventing me to do stuff on my homelab. So I switched DynDNS from inwx.com to desec.io. Much, much better, faster and easier to set up. Awesome! Also, the CNAME entries work much faster than with INWX. But maybe the things with INWX just need to spread a bit longer.

@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.

⤋ Read More
In-reply-to » So, @prologic, 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.

@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. :)

⤋ Read More
In-reply-to » So, @prologic, 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.

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.

⤋ Read More
In-reply-to » So, @prologic, 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.

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.

⤋ Read More
In-reply-to » So, @prologic, 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.

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.

⤋ Read More
In-reply-to » So, @prologic, 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.

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.

⤋ Read More

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.

⤋ Read More
In-reply-to » The vast majority of visits to my web server are: - Me - People or bots looking for vulnerabilities - Web crawlers

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.

⤋ Read More
In-reply-to » Update on trying to get Yarn into the Umbrel App Store.

Sandstorm currently has no special behavior for local networks versus over the Internet: All things use the public IP and supports Let’s Encrypt. Access hence somewhat depends on hairpin routing, but certificates are no issue. On my home network, I actually adjusted my DNS to route my Sandstorm with local IPs internally, mind you, so it works when the Internet is down.

⤋ Read More
In-reply-to » So I setup a Cloudron installation on a Vultr VM.

The way Sandstorm generally addresses the initial-user setup problem is that you can generate an “admin-token” from the CLI to log in administratively one time, and do whatever account setup (or OAuth configuration recovery) that you need to do.

I’m kinda curious where they failed out on this, considering it’s a ready-to-deploy app they support on Vultr, from the looks of it.

⤋ Read More
In-reply-to » @retrocrash So... About these other self-host(er) communities you speak of... Where do we find them, who do we talk to? 🤔

@prologic@twtxt.net Obviously Yarn should be on Sandstorm, but as much as I knock other selfhosting platforms you could get on them very easily. Cloudron, Umbrel, etc. are basically just Docker hosts at the end of the day, but it’d put Yarn in front of everyone who uses those platforms for self-hosting.

⤋ Read More
In-reply-to » The only thing I'll say about Roe v. Wade is this. Overturning the decision does not make abortions illegal, it establishes that the legality of abortions is not within the purview of the Federal government--a stance that also blocks Republicans from enacting a federal-level abortion ban.

@rob@twtxt.net There’s nothing that inherently blocks the federal government from passing a law banning abortion here, it’s just a claim the court establishing a right to abortion was an overreach. Bear in mind, both parties are willing to claim it should be a state’s rights thing… until they’re in the position to enforce their view federally.

⤋ Read More
In-reply-to » Great conversation with @ocdtrekkie tonight. Some things we talked about: * Goryon being taken off the Google Play Store * The woes of uppercase ls and Iowercase Ls * De-Googling Android * The Google Glass and how it forced you into the walled garden * iOS and privacy * Privacy legislation and the extent to which people know about the spying * Creepy Amazon stores * The new issue of Lab6 (https://lab6.com/3)

@mckinley@twtxt.net I prefer Jitsi’s UI but it performs fine. Bear in mind I didn’t hear or see anything on that call though.

⤋ Read More
In-reply-to » Great conversation with @ocdtrekkie tonight. Some things we talked about: * Goryon being taken off the Google Play Store * The woes of uppercase ls and Iowercase Ls * De-Googling Android * The Google Glass and how it forced you into the walled garden * iOS and privacy * Privacy legislation and the extent to which people know about the spying * Creepy Amazon stores * The new issue of Lab6 (https://lab6.com/3)

@mckinley@twtxt.net Did you do this from memory or like… did you take notes? O.o

⤋ Read More
In-reply-to » fucking gg https://www.theregister.com/2022/05/31/vmwarebroadcomacquisitioncustomerreaction/

@prologic@twtxt.net So in actuality they already do: Nobody would be caught dead running vCenter without a valid support contract. Of course, that’s in addition to the upfront purchase.

Switching to fully subscription largely means disregarding the initial purchase, in favor of a higher yearly bill.

⤋ Read More
In-reply-to » fucking gg https://www.theregister.com/2022/05/31/vmwarebroadcomacquisitioncustomerreaction/

@prologic@twtxt.net The best part is the announcement they intend to rapidly shift VMware to subscriptions. So the acquisition hasn’t even closed and they’ve already announced they’re buying it just to bleed customers dry.

⤋ Read More
In-reply-to » So like... there's no notifications for this thing, are there, @prologic?

@prologic@twtxt.net I do understand that, though it makes the engagement problem even worse, I have to remember I said something on here, and then actively check and see if anyone ever commented on it. I try to enable email notifications on every network I use (though some platforms do make this difficult to try to force you to browse directly on their site).

⤋ Read More
In-reply-to » I would agree with the original claim, that open source is broken, because we've let small groups of people (OSI and FSF) hold very arbitrary and restrictive rules that prohibit fixing the issue. The SSPL and similar solutions exist, but we refuse to embrace them because of these gatekeepers to the official definitions of FOSS.

The problem we keep seeing with open source businesses, is if it’s successful enough that Amazon, Google, or Microsoft want in on it, they’ll provide a service hosting your open source project cheaper than you can, without having done any of the development work or contributing anything back.

The OSI though has refused to accept SSPL as being “open source” though, so people argue that it is not. The view that I found in their discussions was that it “wasn’t their responsibility” to make open source businesses viable.

⤋ Read More