Do we need to keep relay latency on the discovery server? The general principle is that the client picks a relay it likes (low latency), announces that or those, and the other side selects from those based on it’s latency measurement, right?
Well, you join all relays regardless of latency. The reason I send the latency is to deal with asymetric links.
Given node A and B, relays X and Y, it’s possible that:
A latency:
X - 2000ms routed via satellite
Y - 100ms
B latency:
X - 5ms
Y - 100ms
In this case it would be correct for B to choose Y and not X as the overall latency is lower.
Gotcha
Do we need to close the connection on successful invitation?
https://github.com/syncthing/relaysrv/blob/master/listener.go#L162
Yes, because this is the protocol connection, not a session connection, we have to reconnect without tls to actually join the session which we’ve requested to create.
A and B. A advertises he’s on relay, establishes a permanent connection (tls - type protocol) to the relay. B finds A on a relay via discovery. B connects to relay (tls - type protocol), says can I speak with A, relay sends A and B an invitation, disconnects B (as it’s only checking wether or not A is there), A stays connected for any future invitations.
A and B read invitation, connect to the designated port on the relay (non tls - type session), send relay the invitation keys (which starts proxt), starts tls handshake (wether server side or client side defined in the invitation).
Possible optimization would be for B to use the protocol connection if its also a permanent client on the relay.
But can’t we have a persistent protocol connection, and just add session connections on the side as they are required?
I’m very deep down in the discovery rabbit hole now 
The point is that B might not be a client, and just passer by which doesn’t want to get connected to, just connect to others.
If he is a permanent client, yeah we could optimize.
Ah. I think I get it.