Greetings!<br><br>I&#39;m a student who will be working on the Searchable Tor descriptor archive as part of Google Summer of Code. Yay!<br><br>I&#39;ve been following Tor development for a while and hope that this opportunity will be my way of sneaking into the development kitchen of Tor. In any case, I hope to stay around for a longer time to come.<br>

<br>The original GSoC project proposal is based on one of the Tor project ideas available [1] and is part of the Tor Metrics project [2]. The GSoC proposal itself is also available to read [3] (TXT; if there&#39;s any interest, I can work on reformatting.) My primary mentor is Karsten and my secondary mentor is Damian.<br>

<br>I will quote the abstract from the proposal to sum up the high-level goals of this project:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">

I&#39;d like to create a more integrated and powerful descriptor archival search and browse system. (The current tools are very restrictive and the experience disjointed.) To do this, I&#39;ll write an archival browsing application wherein the results are interactive: they may act as further search filters. Together with a search string input tool which will have more filtering options, the application will provide a more cohesive archival browse &amp; search experience and will be a more efficient tool.<br>

</blockquote><br>So as of now, we have an array of tools for inspecting, searching for and getting aggregate data about running relays. (For an overview, see the Tools page in the Metrics portal. [4]) These tools include relay search, consensus info, exit-by-IP search, and quite a few more; furthermore, two Onionoo [5] based applications/tools: Atlas and Compass.<br>

<br>This project would proposes to:<br><ul><li>implement a more powerful backend that would allow one to search for all available relays since mid-2007 (I should have clarified in the previous discussions, and Karsten already includes this bit; i.e., since v2 statuses became available [6]; I guess this can also be discussed). &quot;More powerful&quot; here means, first and foremost, &quot;all (&gt;= v2) archival data&quot; (relay descriptors and consensuses at the very least), and furthermore (at least per the original proposal), involving more complex queries: we&#39;d be looking into, I think, minimally, combined AND/OR filters referring to a wider range of data fields available in the archival data and the ability to specify multiple date ranges. Referring to consensus-related data while searching for relays and vice versa would also be possible. (The capabilities would therefore also include those of exoneraTor.)<br>

<br></li><li>implement backend results which would, as of current standing, aim for Onionoo compatibility (again see protocol design in [5]), or perhaps supersede it while providing backwards compatibility (e.g. returning paginated lists of consensus-status-entries where a specified relay was present.)<br>

<br></li><li>(as per original proposal,) implement a more powerful archival descriptor search &amp; browse tool (frontend) which would provide a more uniform &quot;looking up relays&quot; / &quot;searching by using many criteria&quot; / &quot;further refining search in the results page&quot; experience - &quot;refining search results&quot;, i.e. adjusting filters would be semantically the same as entering search criteria in the beginning; hence a more interactive experience, a more powerful search/browse tool.<br>

<br></li></ul><p>The goals and design of the project have to be clarified, however. There is ongoing discussion (see another tor-dev thread [7] e.g.) whether perhaps the focus could be to create a backend which would speak the full Onionoo protocol and therefore be a potential replacement not only for relay search and exoneraTor, but also for other components: all presently-speaking Onionoo applications could be made to talk to the new backend, for example. The overall count of components will hopefully be reduced in any case, but ideally, we would end up with a much more integrated Tor Metrics (and maybe beyond) ecosystem.<br>

</p>Many open questions, however - see again [7]. Obviously discussions are very welcome indeed!<br><br>I&#39;m wfn on OFTC (#tor-dev, #nottor), also reachable via XMPP &lt;<a href="mailto:phistopheles@jabber.org">phistopheles@jabber.org</a>&gt;, and am very much up for any kind of chat. :) I&#39;ll be busy with exams in the first three weeks of June, though - but will find time for sure!<br>

<br>Regards<br>Kostas.<br><br><br>[1] <a href="https://www.torproject.org/getinvolved/volunteer#metricsSearch">https://www.torproject.org/getinvolved/volunteer#metricsSearch</a><br><br>[2] <a href="https://metrics.torproject.org/">https://metrics.torproject.org/</a><br>

<br>[3] <a href="http://kostas.mkj.lt/gsoc2013.txt">http://kostas.mkj.lt/gsoc2013.txt</a><br><br>[4] <a href="https://metrics.torproject.org/tools.html">https://metrics.torproject.org/tools.html</a><br><br>[5] <a href="https://onionoo.torproject.org/">https://onionoo.torproject.org/</a><br>

<br>[6] <a href="https://metrics.torproject.org/data.html#relaydesc">https://metrics.torproject.org/data.html#relaydesc</a><br><br>[7] <a href="https://lists.torproject.org/pipermail/tor-dev/2013-May/004940.html">https://lists.torproject.org/pipermail/tor-dev/2013-May/004940.html</a><br>