<span style="font-family: Arial; font-size: 13px;"><br>>> One proposal I've liked is to socially discourage asymmetrical<br>>> families by giving them with bad badges on Roster.  If A says B is<br>>> part of their family but B doesn't reciprocate, A gets a penalty to<br>>> their bandwidth points.<br><br>> Maybe don't go as far as penalizing relay operators for attempting to<br>> configure a relay family and not succeeding at it.  Keeping family<br>> configurations updated is not exactly trivial.  And if the effect is<br>> that relay operators stop configuring families at all, that's not what<br>> we wanted, either.<br><br>> It would be good to point out configuration problems with family<br>> settings and help operators debug them easily.<br><br>If my understanding of this is correct, doesn't this also have problems with proof-of-operator? That is, exactly as the current case, there's no inherently reliable way to prove that if A declares B and B doesn't declare A, that there *should* be a bi-directional relation. Other properties of a node/relay only go so far in proof-of-relation. The existence of a bi-directional relation is only taken as a hint for path selection. Given X and Y are chosen and have a bi-directional relation, discard one based on the first chosen.<br><br>> I started implementing something here and will report back on the<br>> ticket as soon as I'm more convinced that it works.<br><br>No hints?<br><br>Regards<br>--leeroy<br></span>