[tor-bugs] #9778 [Onionoo]: Adding votes documents to Onionoo

[Tor Bug Tracker & Wiki]

#9778: Adding votes documents to Onionoo
-----------------------------+---------------------
     Reporter:  karsten      |      Owner:  karsten
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Onionoo      |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+---------------------

Comment (by karsten):

 Replying to [comment:6 alphawolf]:
 > What if we include an array of authorities that voted in the current
 consensus?  Since the document is designed for machine consumption, we
 don't actually need to repeat the authority names under each
 "missing_flags"/"extra_flags" property.  Instead, these properties become
 arrays of arrays, with the index of each subarray corresponding to the
 index of the authority.

 Hmm, I think we can't move authority names to the top level, for several
 reasons.  Most importantly, it may always be the case that an authority
 doesn't vote on a flag, even when "Named" and "Unnamed" are gone.  To make
 this even more complicated, there's an open Tor proposal
 ([https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/177-flag-
 abstention.txt proposal 177]) that suggests allowing authorities to
 abstain from voting on flags for only a subset of relays.

 Another reason why I'd like to avoid adding new fields to the top level is
 that all response types return exactly these four fields at the top level:
 "relays_published", "relays", "bridges_published", "bridges".  This is
 done to simplify parsing responses by clients.  Adding a new "authorities"
 field just for details responses would break that simplification.

 Yet another reason is that we're putting together responses from
 previously written JSON documents.  These pre-written documents may be
 days old, and it might well be the case that some authorities took that
 day off but not the current day.  So, any object contained in "relays" or
 "bridges" must be self-contained.

 > > 2. There's nothing that the user could hover over to learn about flags
 in votes that didn't make it into the consensus.  This would be the
 tooltip that would display `extra_flags`.  Not sure how to solve this.
 > >
 >
 > Atlas could show the flags grayed out, in red, or with a strike through
 (or a combination) if a flag was not in the consensus.  Hovering over the
 "inactive" flag could then show the missing/extra flags tooltip.

 Right, we can do that!  Good idea!

 > While we're working out the document format, I propose shortening the
 flags to a 1-2 character token each.  The property names under "relays"
 could also be shortened.  Saving a few bytes in this area will end up
 saving megabytes when votes for all relays are requested.

 Not sold on that one.  The actual saving shouldn't be that big with
 compression turned on (yes, yes, that's a different ticket).  And while
 documents are designed for machine consumption, there's always a tiny
 fraction of people who read machine-readable documents because there's no
 good user interface (yet).  There's also the issue that clients will have
 to understand both full and shortened field names at least for a while.
 That requires quite some coordination, and in practice we'll still end up
 with broken clients.

 Are there any other ways to improve the document format for including vote
 information?  And should we consider additional information contained in
 the proposed "vote-info" document type
 ([https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/164
 -reporting-server-status.txt proposal 164])?

 Thanks for your feedback here!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9778#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online