Rather pointless to compare the SSL certificate to a hash ofcourse. Why not just compare it to a copy of the certificate. No need to obfuscate and allow user to be fooled with changed hash.

The hash is a lot smaller and less likely to be subject of a copy-paste error ¯\_(ツ)_/¯

How does expiration work? What happens if an TLS/SSL cert is leaked/compromised? Change the clients as well?

Since only the keypair is cached, certificates are generated on each startup. This means they never expire (unless you run your application without any interruptions for a whole year).

But yeah, if they're leaked you just gotta re-send them to the clients. This isn't meant for large professional projects, only for stuff where the convenience outweights the pros of using a proper certificate.

You would probably need some sort of "authority" to redistribute the hashes.

The was / is a DNS standard for that: DANE. Sadly DANE was never really adopted. Chrome had support for it but it was removed eventually.

One of the main reasons for the library is no need for cert authority. Why not just create a regular cert Authority certificate and put the trusted authority cert on the clients. That makes it so you almost never have to change the clients certs. Also, it's supported by standard TLS libraries and clients.

True, didn't think of that. The server would still have to generate it using a command though... I like having things automated.

Pretty much same story as SSH keys and fingerprints.

I’m confused, domains are not a barrier to entry (I’d argue that the developer account is a much larger barrier). Why is this a needed thing?

Not sure what you mean by developer account...

Anyway, if I understand correctly, this is basically just a user friendly version of certificate pinning.

Oops! For some reason I thought it was Swift at first. My bad, I understand it a bit better now then :).