Yes there were significant portions that were proprietary before this, including support for some services.

The parts that were open source might still be worth forking, but you would probably need to change every occurrence of the name to avoid trademark issues.

I can think of a of other ways that client certificates could work, but they have problems too:

1. Use DANE to verify the client certificate. But that requires DNSSEC, which isn't widely used. Would probably require new implemntations of the handshake to check the client cert, and would add latency since the server has to do a DNS call to verify the clients cer.

2. When the server receives a request it makes an https request to a well known enpdpoint on the domain in the client-cert's subject that contains a CA, it then checks that the client cert is signed by that CA. And the client generates the client cert with that CA (or even uses the same self-signed cert for both). This way the authenticity of the client CA is verified using the web PKI cert. But the implementation is kind of complicated, and has an even worse latency problem than 1.

3. The server has an endpoint where a client can request a client certificate from that server, probably with a fairly short expiration, for a domain, with a csr, or equivalent. The server then responds by making an https POST operation to a well known enpdpoint on the requested domain containing a certificate signed by the servers own CA. But for that to work, the registration request needs to be unauthenticated, and could possibly be vulnerable to DoS attacks. It also requires state on the client side, to connect the secret key with the final cert (unless the server generated a new secret key for the client, which probably isn't ideal). And the client should probably cache the cert until it expires.

And AFAIK, all of these would require changes to how XMPP and other federated protocols work.

> Fair enough but are network clients actually meant to use DNSSEC?

I dream of an alternate reality where DNSSEC and DANE had become more ubiquitous, and we didn't have need for CAs to sign TLS certificates[1]. But that requires DNSSEC (or some other cryptographic verification) on the client.

[1]: Or something like that. In that mythical world maybe DNSSEC was also better designed...

I want a separation between the streaming platform companies and the content making companies, so that the streaming companies can compete on making a better platform/service and the content companies compete on making better content.

I don't want one company that owns everything, I want several companies that are able to license whatever content they want. And ideally the customer can choose between a subscription that includes everything, and paying for content a la carte, or maybe subscriptions that focus on specific kinds of content (scifi/fantasy, stuff for kids, old movies, international, sports, etc.) regardless of what company made it.