Re: [tor-dev] Consensus-health single-relay data

2018-04-06 Thread Tom Ritter
This now supports exact nickname, partial fingerprint, and multiple of each; and is deployed. Other updates are: - Known flags are not omitted from summary - A footnote is given when an assigning bwauth is not present - the misleading sha-1 signature algorithm is removed - Atlas became Relay Sear

Re: [tor-dev] Consensus-health single-relay data

2018-03-09 Thread teor
> On 9 Mar 2018, at 20:28, Tom Ritter wrote: > > I have tested it on Tor Browser and High Security Slider, seems to > work for me, but I want feedback on the UX and for bugs Wow! It works! And it even works in iOS Safari. Also, there is a feature? where you can keep pasting relay fingerprints

Re: [tor-dev] Consensus-health single-relay data

2018-03-09 Thread Tom Ritter
Please test http://utternoncesense.com/ : check the end of the page. (Note this is a static link, I'm not updating it every hour). I have tested it on Tor Browser and High Security Slider, seems to work for me, but I want feedback on the UX and for bugs. Obviously this doesn't work with js disable

Re: [tor-dev] Consensus-health single-relay data

2018-03-07 Thread nusenu
Tom Ritter: > teor suggested the other day that it'd be really useful to be able to > see the vote data for a single relay; great to see this is being worked on - thanks for that! Previously we also mentioned this feature in the context of onionoo, but processing votes is not something onionoo

Re: [tor-dev] Consensus-health single-relay data

2018-03-07 Thread teor
> On 7 Mar 2018, at 18:22, Tom Ritter wrote: > > teor suggested the other day that it'd be really useful to be able to > see the vote data for a single relay; since the _entire_ detailed page > is huge and unwieldy. > > I've been pondering how I could support this without complicating the > ser

[tor-dev] Consensus-health single-relay data

2018-03-07 Thread Tom Ritter
teor suggested the other day that it'd be really useful to be able to see the vote data for a single relay; since the _entire_ detailed page is huge and unwieldy. I've been pondering how I could support this without complicating the server, which results in a few constraints: a) I really don't wan