[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-relays] Re: Reducing ContactInfo to the family ID level
On 10/05/2026 11.10, nusenu via tor-relays wrote:
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.
Hello Nusenu,
Interesting conversation here! I'm not a huge fan of this for a number of
reasons that I am trying to list here:
This setup assumes that everybody does all their processing with an
Onionoo(-like) service around (like yourself): for people who aren't using
Onionoo (or who are building Onionoo itself), you will likely need to store a
dictionary that maps families to ContactInfo for longer period of time, in case
the family shows up again after being gone for a while?
For people who are "just" consuming Onionoo data, you now need to parse the
entire Onionoo data into memory and store the state there before you can query
ContactInfo properties for a given relay because you may need to look up the
data from another relay here. This impacts people using Onionoo with its "limit"
and/or "search" feature, where you now need to do multiple queries inside the
family to figure out the ContactInfo? Or is this also a feature request to
Onionoo to have it handle this `MyContact` "presence" and do some kind of
rewrite for each query response such that all family sets at maximum have one
ContactInfo response included the query result set?
IMO, one of the wonderful properties with configuration management tools, such
as Ansible here, is that you can easily go from "I've set this $thing up on host
A" to "I can set $thing up on N hosts". With the proposed design here, the
configuration management system now needs to support some kind of "one-of-N"
configuration, where one host gets configuration X and everything else gets
configuration Y? Which relay gets the ContactInfo here?
What happens if the relay that publishes ContactInfo, on behalf of a family, is
down for an extended period?
IMO, we need to be careful with data (re-)modeling and avoid "reducing" $things
unless there are good reasons. Especially when it adds complexity elsewhere.
What are the reasons that you think it would be useful to have smaller Onionoo
"details" files? Is it disk storage space that is a problem? Is it download
time? Wouldn't using stronger compression algorithms help here if size is the
issue? Or is processing time the issue? Then perhaps JSON is the issue?
I cannot parse what problem it is you're facing from either the "idea", the
"benefits," or the "downsides" here. If it's any help, we still have the data up
that we used to evaluate compression algorithms during Sponsor 4 in ~2017
here[1]. These days, Brotli with custom dictionaries would likely be a better
choice here.
I feel that we often see the "ContactInfo" related problems appear out of of the
unknown, with little context for what problem they are trying to solve, but with
plenty of solutions. I think it would be helpful if we had more conversations
about the problem space as that is likely signficantly more interesting than the
solution space here :-)
Cheers,
Alex
[1]:
https://docs.google.com/spreadsheets/d/1devQlUOzMPStqUl9mPawFWP99xSsRM8xWv7DNcqjFdo/edit
--
Alexander Hansen Færøy
_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx