corver
corver
Ok cool, I'll give it a shot. Here is my proposed solution: - Clean "relay constraints" on disconnect. - Update "relay constraints TTL" when reservations are refreshed - Deprecate "MaxReservations"...
Why don't we add it to the lock file rather? Make it part of the protocol properly. CLI flags is very loose, people will change it over time and joke...
100 chars is also too long imo, it doesn't display nicely in grafana and people will write sentences. Suggest 32 chars.
another term could also be `nickname`, feels a bit simpler and more approachable to non-english speakers.
I'd also suggest we not try to "replace" existing `cluster_peer` names, as that will just result in a mess in grafana as timeseries chop and change, deduplicating is impossible I...
Note my suggested solution: - Add a optional `--nickname` string flag - Share that with peers via `peerinfo` protocol - Add `app_peerinfo_nickname` constant metric with nickname label (including own)
Note that adding this to the lock file is still the best solution as then it is also supported by DKG, see #1912. Requiring users to add consistent moniker fields...
Charon isn't responsible for the the network spec, it just passes whatever the BN provides to the VC. So this is configured in the BN, not in Charon.
Where should this document be created? Should it only contain Lighthouse and Teku?
Pushing back since we should probably include the checksums and hashes. And @OisinKyne mentioned that is not priority right now