Relay operation

Happy Families¶

80% of microdesc size is family-related right now
happy families uses an extra cryptographic key and we group the family by that
is released in 0.4.9.5 and directory authorities are on consensus method 35 for 2 weeks now and thus the happy families feature is enabled
question is when to disable the old family system
- last time ahf looked: 6000 relays have family enabled and 2000 are on happy families already
- it's important though to look at the amount of operators moved over to the new system as well, not just the number of relays supporting it
- applied privacy folks moved already over to the new system
likely 0.4.9.x release where directory authorities would filter out old families
Apple iOS has issues with current long family lists due to memory limit, the happy families would help Tor on that platform as well; the guardian project is interested in seeing this fixed
there is documentation for the new system on our community portal
Idea: metrics port entry for counter of family members and then we could do an alert if suddenly N new relays are supposed to be in the family
we could add a feature as well in Tor Weather where people could get informed if the family (supposedly) has changed
ahf talks a bit about CGO and points to proposal 344 about information leak hazards for Tor and Tor-style implementations
how bad would it hit dir-auths if all or many exit nodes are disabling Guard functionality e.g. by setting DirCache = 0?

contact information field changes we might want to do for arti
contactinfo field is free text right now and folks can add any stuff to it (like where relays are run on, contact methods etc.)
CISS is using this field as well
happy families shows how relays belong to a single entity
who is supposed to validate the CISS-related proofs? directory-authorities?
we think the most efficient and important thing is an email address
in arti we plan to make the contact field email-like
if community wants to use CISS we could still expose this in Onionoo; non-email stuff could go into extra-info descriptors
while we think about changing the semantics of contactinfo we should think about options to reduce the risk of offending nicknames etc.
contact info and nicknames/extra-info etc. could hidden and only available to some WHOIS-like database
- decentralized database could be built as well instead of a centralized Tor Project one
in arti the idea was something like
```
[contact]
email = email@address
```
multi-stage process, first stage arti for contact info, next step could be aiming for reducing exposure of free text field entries or/and it could be validation of email addresses
proposal related to that is "Restrict ContactInfo to Mandatory Email Address" which got sent to the tor-relays@ mailing list on 2023-10-21 together with additional info and links to relevant background information

nothing got mentioned
planned for c-tor is only cleaning up TROVEs and then regular maintenance; maybe we'll add the patch for deprecating old family system
new PQ handshake in OpenSSL might need to get added to c-tor
compression bomb check showed up with log message with high priority; the limit for allowed sizes got bumped form 50KB to a couple of MB
- Idea: fixing that might have made the Tor network more stable; could be worth analyzing whether that's the case