[tor-dev] Roster introduction

2015-07-02 Thread Virgil Griffith
Hello everyone. This is my first report on the Roster project and I wanted to give you all an introduction what it is and where it's going. I'm interested in seeing Tor grow. Current work towards this is tor2web and now Roster. Roster is the rebranded continuation of the "Torati" proposal which

Re: [tor-dev] Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth

2015-07-02 Thread l.m
So I guess I should go back to the original issue posted in this thread. It hasn't been addressed if the (bi-directional family) concern is actually data from Onionoo or operators that just don't declare families. The view from Onionoo--based on consensus, taking into consideration caching and othe

Re: [tor-dev] Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth

2015-07-02 Thread Karsten Loesing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/15 15:07, l.m wrote: > >>> One proposal I've liked is to socially discourage asymmetrical >>> families by giving them with bad badges on Roster. If A says B >>> is part of their family but B doesn't reciprocate, A gets a >>> penalty to thei

Re: [tor-dev] Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth

2015-07-02 Thread l.m
>> One proposal I've liked is to socially discourage asymmetrical >> families by giving them with bad badges on Roster. If A says B is >> part of their family but B doesn't reciprocate, A gets a penalty to >> their bandwidth points. > Maybe don't go as far as penalizing relay operators for attem

Re: [tor-dev] Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth

2015-07-02 Thread Karsten Loesing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi leeroy and Virgil, I'm replying inline. On 02/07/15 14:06, Virgil Griffith wrote: > One proposal I've liked is to socially discourage asymmetrical > families by giving them with bad badges on Roster. If A says B is > part of their family but B do

Re: [tor-dev] Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth

2015-07-02 Thread Virgil Griffith
One proposal I've liked is to socially discourage asymmetrical families by giving them with bad badges on Roster. If A says B is part of their family but B doesn't reciprocate, A gets a penalty to their bandwidth points. I think right now the proposals are to either: (1) move forward using Obser

Re: [tor-dev] Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth

2015-07-02 Thread l.m
The major problem with ticket 16276 is that it isn't a fix (as you seek here). It just moves the current implementation into the details document rather than being done in the node index. I don't think you *can* fix it as you seek. Bi-directionality isn't an enforceable property. The spec makes no

Re: [tor-dev] Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth

2015-07-02 Thread Aaron Gibson
On 2015-07-02 08:12, Karsten Loesing wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moving this discussion here from another list with Virgil's permission. On 02/07/15 08:42, Virgil Griffith wrote: Big issues right now are: * Bugs (?) in Onionoo --- Onionoo doesn't sanitize its data. Fo

[tor-dev] Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth

2015-07-02 Thread Karsten Loesing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moving this discussion here from another list with Virgil's permission. On 02/07/15 08:42, Virgil Griffith wrote: > Big issues right now are: * Bugs (?) in Onionoo --- Onionoo doesn't > sanitize its data. For example, there's a lack of bidirectionali