Re: [tor-bugs] #25999 [Core Tor/Stem]: Build an abstraction layer over different consensus flavours

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#25999: Build an abstraction layer over different consensus flavours
---------------------------+-----------------------------------
 Reporter:  teor           |          Owner:  atagar
     Type:  enhancement    |         Status:  needs_information
 Priority:  Medium         |      Milestone:
Component:  Core Tor/Stem  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  descriptor     |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+-----------------------------------

Comment (by teor):

 Replying to [comment:3 atagar]:
 > Hi teor, interesting idea. In Stem I could provide a higher level
 'Relay' class that lazy loads whatever descriptors it needs to get
 commonly desired data (exit policy, contact info, etc). This would need to
 be based on stem.descriptor.remote (the controller interface relies too
 much on caching and the client's torrc to be reliable).

 Ok, that would be very helpful. And it's good to know that we can't fix
 this issue in Tor by modifying the control spec.

 > Honestly I wonder if we should rethink our dir-spec more fundamentally.
 It's grown organically and honestly the myriad of documents is more
 confusing than it probably needs to be.

 But the documents in the dir-spec primarily exist for Tor clients
 (including relays) to efficiently use the network. They don't exist for
 convenient information retrieval by analysts. (That's why we have Stem,
 Collector, Onionoo, Relay Search, and other tools.)

 Here's why we have each document type:
 * ns (original) consensus flavour - a comprehensive consensus, used by old
 clients, and for detailed analysis by tools and people
 * directory authority certificates - validating consensus signatures, used
 by all Tor instances
 * relay descriptors - a signed record of relay attributes, used by bridge
 clients, and for detailed analysis by tools and people
 * relay extrainfo descriptors - a signed record of relay statistics, used
 by metrics
 * microdescriptor consensus flavour - a smaller consensus to save
 bandwidth, used by all recent clients, relays, and bridges
 * microdescriptors - a smaller record of unchanging relay attributes to
 save bandwidth, used by all recent clients, relays, and bridges
 * bridge authority legacy v2 consensus format - used by BridgeDB

   might have missed a document type or two, but I can't see any we could
 remove or even combine.

 I think that we could redesign the directory URL scheme, but it would be a
 long time before we could get rid of legacy URLs.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25999#comment:4>
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