Can a client and server use different congestion algorithms when communicating?

I'm writing a http3 (which runs on quic) library, and there's a requirement of choosing different congestion control algorithm by caller. I did some Research and read this:

There are several variations and versions of the algorithm implemented in protocol stacks of operating systems of computers that connect to the Internet.

I suddenly notice that I'v never thought about how a congestion control algorithm really works (on tcp) before, besides some abstraction theory. So here are some questions which are not very clear to me.

1. Can a client and server use different congestion algorithms when communicating? For example client use the Reno and the server use the CUBIC?
2. If yes, this is any disadvantage that client and sever use different algorithms?
3. If no, how do the server and client negotiate an congestion control algorithm?

1. Yes, congestion control only affects the path from the sender of data to the recipient. There is no coupling between what congestion controller the 2 peers use. The only thing a congestion controller needs to work properly is ACKs from the peer, and those are sent independent of the congestion controller that peer uses.
2. No. It's common
3. There doesn't exist any negotiation (and even no advertisment). You won't know what congestion controller the peer uses. You might just be able to guess it based on its transmission behavior.