Hello Karsten and everyone else :)<br><br>(TL;DR: would like to work on the searchable Tor descriptor archive project idea; considering drafting up a GSoC application)<br><br>I&#39;m a student &amp; backend+frontend programmer from Lithuania who&#39;d be very much interested in contributing to the Tor project via Google Summer of Code (well, ideally at least; the plan would be to volunteer some time to Tor in any case, but it&#39;s yet to happen, and GSoC is simply too awesome an opportunity not to try) -<br>


<br>The &#39;searchable Tor descriptor/metrics archive&#39; project idea [1] would, I think, best fit 
in with my previous experience and general interests in terms of 
contributing to the Tor project. The searchable archive project idea in itself has a rather clear list of goals / 
generic constraints, and since I haven&#39;t contributed any code to the Tor
 project before, working with an existing general project idea (building a more concrete design proposal on top of it) probably
 makes most sense.<br><br>This particular project, I think, would match my previous Python backend programming experience: building backends to work with large datasets / databases -- crafting efficient ORMs and responsive APIs to interact with them. [2] <br>


<br>Applying the 
knowledge/skills learned to something which is ideologically close at 
heart and the purpose of which is very obvious to me sounds thrilling! (This year, as far as Python frameworks are concerned, I&#39;ve 
been mostly exposed and have been working with Flask - have some 
(limited) experience with Django before that. As far as
 a proof-of-concept for the searchable archive is concerned, I&#39;m 
considering trying some things out with Flask, since it allows me to do 
some quick prototyping.)<br><br>I&#39;d like to try and work out an implementation/design draft for what I 
could / would like to do (this is a preliminary email - I know I&#39;m a bit late!) Ideally it (and a simple proof of concept 
search form -&gt; browseable/clickable results / relay descriptor 
navigation page) would serve as the base for my GSoC application, but I 
have to be realistic about me being rather late to apply and not having 
participated in neither Tor nor GSoC before. I&#39;d like to work out an application draft if possible, though. (Were I to get accepted, I would be able not to do any part-time work this summer, or would only need to take passive care of a couple of already running backends.)<br>


<br>I&#39;ve read into the Tor Metrics portal pages (esp. Data Formats), and am trying to get acquainted with the existing archiving solution (reading into the &#39;metrics-web&#39; java source (under 
metrics-web/src/org/torproject/ernie/web) to see how the descriptor etc.
 archives are currently parsed / imported into Postgres and so on), to first and foremost be able to evaluate the scope of what I&#39;d like to write.<br><br>I will presently work on a more specific list of constraints for the searchable archive project idea. I can then try producing a GSoC application draft.<br>

<br>Just to get an idea of what kind of system I&#39;d be building / working on - at the very least, we&#39;d be looking into:<br><ul><li>(re)building the archival / metrics data update system - the proposed method in [1] was a simple rsync over ssh / etc. to keep the data in sync with the descriptor data collection point. If possible, it would help if the rsync could work with uncompressed archives - rsync is intelligent enough not to need to send *that* much excess data - and diffing is more efficient with uncompressed data.<br>

A simple rsync script (can be run as a cron job) would work here.<br><br></li><li>a python script (probably to be run through cron) to import the archives into DB. Can stat files to only need to import new/modified ones, e.g. The good thing about such an approach is that the script could work as a semi-standalone (would still need the DB / ORM design), therefore could be used in conjunction with other, different tools - and it would be built as an atomic target during the implementation process - I heard you guys like modular project design proposals ;) who doesn&#39;t like them!<br>

We already have metrics-utils/exonerator/exonerator.py (which works as a semantically-aware descriptor archive grep tool) - some archive parsing logic can be reused maybe - the more pertinent thing here would be to<br><br>

</li><li>build the ORM for storing all the archival data in DB. Postgres is preferred and could work, especially since probably the a large part of the current ORM logic could be used here (I&#39;ve taken a glance at the current architecture, it makes good sense to me, but I haven&#39;t looked further, neither have I done any benchmarking with the existing ORM (except for some web-based relay search test queries which don&#39;t really count.))<br>

<br></li><li>it is very important to build an ORM which would scale well data-wise, and would suit our queries well.<br><br></li><li>query logic and types - the idea would be to allow to do incremental query-building - on the SQL level, WHERE clauses can be incrementally attached to the higher-level ORM query object. For example, part of fingerprint / relay name -&gt; add a date interval -&gt; additionally, add a day-specific &quot;on date&quot; clause -&gt; etc. ORM efficiency, benchmarking and restrictions on query complexity - this may turn out to very much be a nontrivial matter.<br>

<br></li><li>on the user interface level, user query input parsing - the idea would be to allow for flexible user input; date interval / info not mandatory; possibly, the user may provide additional filtering by specifying more descriptor metadata. Would need to figure out the most accessible type of input - a simple input field with info about the flexible syntax with examples and a flexible parser, and/or optional additional fields - a responsive UI (can expand the input form into additional fields/options and try to avoid contradictory / non-sensical input) might prove effective here.<br>

<br></li><li>results page - would need to work out what kinds of relay metadata to show, can click on parts of the data on the results page to further narrow results - unless click on relay name / fingerprint / etc., in which case would be taken to that specific relay&#39;s page (on a more general sense, this would also be a kind of &#39;result narrowing.&#39;)<br>

<br></li><li>=&gt; generally create a browsable relay archive, formatting / aggregating specific descriptor fields to provide more info about each relay. &lt;-- may make sense to start working on the particular constraint list starting from this point.<br>

</li></ul><br>Hopefully Karsten can help me with the application, assuming my idea for the project is to make sense. :)<br>
<br>I will follow up with more details. Besides my email address &lt;<a href="mailto:kostas@jakeliunas.com">kostas@jakeliunas.com</a>&gt;, I can be reached on #tor-dev as &#39;wfn&#39;, or XMPP/Jabber via &lt;<a href="mailto:phistopheles@jabber.org">phistopheles@jabber.org</a>&gt;.<br>

<br>Cheers to you all<br>Kostas.<br><br><br>[1] <a href="https://www.torproject.org/getinvolved/volunteer.html.en#metricsSearch" target="_blank">https://www.torproject.org/getinvolved/volunteer.html.en#metricsSearch</a><br>

<br>[2] My largest Python backend related project was this winter, building a redis (product likes/dislikes) + mysql (everything else) product 
recommendation solution to work with a large dataset of (product) 
metainfo (such as user votes on products), and creating APIs (on top of 
Flask) (API for the frontend CMS and for a mobile app) which include 
custom-per-user product recommendation feeds, etc. Large data (nothing 
close to the Tor descriptor/metrics archives, though!) + Interactive 
application logic architectures are of interest to me.