Opened 5 weeks ago

Last modified 8 days ago

#33008 merge_ready enhancement

Display a bridge's distribution bucket

Reported by: phw Owned by: metrics-team
Priority: Medium Milestone:
Component: Metrics/Relay Search Version:
Severity: Normal Keywords: s30-o24a1, anti-censorship-roadmap-2020Q1 metrics-team-roadmap-2020Q1
Cc: arma, cohosh, gaba Actual Points:
Parent ID: #31281 Points: 2
Reviewer: Sponsor: Sponsor30-can

Description

Bridge operators often want to know what distribution bucket their bridge fell into. Since #29480, one can find out by inspecting our archived bridge pool assignments but that's cumbersome and not user friendly. We should instead show the bucket on the bridge's relay search page. How can we get this done?

Child Tickets

Attachments (1)

mockup.jpeg (247.8 KB) - added by phw 4 weeks ago.
Relay Search mockup

Download all attachments as: .zip

Change History (14)

comment:1 Changed 5 weeks ago by arma

I am excited about this one, because it's the culmination of all the back-end work: just having the data in a data set is a good step zero, but giving it to users (bridge operators) in a usable way is where it all needs to lead.

comment:2 Changed 5 weeks ago by karsten

Here are the steps for getting this done (with very rough estimates with 1 point == 1 workday):

  1. Decide where to add bridge distribution information on Relay Search. For example, would we simply want to display something like "https ip=4,6 ring=2 transport=websocket,fte,obfs3,scramblesuit,obfs4", or would we want to structure that information somehow for the user or leave out less relevant parts? (0.5 points)
  2. Specify one or more fields to be added to Onionoo's bridge details documents, following requirements from the first step above. (0.25 points)
  3. Extend Onionoo to fetch bridge pool assignments from CollecTor, store the latest bridge pool assignment for each bridge in its details status document, and write this information to the bridge's details document. (1 point)
  4. Add bridge distribution information to Relay Search as specified in the first step, using the data from the updated Onionoo protocol version as specified in the second step. (0.25 points)

I can do steps 2 and 3, and irl should do (or review) steps 1 and 4.

comment:3 Changed 5 weeks ago by phw

Once this is done, we shouldn't forget to update our documentation. We want to tell people how they can learn their bridge's distribution bucket, and what they can expect for a given bucket.

comment:4 Changed 4 weeks ago by irl

This sounds like lots of things coming together nicely, we should close this loop.

On step 1, could an anti-censorship person come up with an MS paint quality mock up of what data should go where? I'm not familiar with how this works exactly or what bridge operators may have for context.

Happy to do step 1 with that input, and step 4. I can also review 2 and 3, some of the input on step 1 should feed into step 2.

Changed 4 weeks ago by phw

Attachment: mockup.jpeg added

Relay Search mockup

comment:5 Changed 4 weeks ago by arma

I agree, this mockup is what I was going to suggest too.

And then the "https" should be a link to an anchor in an external document that the anti-censorship team maintains, which has anchors for each distribution strategy.

(Actually phw, do you want the word 'bucket' or should we go with something like 'strategy' so we won't be explaining to everybody why it's a bucket?)

comment:6 in reply to:  2 Changed 4 weeks ago by phw

Replying to karsten:

  1. Decide where to add bridge distribution information on Relay Search. For example, would we simply want to display something like "https ip=4,6 ring=2 transport=websocket,fte,obfs3,scramblesuit,obfs4", or would we want to structure that information somehow for the user or leave out less relevant parts? (0.5 points)


I suggest only displaying the bucket, which would be https in your example. We're already displaying the supported transport protocols in a separate field and I don't think it's useful to expose the BridgeDB ring. That said, here's a simple mockup:

Relay Search mockup

comment:7 Changed 4 weeks ago by karsten

Status: newneeds_review

Okay, if it's just the distributor bucket/strategy that we want to display, the Onionoo side is relatively simple. Please review commit 633aa3e in my metrics-web task-33008 branch for step 2 above and commit ff2db94 in my Onionoo task-33008 branch for step 3 above.

comment:8 in reply to:  5 ; Changed 4 weeks ago by phw

Replying to arma:

And then the "https" should be a link to an anchor in an external document that the anti-censorship team maintains, which has anchors for each distribution strategy.


That's a good idea. This could be a new page on BridgeDB, e.g., bridges.torproject.org/info.

(Actually phw, do you want the word 'bucket' or should we go with something like 'strategy' so we won't be explaining to everybody why it's a bucket?)


I would suggest "bridge distribution mechanism".

comment:9 in reply to:  8 Changed 4 weeks ago by arma

Replying to phw:

(Actually phw, do you want the word 'bucket' or should we go with something like 'strategy' so we won't be explaining to everybody why it's a bucket?)


I would suggest "bridge distribution mechanism".

Sounds great to me.

comment:10 Changed 3 weeks ago by gaba

Keywords: anti-censorship-roadmap-2020Q1 added

comment:11 in reply to:  7 Changed 9 days ago by irl

Status: needs_reviewmerge_ready

Replying to karsten:

Okay, if it's just the distributor bucket/strategy that we want to display, the Onionoo side is relatively simple. Please review commit 633aa3e in my metrics-web task-33008 branch for step 2 above and commit ff2db94 in my Onionoo task-33008 branch for step 3 above.

LGTM.

The bridge model will need to be extended in relay search, and an extra row on the table. If you want to have a go at that it should be an easy change.

comment:12 Changed 9 days ago by gaba

Keywords: metrics-team-roadmap-2020Q1 added

comment:13 Changed 8 days ago by karsten

Points: 32

Onionoo patch merged, released, and deployed. metrics-web patch rebased and extended by that easy change to put into Relay Search, and deployed. Please give it a try!

What remains is that "https" and the other distribution mechanisms link to an anchor in an external document. As far as I can see, that page would need anchors for "email", "https", "moat", and "unallocated". Ideally, anchors would be the exact strings as these distribution mechanisms, like https://bridges.torproject.org/info#unallocated.

Should that be a new ticket, or is creating that page a quick task on your side?

Note: See TracTickets for help on using tickets.