[tor-relays] Re: Reducing ContactInfo to the family ID level

[Sebastian Hahn via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx>]

Hi,

> On 10. May 2026, at 11:10, nusenu via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> wrote:
> since we have a significantly less
> cumbersome and much less error prone way for tor relay operators
> to self-declare their relay groups using the Happy Family design
> I was thinking about whether we actually need ContactInfo
> at the relay fingerprint level or if we only need it at family ID level?
> 
> The idea:
> - only a single relay in a family publishes a ContactInfo that is valid for the entire family
> 
> benefits:
> - easiers ContactInfo management for relay operatos not using configuration management, since they only need to update a single config
> - less redundant information in relay metadata that gets received and distributed by tor directory authority
> - significantly smaller onionoo details files
> 
> downsides:
> - no "backup channel" in case software has Happy Family related issues - like we saw in collector/onionoo
> - less flexibility you want to have different contacts for different servers
> 
> 
> I do not expect that rust-based tor relays - that hopefully significantly reduce the number of tor daemons an operator
> has to run to make use of multi-core CPUs will take over the tor network soon.
> So this will remain a relevant question for the time being.
> 
> This topic is limited to relays and not bridges until bridges fully support Happy Family.
> 
> If there are no strong reasons for relay level ContactInfos I might implement the idea in a minor variation in ansible-relayor:
> only a single tor instance per server will get a ContactInfo torrc entry.
> The CIISS spec would also be updated to reflect that.

thanks for thinking about the design space more! For this concrete idea,
I am not a fan, however:
- For external parties, it may be harder to link a relay to its contact
  info
- If, for whatever reason, the relay carrying the contact information
  is missing from a consensus, there is no link to retrieve this
  information

Have you done some analysis how much bandwidth this would save in
practice? I would hope compression actually takes care of the bulk of
the problem for larger families, but I am not entirely sure of that.

Thanks
Sebastian

_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx