That was one of my thoughts as well. Apart from it being a big and churning list of addresses, STUN will predate the announcement to discovery, since that address is supposed to be in the discovery, so there’s a chicken and egg problem.
That said, I think we mainly use STUN for port discovery? The source address seen by the discovery server should be the same as for the STUN packets presumably, even before STUN is completed… Maybe this would in fact be a workable mechanism, even though it’s a bit heavy handed…
There’s an authentication field we could use in STUN, and we could set a client ID and filter on that, but that’s only effective for new clients…
(There are quite a few packets with a client ID that’s not Syncthing though, StunClient which is the default for at least the Go STUN library, but most seem to be using blank client ID like Syncthing currently does…)