I've recently been setting up web servers like Forgejo and Mattermost to service my own and friends' needs. I ended up setting up Crowdsec to parse and analyse access logs from Traefik to block bad actors that way. So when someone produces a bunch of 4XX codes in a short timeframe I assume that IP is malicious and can be banned for a couple of hours. Seems to deter a lot of random scraping. Doesn't stop well behaved crawlers though which should only produce 200-codes.
I'm actually not sure how I would go about stopping AI crawlers that are reasonably well behaved considering they apparently don't identify themselves correctly and will ignore robots.txt.
When me and a bunch of friends and acquaintances switched away from Slack a little under a year ago (I think) we looked into Matrix. One of the primary requirements was that even our non-technical friends should be able to use it.
At the time Matrix/Element had recently launched their Matrix 2.0 efforts and I tried setting up the whole stack without resorting to their all in one shell-script meant for non-production use. I did not mind hosting four different servers (Synapse, Matrix Auth Service (MAS), Call, etc), but did find the integration and config job a bit tedious. The main blocker though was the lack of an invite-system in the new Matrix Auth Server. Also the fact that the Element X app uses a new Livekit based call server while other clients/apps use a different approach is also something not great.
We ended up going for Mattermost. One service easily hosted with Docker. One app, and easy invites. While I think federation would be cool, right now Mattermost was a bit simpler to get up and running.
Element seems more focused on enterprise and government contracts than self-hosters. I think this is fine, they need to pay their bills. But Matrix 2.0 for self-hosters might need a better story right now.
When we first announced Matrix 2.0 implementations in Sept 2024 we made a major error by not providing an easy distro, so I feel your pain.
We fast-followed with https://github.com/element-hq/ess-helm as a really easy distribution (albeit using helm charts) based on the paid offering we provide for folks for NATO and the UN and folks. It really is trivial to install now - e.g. here's a live-install from FOSDEM last weekend: https://youtu.be/EngsGD30Ow0?t=929
While I definitely appreciate that this exists now (as another person who considered matrix and ended up passing due to deployment complexity) this is not what I think most folks would reasonably call a "trivial" docker compose setup.
It's a 16 service compose setup, complete with init hacks, inline docker-file builds to use those init hacks, a whole bunch of required config templates, some services that aren't clear if they're examples or requirements (ex - why is mailhog in there? just give me the SMTP env vars), and just a lot of general complexity still.
This feels like several discrete services that don't play nicely, herded together like cats. It doesn't feel like a solid and planned set of tools.
---
From my end - it's not enough to just stand it up. If this is my primary messaging tool and I'm hosting it, I need to have a feel for how it might break, and how I can fix it when it does.
Hell, I'm not even allergic to k8s (I host dozens of services on a baremetal cluster), but I am allergic to helm for very similar concerns: Complexity at the self-hosting scale (individual to small business) is rarely worth the additional overhead, and helm rapidly makes what should be simple yaml file deployments a complex, abstracted process. Your docker compose has a similar feel.
My first rule of thumb is "How long will it take me to manually read and understand a compose file while converting it to a k8s deployment?" This one looks onerous, not trivial.
I'm in the same boat as you. I've built a personal home page with Astro and hosted it on Cloudflare. It has been really cheap, only paying for worker subscription at 5 dollars per month. The site has been running non-stop essentially without downtime. And as you say the user experience of Astro's static HTML, css and minimal JS output on Cloudflare edge CDN network is really good.
But with the events of the world being what they are I have been considering moving my Astro page to BunnyCDN and thus Europe (where I live). The only Cloudflare specific feature I've used is D1 database so migrating now shouldn't be too difficult. I really hope Cloudflare does not make it difficult to use Astro on other providers, either intentionally or by accident. Next.js for a long time was essentially a framework that only ran great on Vercel, and using other providers was asking to become a second citizen. I believe it is somewhat better now with proper provider plugin system, but still.
Astro has been great and I understand they need to find a way to economically sustain their business. Joining a big company like Cloudflare is one way to do that. I can't complain too much never having opted to use Astro's commercial offerings. So I only hope they keep Astro open. I'm building a new product on top of Astro now and would hate to see it become a Cloudflare-only product.
I’ve ended up the same place as you. I had previously set up my gpg key on a Yubikey and even used that gpg key to handle ssh authentication. Then at some point it just stopped working, maybe the hardware on my key broke. 2FA still works though.
In any case I figured storing an SSH key in 1Password and using the integrated SSH socket server with my ssh client and git was pretty nice and secure enough. The fact the private key never leaves the 1Password vault unencrypted and is synced between my devices is pretty neat. From a security standpoint it is indeed a step down from having my key on a physical key device, but the hassle of setting up a new Yubikey was not quite worth it.
I’m sure 1Password is not much better than having a passphrase-protected key on disk. But it’s a lot more convenient.
> I had previously set up my gpg key on a Yubikey and even used that gpg key to handle ssh authentication. Then at some point it just stopped working, maybe the hardware on my key broke
Did you try to SSH in verbose mode to ascertain any errors? Why did you assume the hardware "broke" without anyone objective qualifications of an actual failure condition?
> I figured storing an SSH key in 1Password and using the integrated SSH socket server with my ssh client and git was pretty nice and secure enough
How is trusting a closed-source, for-profit, subscription-based application with your SSH credential "secure enough"?
Choosing convenience over security is certainly not unreasonable, but claiming both are achieved without any compromise borders on ludicrous.
I love that Kagi puts the "monetization" icon right next to results so I can avoid navigating to them. This means I'm much less likely to click on Medium.com links and other monetized blogs and sites. Often times the good content is on some personal website where the creator doesn't really care about earning money off it.
Another neat feature is the possibility to rank results or block them manually so you can lower visibility of certain sites. Really help push the scammy sites down.
Compare this to Google Search where the first half page is paid results (ads) and the rest of the results are of dubious quality. And you don't really have much of a way to influence your search results.
> love that Kagi puts the "monetization" icon right next to results so I can avoid navigating to them
One of the things I love about Kagi is it isn't overly opinionated. I'm not particularly sensitive to this issue. You are. Yet until this comment, I didn't notice that Kagi was doing this. It informed you. It didn't get it in my way. That's good design.
> Another neat feature is the possibility to rank results or block them manually so you can lower visibility of certain sites. Really help push the scammy sites down.
The ad-driven search engines refusing to implement this really drives home their conflicts of interest.
I don’t mind Medium being monetized, but I have the domain downranked, because posting on medium is a very strong signal that the content is worthless.
Scaleway is indeed the closest thing we have to AWS, Google Cloud and Azure by a European company. They are fast building out a comprehensive managed cloud with IAM, managed databases, containers, etc. I do hope they succeed. I've only used them for hobby projects, so my experience is limited to lighter workloads. But the UI is pretty good, and they have APIs and CLI for all operations.
This. Relying on developers manually trying to follow a style guide is a recipe for not having a consistent style. Instead something like pgFormatter should be used. I'm not sure what the state of SQL formatters and IDE support is these days. Not sure how many command based options there are.
And people who use things like Datagrip or other IDEs will probably format with their IDE's preferences unless there is a plugin for things like pgFormatter. This works well if there is a company mandated editor/IDE, but not so well when you have developers across various editors and IDEs.
A killer feature rustic has over restic is built-in support for .gitignore files. So all your dependencies and build output is automatically ignored in your backups.
Nice. Using `.gitignore` would simplify my Restic, Borg/Borgmatic, and Rsync-based backup scripts/configs. (Right now, I end up duplicating the same information in a few places, not very well.)
At first I thought that sounded great, but then I realized that that would exclude files that I want to be backed up, like `dir-locals-2.el`, which should be excluded from git, but should also be backed up. There doesn't seem to be a great solution to that in general.
Wouldn’t you back up your git repos by pushing them somewhere? Even if that somewhere is a different directory on the same drive. Backing up your local working copy sounds a bit odd.
I see they have gotten support for S3 (and other storage providers) via OpenDal. Might need to revisit rustic for my backup needs then! I once started looking at what it would take to build a GUI using Tauri (Rust backend <-> JS/Web frontend), but didn't have time to figure out the APIs.
What I really like about Rustic is that it understands .gitignore natively so you can backup your entire workspace without dragging a lot of dependencies, compiled binaries, and other unnecessary data with you into your backups.
As a developer who has worked extensively with React and Reagent (a ClojureScript wrapper around React) I actually enjoy this kind of syntax. Better that then some custom HTML templating syntax I need to learn in addition to the language.
It doesn't look too bad if one also break the code into multiple functions to make "layouts" and "components".
I have had lots of fun building with Bun, ElysiaJS, and HTMX. Might test your go library out as well. Looks pretty neat.
I'm actually not sure how I would go about stopping AI crawlers that are reasonably well behaved considering they apparently don't identify themselves correctly and will ignore robots.txt.