Make various UI improvements

added component::metrics/compass owner::metrics-team priority::medium resolution::wontfix severity::normal status::closed type::enhancement labels

Replying to grarpamp:

Thanks for your suggestions. Please note that Compass is pretty much unmaintained these days. But it might be that we're going to integrate part of Compass' functionality into Globe. That's why I reply to the suggestions below. Also cc'ing the Globe author.

Would be nice to have a checkbox: 'Select only non-exit relays'

Makes sense.

I'd also rework the speed/network radio to be independant of whichever non-exit/exit relay type is chosen. Since non-exits don't have ports, ports should be unrolled from speed/network to fit that context as well. ie:

heading: params (was: exits) radio: all relays (default) radio: select relays by param subheading: speeds radio: rateA (default) radio: rateB subheading: port sets radio: full (default) radio: reduced radio: sponsored subheading: /netsize restrictions radio: ...

The whole "fast exits" part needs to go away. It was only added because we had a sponsor who wanted us to set up fast exits with certain criteria. But that sponsor contract ran out, and now the fast exit selection is cluttering the interface. So, the entire part under "Exits" should go away.

'K' is not a valid SI/ISO-IEC prefix, please correct this to use 'k' (x10) or 'ki' (power2). https://en.wikipedia.org/wiki/Binary_prefix

Agreed. Not relevant with the fast exit part going away and with integrating the rest of Compass into Globe. (Nitpick: the power2 prefix is 'Ki', not 'ki'.)

'95+ , 5000+ ' - Add description of what these two paired numbers mean (currently seen in three places).

Not relevant anymore with the fast exit part going away and with integrating the rest of Compass into Globe.

Add blurb that terms '[non-]exit, running/inactive, guard' refer to specific thing of 'flags'.

This suggestion is rather specific to the current Compass interface. Also, I'm unclear whether additional blurbs are going to make things clearer to the average user or confuse them even more. Most users will understand what an "exit" is, but not what an "Exit flag" is. So, not sure whether this suggestion is going to make things better.

Trac:
Cc: N/A to rndm

it might be that we're going to integrate part of Compass' functionality into Globe.

Since they all draw on Ooo, I'd merge compass, globe and atlas all into globe. You'd need to sort out the UI, and access to graph sources (maybe that's in Ooo too, haven't looked API yet.) https://metrics.torproject.org/tools.html

'Select only non-exit relays' Makes sense.

I wanted to look at internal bandwith vs external.

heading: params (was: exits) So, the entire part under "Exits" should go away.

I knew the sponsor thing. You'd likely want to make some selectable params anyway, like looking at bandwidth available to different portssets. Put it under and 'advanced' screen.

(Nitpick: the power2 prefix is 'Ki', not 'ki'.)

Typo, unlike comments, OP's can't edit their own ticket headline or description.

So, not sure whether this suggestion is going to make things better.

It's a meh.

https://www.torproject.org/projects/onionoo.html 'torstatus websites' here is a dead link. blutmagie, rueckgr and hermetix might be the last.

The Ooo INSTALL docs may want to create a way to not sync historical from tpo, but just collect ongoing from local Tor process as can be.

Replying to grarpamp:

it might be that we're going to integrate part of Compass' functionality into Globe.

Since they all draw on Ooo, I'd merge compass, globe and atlas all into globe. You'd need to sort out the UI, and access to graph sources (maybe that's in Ooo too, haven't looked API yet.) https://metrics.torproject.org/tools.html

You're welcome to help with the merging or testing of merged Onionoo clients.

'Select only non-exit relays' Makes sense.

I wanted to look at internal bandwith vs external.

That's actually not as simple as comparing relays with the Exit flag to relays without it.

heading: params (was: exits) So, the entire part under "Exits" should go away.

I knew the sponsor thing. You'd likely want to make some selectable params anyway, like looking at bandwidth available to different portssets. Put it under and 'advanced' screen.

Agreed.

(Nitpick: the power2 prefix is 'Ki', not 'ki'.)

Typo, unlike comments, OP's can't edit their own ticket headline or description.

Okay.

So, not sure whether this suggestion is going to make things better.

It's a meh.

Okay.

https://www.torproject.org/projects/onionoo.html 'torstatus websites' here is a dead link. blutmagie, rueckgr and hermetix might be the last.

Thanks, updated.

The Ooo INSTALL docs may want to create a way to not sync historical from tpo, but just collect ongoing from local Tor process as can be.

Onionoo requires historical information to be useful. Also, it wouldn't learn stuff like sanitized bridge descriptors, BridgeDB's pool assignments, or exit lists from a local Tor process.

You're welcome to help with the merging or testing of merged Onionoo clients.

Feedback coming from Ooo install as I get there.

'Select only non-exit relays' Makes sense. I wanted to look at internal bandwith vs external. That's actually not as simple as comparing relays with the Exit flag to relays without it.

Sure, Exit flag is a heuristic. So that means we need checkboxes for at least, and all of:

exit
non-exit
reject : (never-exit)

And then you might be able to calc further and subtract bw of the first two from the latter mod 3hops and get idea of free bw in the core (mod 3 and 6 hops, split and allocate by current exit:core ratio). That's more of a metrics thing, but needs Ooo to group the relays, so might as well add the groups to the UI.

Thanks, updated.

torstatus.all.de seems dead, though it may be me, or waiting on website push.

Onionoo requires historical information to be useful. Also, it wouldn't learn stuff like sanitized bridge descriptors, BridgeDB's pool assignments, or exit lists from a local Tor process.

Yes, some data at tpo is not accessible to third party instances, whether by policy or lack of API. The idea is for others install Tor, Ooo and the webUI, and start generating and publishing their own data (historical from their own 'day one'). The tool should display what it is able to collect locally, even if that means some block features (as you mention) are necessarily disabled.

Reflect in the summary that this ticket is about a little bit of everything. And it's probably moot anyway, because Compass is even less maintained now than 3 years ago. But let's keep it open for now. Maybe some of the ideas here can survive and be carried over to Atlas, who knows.

Trac:
Severity: N/A to Normal
Reviewer: N/A to N/A
Sponsor: N/A to N/A
Summary: select only non-exit relays, related items to Make various UI improvements

I believe that gsathya has stopped working on any of these tickets quite a while ago. Reassigning to the friendly metrics-team user. (gsathya, thanks for having worked on all these tickets back when you did!)

Trac:
Owner: gsathya to metrics-team
Status: new to assigned

The metrics team has put a goal of shutting down Compass in its roadmap and merging functionality with Relay Search (previously known as Atlas). This ticket is specific to Compass and as development on Compass has ceased, I am marking this ticket as wontfix.

See #23517 (moved) for information on the planned work to integrate Compass functionality into Relay Search.

Trac:
Status: assigned to closed
Resolution: N/A to wontfix

closed

Make various UI improvements

Child items ...

Activity