Again for Germany, it’s handled by a single provider, and they absolutely do utilize CoCo tech. (Source: I work at one of the involved companies, sorry, not going to be more specific)

In the case of Germany: confidential computing tech ensures all data is encrypted in storage and in memory, shielded even against data center employees / hosting providers. I imagine that’s become the standard for most countries.

When we need to know each others location, we share it via element / matrix. Our own server, so no third party.

Happens maybe four times a year.

(Also, do you just always have location services enabled?? IMO it’s a battery drain, I pretty much only enable it for this and while I need to navigate)

Ah, nice. In that case just beware to move /var/lib/private/conduwuit to /var/lib/private/continuwuity, not /var/lib/conduwuit to its counterpart

Ah crap, forgot to ping you! Sorry!!

Yep, easy decision now. Migration went smoothly, just had to move the state dir and chown it to continuwuity:continuwuity. Might be different on docker though, no idea, sorry 😄

Update: seems to me tuwunel is drama waiting to happen. See updated post for details.

Yes, completely agree. It seems that the matrix foundation could easily take a different path to allow the community to flourish and third-party servers to have a much easier time. Since I’m not federated, I wouldn’t even mind if whatever fork I’ll end up on eventually says “fuck this, we’re not following synapse specs any more”.

But yeah, I am sure selling premium accounts on matrix.org is what will save the matrix ecosystem… 🤦🏼‍♀️

Understandable.

Hm, fair enough, I actually have very little experience with XMPP. (Only through prosody, which I personally am on a war footing with.) From a cursory glance, I also couldn’t find an Android lient I’d really want to use, but of course that is subjective.

In any case: I have a matrix server up and running, and it has been a pain to get friends and family on there; I do not want to do all of that again with a new protocol/clients. As long as it’s sustainable, I want to stay with the same server installation, and that means choosing a conduwuit for me.

There’s nothing technically wrong with it, it’s just a glacial development speed. I tried contributing there myself when I wanted a specific feature (which had been requested years prior by someone else and was deemed a good idea), it took months before I even got a single comment back.

In the meantime, I had switched to conduwuit because it was a much, MUCH more active project. However, conduwuit has diverged substantially from conduit, including irreconcilable database changes, so it is not possible to migrate back, that would require starting from a fresh slate and loosing all user data.

Understandable. Funny thing is, I’m not even federated; I think that keeps me away from a lot of drama.

But yeah. The drama sucks, and so does the Matrix Foundation. So many dumb decisions, so many years old issues that could easily boost acceptance and usability, but… Nah. No better alternatives around though if you want to own your data, have proper multi-client support, and at least the option to federate.

Nice, how’s it been going?

Roger, will do.

Yeah, community driven sounds like unless there’s new drama. But yeah, currently tending towards continuwuity. Purely vibes based from snooping around both repos.

We have NixOS, Proxmox and TrueNAS in use.

• TrueNAS on a dedicated NAS host. It’s great for that, and has been super stable. The snapshotting works great, and all the little tasks associated with a NAS are taken care of without needing to spare a thought.
• Proxmox as VMS host. You haven’t mentioned it above, so I’ll leave it at this: also works really well for its purpose.
• NixOS: acouple dozen NixOS VMs runnign on the Proxmox hosts. I like the separation (i.e.: one VM <-> one task/service), but it’s not necessary, esp. if you plan on using a stable branch. I absolutely love NixOS, and would never run server applications on anything else ever again. The documentation thing is trueish. There’s not even close to the same documentation as with e.g. Arch and the Arch Wiki, but that makes sense when you think about it: instead of hundreds of lines of documentation, you hide that complexity behind an option, e.g. graphics.nvidia.enable = true; which then becomes pretty self-explanatory, at least if you are somewhat familiar with the ecosystem already. The way I’d recommend going about documentation with nix is this:
  • go to search.nixos.org/options, search for the service you would like to host. 90% of the time, the options and descriptions shown are all you need.
  • if an option is unclear, click on its “declared in” link. You’ll be taken to the module source in nixpkgs. Look at what they are doing there/the comments explaining why. Often, this resolves any ambiguity, or helps you out with your goal.
  • if that did not help, check the NixOS wiki; often, common pitfalls are documented there, together with the nix expression to fix them.
  • another great way is to search GitHub for language:nix <thing you need to do>. As a random example: I recently wasn’t sure how to configuring scaling in hyprland on NixOS, but searching for an appropriate term will quickly show you how other people have solved the same problem. It’s not really documentation, but the declarative nature of nix means it’s easy to find TONS of working examples via a github search.
  • all else failing, ask on discourse.nixos.org. Youńll usually get useful help very quickly there.

So, what’s my advice?

If you are unfamiliar with NixOS, it’s probably a bit of a headache getting a NAS to run satisfactory. Truenas works so well, there isn’t really a need for nix. But running your services in nix is great, totally recommend!

Not sure, but they also support Borg, which definitely does.

Btw, nice read OP. Always great to see more Nix “in the wild”.

Yeah, but no dark magic involved.

• build image
• copy to proxmox ISO store
• import, resize disk
• start, wait to come online
• read ssh pubkey, save it
• rekey secrets
• rebuild VM

The only “magic” parts are two nix modules for handling proper networking and hardware setup, and exposing required attributes to the script.

Works really well, zero manual config (beyond the services you want to run…) required on nix or proxmox side.

Nothing. People fearmonger

Funny - same thing here. Got 3 proxmox hosts running, all virtual machines are NixOS though.

I’d love to go full Nix, but between my GF and I, we kinda split the responsibilities: hardware is hers, applications are mine. And there’s not a chance she’ll give up her Proxmox hosts 😄

Got it automated to a single “provision” command though that will spin up any of my nix VMS unanttended, so I’m happy with that.

Semmel