Again please see the above presentation. And yes a central bank could also use Taler, as one of many banks, which would prevent it from being centralised on a single one like in the case of CBDC.

GNU Taler isn’t a currency, its a payment system. And it can be used internationally, you are just completely misunderstanding its purpose and how it functions.

If you would have bothered to see the linked presentation you would know that GNU Taler is explicitly positioning itself as a better international payment standard to prevent central bank digital currencies from taking that role (as commercial banks do not like the idea either).

Its pointless to compare GNU Taler to Bitcoin or other crypto currencies, as it solves a completely different problem space.

https://github.com/lldap/lldap is a good alternative that’s easy to setup.

Did you read the article?

https://github.com/thomiceli/opengist

Does what you want except the auto-delete I think.

If your system is compromised to such an extend, it really doesn’t make much difference how the keys are stored at rest.

With hardware like that the main issues are power inefficiency and (often) lack of UEFI support making it hard to install modern distros on them.

Otherwise there should be mitigations for the CPU issues, so unlikely that it will be a real issue from the security perspective.

It still seems to be under heavy discussion. see this recent article: https://netzpolitik.org/2024/eu-council-discusses-digital-euro-and-how-much-privacy-should-it-be/

I assume the end result will be more privacy preserving than current commercial offers like Visa or Mastercard, but it will be a trade-off between what commercial data-brokers will be able to see and what the central bank will be able to see. Pick your poison I guess 😒

Realistically it might also become so bureaucratic that it will see limited uptake, but specifically for GNU Taler it might make it possible for a Taler intermediatory to exchange digital Euros for tokens in your Taler wallet without having a banking license, which could help Taler adoption a lot. But I guess the latter would depend on how usable the former is. Like if it is too bureocratic, then a separate payment system based on it could thrive, but if it is easy to use, then too few people would probably see the benefit of GNU Taler as an extra step.

The one at the top could also be a connector for a serial port for debugging or so.

https://github.com/fatedier/frp seems to be designed for such cases, but I have not tried it myself.

Lead acid can boil over and fill a badly ventilated room with flammable hydrogen and other toxic gasses.

A well maintained LiFePO4 battery that some modern UPS use it probably less risky, but I think the risk for both is very low.

Yes, don’t expose Windows to the internet 😒

https://opnsense.org/ is a good system if you want an easy to install and open-source firewall.

Edit: no need to buy their official hardware. Any x86 system with two network ports will do.

When you are actively charging the batteries off a solar panel for example, it will be even higher, up to 17V 14.5V or so I think. The automotive PicoPSUs only cost a little more and will smooth it out up to 24V I think… there are even some models that go up to 48V.

Edit: why the down-votes? Is this incorrect?

Some people want to be able to reach their server via SSH when they are not at home, but yes I agree in general that is not necessary when running a real home server.

Get a PicoPSU for automotive use (there are two varieties, one that needs stable 12v and another that can run directly off a battery with varying voltage).

Don’t leave SSH on port 22 open as there are a lot of crawlers for that, otherwise I really can’t say I share your experience, and I have been self-hosting for years.

If you can install a second gigabit NIC into the optiplex it can work very nicely with OPNSense as the main gateway. Then you can connect the LAN side to a simple un-managed switch and branch out to anything further from there.

Edit: OpenWRT is a bit of a pain to manage on x86, so I would try to avoid it for that.

This is nonsense. A small static website is not going to be hacked or DDOSd. You can run it off a cheap ARM single board computer on your desk, no problem at all.

Well then, your assertion that Matrix gives it freely is false.

My point is that it should never give out that data, or even store it permanently in the first place. This is just a fundamentally bad design from a privacy perspective, and other messengers don’t do that.

This is false, too. Historical event visibility is controlled by a room setting. (And if you don’t trust admins of a sensitive room to configure for privacy, then you’re going to have bigger problems, no matter what platform it’s on.)

This is not false, what you mean only hides it for normal users, but it still ends up in the database of all participating homeservers and all the admins of those have full access to it. I happen to run a Matrix homeserver myself…

Obviously you need someone joining the room for the room metadata to be shared between homeservers. But that is really only a minor barrier and once that has happened the worst case scenario takes place immediately. On other messengers (federated or not) a newly joining member has very limited access to past room metadata. Not so with Matrix, where a joining homeserver get full retroactive access to all the room metadata since the room’s creation. If you can’t see the problem with that, you really need to stop privacy LARPing 🙄