I can agree with this, at least.

If you want to keep everything inside a singular Nix configuration while still using Docker, you can check out the NixOS option virtualisation.oci-containers - essentially, a declarative way of managing docker/podman containers (similar to docker-compose) but with Nix.

Wouldn’t just using a temporary phone number service work? From what I remember, you just need to recieve a text message and put it into Signal during registration. From skimming through the post, there’s no mention of this option.

I would agree somewhat, except I think Bitwarden verifiably doesn’t store unencrypted password data. Of course, I think that a self-hosted solution is pretty much always more secure than one that isn’t, but the convenience Bitwarden provides is real.

You could host on Gitea and mirror to GitHub. Obviously, users may be less inclined to sign up to your Gitea instance, but I hope people being unwilling to register becomes less of an issue once Forgejo (Gitea fork) implements forge federation.

I hope this changes (even if a little bit) once Forgejo (FLOSS Gitea fork) adds forge federation.

I’m not sure - conduwuit does seem to have more active development but it’s not as though conduit is dead either…I also can’t find any other reasons to use conduwuit mentioned on its repository, so I’m just going to stick to conduit.

I’ve been using Conduit within a docker container for a while now, and it’s worked pretty well aside from the mautrix-signal bridge (this was fixed in version v7.0.0, I think). Other than conduit, I tried out dendrite, but the latency in sending messages was unbearable.

I’ve previously had issues with Matrix being incredibly slow and unreliable with federation (I’m self-hosting). However, that’s pretty much in the past now and I seem to have somehow resolved that issue.

I’d just like to add that you can use a temporary phone number service to sign up to Signal as you only need a phone number to register, not to actually use Signal.

This is a pretty good option, though I also think something like what aseprite has done is pretty good too (compile it yourself for free, or pay for a precompiled binary available through e.g. Steam) - from what I can tell this setup is fairly profitable.

Well, I’m not sure how many lines of C rm is written in but I think that rm being only around 4kb (iirc) is something to consider.

But still, storage probably matters least in this day and age. Oh, and…

something I used to completely nuke my home server

If I’m reading this right, then I hope you had backups ready :)

Nah, no way. :)

This probably isn’t the answer you’re looking for, but vpr being memory-safe isn’t a benefit that it has over rm, since rm apparently doesn’t allocate any memory (as @radiant_bloom@lemm.ee wrote).

the first thing you mentioned as a benefit was memory safety.

Looks like I worded my project description poorly. As I wrote in another comment, I meant that this alternative is memory-safe (being written in safe Rust), but not that rm isn’t.

edit: I’ve updated the post’s title to clear things up

I guess vpr -x would be memory-safe that way then. ;)

I don’t know whether rm is memory-safe or not, but vpr is. By ‘memory-safe alternative’ I meant that this alternative is memory-safe, but not that rm isn’t.

Matrix/Element isn’t an alternative.

Why not?

And, what about Revolt?

But it’s still possible to give an estimate knowing a little bit about the hardware, right?

Happy to hear that you like it :)