I host Synapse using this playbook. I can highly recommend it - the instructions are very clear and detailed and ongoing maintenance is straightforward too (just git pull and redeploy, and 5% of the time modify a deprecated variable).
As for how to delegate to a subdomain - that’s covered here. Basically - you set it up on matrix.example.eu and then have a “well known” file hosted at example.eu that tells other clients/servers where to look.
For services only I depend on, I have production-only. Since I can only inflict damage on myself, and can often work around problems.
For the XMPP server my friends and family also depend on, I have a dedicated nonprod VPS. My services are driven by ansible playbooks, so I’ll tweak the playbook with whatever change I want to make works in nonprod, before running the same playbook against prod.
Whenever there’s a new Debian Stable release, I’ll rebuild the servers completely, to try and prevent “drift” between the nonprod and prod versions (not that I change things often enough for this to become a big problem). This is also the big test of my backups, which so far haven’t been needed in a “real” emergency 🤞
Distributions handle this for you. Installing your software through a distro, instead of getting it from each individual software authour, means that you trust one organisation instead of hundreds of individuals.
For instance, Debian has a strict set of guidelines for Debian developers (who have the right to upload packages). They will be familiar with the software they are packaging, are often independent from the upstream authours, and are expected to check the package for various issues, including licensing, security, version incompatibilities etc. In addition, every upload is signed, so you can see who is responsible for everything.
And when something slips through, as almost happened with xz, the analysis and recovery all happens completely in the open. There may not have been enough eyes on xz to prevent the vulnerability in the first place, but once it was discovered, there were at at least hundreds of people dealing with the aftermath, all in the open.
Compare this with proprietary software, where you’d be lucky if such a vulnerability was even disclosed, vs just silently patched.
Yep
I can highly recommend Mythic Beasts (UK).
There is no upsell or variable pricing and they make money by charging a flat rate on top of the cost from their supplier. See this blog post for more info
Yes, me too! But, only if I have the autonomy to improve things where I can. Otherwise, I just find it demotivating
I agree, it’s a great UI in terms of speed and no JS, but it’s not super intuitive and not helped by the way it’s been split into modules.
Basically, each subdomain (git.sr.ht, todo.sr.ht etc) doesn’t link to the others - the only one that links everywhere is the root “sr.ht”. You can think of sr.ht as a “hub” that links to the others. So - to take an example:
So, in your case, if you replace git.sr.ht with just sr.ht in the URL, it should take you back to the “hub” for that project. Then, if the tickets feature is enabled, you should see a link to “tickets” there.
nlnet is the main one that comes to mind.
How much money do you donate?
I am very privileged to have some money left over after fulfilling essential needs. So, I set a fixed amount a while ago, and then whenever I am able to make a saving (e.g. switching to a cheaper phone plan) or get a pay rise (if it ever comes), I’ll put some of the gains into donations.
When do you donate?
I remember reading somewhere that many organisations prefer regular donations to one-off donations, even if the regular amount is smaller, since it helps them plan better. So I always give regular donations, even if the amount is smaller to compensate.
I have everything set up as automatic donations in liberapay and OpenCollective. So, it’s pretty seamless!
If anyone ever wants to gift me anything, I’ll ask for them to consider a donation to a project instead.
Do you have a minimum donation amount?
I try to avoid payments under £5. Below that point, way too much of the money goes to fees. For some projects where I donate a small amount, I donate yearly instead of monthly instead.
How do you decide what projects to support? Do you forego donations if you’ve contributed in other ways?
I don’t donate to every project I benefit from, but I care a lot about XMPP and Linux on Mobile, so I donate mainly to projects in these areas. I’ve also contributed code to some of these projects, but I keep donating as I want to support the ongoing maintenance as well as just individual features.
Do you donate to all equally or do you have some sort of ranking? Is it by amount of use, subjective preference, something else?
I care about XMPP as a whole succeeding, so I donate to many projects I don’t even use myself. I wanted to donate to clients and servers for each major platform, so I split the clients like this:
Then, I donated an equal amount to each platform (so, for example all the Linux clients combined would get the same as the single Android client).
However, since I was donating so little to each Linux client, I decided to gradually increase the amount I donate to those over time.
I’ve also recently started donating to libraries / ancillary projects in the same space. But I don’t have much money left to play with for them, so the amount is smaller :(
Linux on Mobile is simpler as I only donate to two projects, so I just donate equally to both.
So, long story short, it started with some kind of structure, but has become more subjective since then :)
What platforms do you prefer using? Liberapay, Opencollective, Patreon, ko-fi, Paypal, Monero, actual post?
I really like liberapay, especially as it mostly works without Javascript. But Opencollective is pretty nice too. If the developer themselves gives a preference, I’ll normally use that platform.
One thing I’m interesting in knowing is - do people generally prefer donating to fewer projects, but with bigger amounts, or vice versa? One criticism of my approach is that, because I am spread quite thin, I risk not really helping any project that much, whereas if I focused on one or two projects, at least those could benefit a bit more.
It’s not perfect yet, but it’s much, much better than the old days.
OMEMO is supported by every major client, and they interoperate successfully. Unfortunately, most clients are stuck with an older version of the OMEMO spec. It’s not ideal, but it doesn’t cause any practical issue, unless you use Kaidan or UWPX, which only support the latest version.
All popular clients and servers support retrieving chat history now too.
In practice, I’ve been using it for several months to chat with friends and family, and haven’t had any issues.
Perfect, now you just have to wrap your program inside a debugger in production!
Yep, that’s the gist of it. In order to change the license from the GPL, they’d need the permission of all of the copyright holders who’ve contributed code under the GPL to the project. After a few months have passed, this basically makes it impossible (or at least extremely difficult) since at least one person (and likely many people) will say no.
They have also funded a lot of improvements to XMPP clients and servers.
I originally suggested Monal to my friend (who is quite into iOS and really appreciates a well designed application) and she found the same, but then she tried Siskin, and was happy enough to use it to this day.
Just for reference, here are my favourites on each platform.
Each support modern XMPP extensions, interoperate very nicely with each other, and (at least in my opinion) look good!
As a note of caution, I used Oracle’s free tier to run a personal Matrix server, and it got deleted without any advance warning after a few months. I migrated to another provider and haven’t had any issues for 2+ years now.
Along similar lines, I’d say Snikket. I feel XMPP often has quite a bad reputation based on the user experience from 10 years ago, but it’s come such a long way and projects like Snikket make it very easy to get started.
This was a good watch. I liked the emphasis that you’re not paying for code per se, but paying to support a specific maintainer who is developing some code. In that context, already having a community around you, and doing a bit of self-promotion is important.
The same authour has another interesting video about the weird incentives around feature request bounties, which I enjoyed as well.