There was the RustConf Reflections Drama…

Tim Chevalier left Rust over Drama. One of the top two contributors at the time.

Well, it startend with conduit. That was a respectable name. The development slowed down and someone wasnt happy abput not getting pr merged. Then it got forked to conduwuit.

Speed picked back up. There was later a massive meltdown for some reason. To successors emerged continuwuity and tuwunel.

Oh I missed that. Oh no. Rolling your own crypto, surely nothing can go wrong.

For a discord or Telegramm alternative it doesnt need to be e2e.

I should have been more clear.

I meant for self hosting.

Though realistically, even if the service is provided for the public, you could just use an instance of keycloak or something similar with open registration. That’s what an association I’m close to is doing already.

By default, the Credentials provider does not persist data in the database. However, you can still create and save any data in your database, you just have to provide the necessary logic, eg. to encrypt passwords, add rate-limiting, add password reset functionality, etc.

That is exactly the complexity I wouldn’t want. With just SSO it is enough to send a redirect URL to the browser and on the callback set a cookie. No js needed. If your service gets compromised and someone leeks the credentials, just log everyone out.

If i created a service I would go in the opposit direction. Only offer SSO and no other option.

You loose quite a bit of complexity that way.

You say you are on a budget. Yet you talk about 128 Gigs of ram.

Maybe you should clarify what your budget is.

Its timing based. When piped a script, bash executes each line completly before taking the next line from the input. Curl has a limited output buffer.

1. Operation that takes a long time. Like a sleep, or if you want it less obvious. A download, an unzip operation, apt update, etc.
2. Fill the buffer with more bash commands.
3. Measure on the server if at some point curl stops downloading the script.
4. Serve a malicious payload.

They can even serve a different file for curl vs curl|bash

I manage all my services with systems. Simple services like kanidm, that are just a single native executable run baremetal with a different user. More complex Setups like immich or anything that requires a pzthon venv runs from a docker compose file that gets managed by systemd. Each service has its own user and it’s own directory.

https://github.com/rust-lang/rfcs/pull/3243

Only the rfc is merged. The others need work including implementations.

If a service doesnt offer Oidc, just dont self host it. The SSO service can then be properly secured and even if its only a password, at least its not reused.

At least in the beginning the scrapers just used curl with a different user agent. Forcing them to use a headless client is already a 100x increase in resources for them. That in itself is already a small victory and so far it is working beautifully.

https://www.phoronix.com/forums/node/1594957

For anyone curious

Somewhere else this was posted the author stated they wrote it themselves, but took grammar corrections from grammarly. That probably created the Ai vibes.

They already got a lot of flak for it there.

Most people expect a domain to work without adding 8080 as a port number in the URL. Hell, I’d say a majority don’t even know that it’s possible.

Consider using Caddy. It is much simpler to setup and all the required headers get set automatically.

There is always the option of waydroid to get android apps running on Linux. It’s not a great solution, but a first stopgap measure to use services only available as apps.

Oh, he was also around that time part of a German party assembly. You know of the party where top politicians say things like. “The Nazis where not that bad” or " The Problem with the holocaust was, that it didn’t finish." That was probably an accident and misunderstanding too.

https://www.tagesschau.de/inland/bundestagswahl/parteien/musk-afd-wahlkampfshow-100.html