[tor-dev] Questions regarding the future of families

nusenu nusenu at openmailbox.org
Sat Mar 5 00:48:09 UTC 2016

> Regarding the state of family support.  I've been working on a project
> which could be used to expand the number of running relays and have been
> trying to find the best way to coordinate this so as to make it both
> obvious who the operator is (which can be done with contact info) as well
> as to help users avoid building circuits within these related nodes.
> In the vein of "playing nicely" with the network my concern is that when
> running large scale infrastructure one needs to minimize the number of
> moving pieces possible. Ideally this would allow me (in the best case
> scenario) to supply a static family identifier en masse minimizing the need
> for managed configurations.
> In the worst case scenario (that of an entity trying to launch a sybil
> attack) the administrator would not even attempt to populate this so as to
> try and appear as separate nodes in the network.
> Do folks have suggestions on the best way to "play nice" here?

So you want to have a proper MyFamily configuration across a very high
number of relays without reloading them all every time you add a new
relay? Why are you worried about these reloads?

The only way I can think of is to preemptively create relay keys.

Lets say you are about to deploy 100 relays within the next week.
First you would create 100 relay keys and collect all fingerprints to
form the MyFamily string. Then you could use that static string and no
reload is required as long as you do not run more than 100 relays.

Depending on how much "idle/spare" fingerprints are in your MyFamily
string this might also costs the network an unnecessary overhead.

So adding fingerprints to MyFamily on demand is probably nicer than
creating huge descriptors with spare fingerprints just because you do
not want to reload your tor instances.

@"minimizing the need for managed configurations"

If you run "large scale infrastructure" you usually want to have
"managed configurations". No one wants to manage many servers manually.

Please consider AS and geo diversity when adding a significant amount of
tor bw and maybe set yourself an upper boundary as to how big you want
to grow.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160305/52fb0e1a/attachment.sig>

More information about the tor-dev mailing list