Vanilla 1.19.1-pre2 server, modded Fabric client with NCR 1.3.0.

1. Start the server with enforce-secure-profile=true
2. Join with the client and, check the checkbox and proceed with the warning. Verify the icon next to chat - it is red
3. Restart the server with enforce-secure-profile=false
4. Join with the same client, verify the icon next to chat - it is still red
5. Join the same server via different host (e.g. ip instead of domain or vice-versa)
6. Verify the icon - it is yellow as it should
7. Remove the original host from whitelist, restart the client
8. Join the original host
9. Verify the icon - it is yellow as it should

Unfortunately, the only way for client to know whether the server has enforce-secure-profile enabled or not is to try joining without sending it account's public key and see if it gets kicked. When the server is whitelisted - client will always send its public key, in order to save you from going though warning screen every time. Right now there is no way to work around this beyond manually tweaking the config or changing how host address is spelled, but I will leave this open in case things change in future, or someone suggests a solution that I did not think about.

Although, I have an idea that might work...

Alright, so, the way in which I got it to work is as following: when you first try to connect to whitelisted server, the client will try to refuse sending its keys. If it gets disconnected because of that, it will immediately try to reconnect again, this time exposing its keys. Server safety status will be updated depending on whether this second reconnect was necessary. If second reconnect fails (for whatever reason), it will leave you alone with disconnected screen (no endless reconnection loops should happen).

The side effect of this implementation is that logging into whitelisted servers with enforce-secure-profile enabled will take slightly longer, but since the server will disconnect you before sending any data about chunks/players/other heavy stuff first time - it should not be a problem. The benefit is that you will be updated on server safety status.

Hmm okay, that approach seems fairly reasonable. Maybe add an interval though, like one check every 24h?

Maybe add an interval though, like one check every 24h?

Don't think that's necessary considering negligible amount of networking overhead involved, but I will consider if people will have complaints about this.