[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9778 [Onionoo]: Adding votes documents to Onionoo
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs