Squithrilve

Who said the keys need to be long lived in WKD? WKD just makes the key discovery easier based on email address, you can rotate your key as often as you want (just set the expiry date so clients check it).

Also, I'm not sure if I get the "public ledger" part as WKD I just your own HTTPS server. It doesn't have anything in common with keyservers.

Does anyone know any other good resources (esp. books) on this subject? (Clifford/geometric algebra)

mkinitcpio is being replaced with dracut so zstd won't probably happen.

Google is closing on of their perfectly working services? Who could've imagined such a conundrum!

This is not the only example. I never ceases to amaze me that Google dropped XMPP because of non-mobile-friendliness and it was proven wrong by a single developer (see: Conversations.im).

It seems in a lot of cases Google just want to go on an easy route of creating fake "standards" (AMP) instead of long way of working with broader community for common good.

Maybe that's just me but the Google I remember back when Android was announced and the company it has become now it's like two totally different entities.

> The people who had been using it would continue uninterrupted.

I'm not sure about that. If the main matrix server disappeared today that'd be problematic. Yes, you'd have history locally but the same can be said for any native client that stores history locally.

As far as I know there is no way to migrate matrix history now. Is there? (genuinely curious)

> Someone comes along with a patch or idea. Bunch of big Postgres people come knock it and it dies right there.

This is not unique to Postgres. I've seen this behavior on many development mailing lists (e.g. Mutt-dev).

Poor support of SSL certificates in browsers is commonly attributed to bad UX but the real reason is that they are credentials that can be re-used by multiple services to track you as an individual. Newer standards like U2F completely compartmentalizes origins so that if you register to service X a different service Y will not know who you are.

SSL certificates also doesn't work in HTTP/2 (because of multiplexing multiple requests).

Benefits include storing private key in a hardware tokens, most OSes support them out of the box. You can just plug your token into USB port, visit site that requests a client certificate, enter PIN and be done (e.g. Yubico PIV applet).

HTML also has/had <keygen> element that would generate private key in a browser, send the public key to be signed to a webpage essentially creating private/public key credentials but that is being removed from browsers.

For inter-service communication I'd definitely consider using SSL client certificates pinning private keys e.g. to TPM but regular users can't be bothered with it.

If you're interested check out Token Binding that makes tokens (cookies, etc.) bound to TLS connections essentially providing security of client certificates for tokens.

Every time I read a API that uses signed/authenticated requests (AWS, Let's Encrypt ACME) I wonder exactly the same thing - why is this needed in the first place? If TLS guarantees lack of replays it seems to me like signed requests just protect their own complex infrastructure from reusing the same request twice...