asn, rdns, tordnsel,
>> cw, ...) - historic records
>>
>> I didn't find something matching so far, so I'll go ahead, but if
>> you know of other existing relay db schemas I'd like to hear about
>> it.
>>
>> thanks, nusenu
>>
>>
Progress/activities since last time:
* incorporating BridgeRequest's together with an initial bridge request
API over JSON (it's easier to do both as they are tightly related.) The
bridge request api is based on isis' initial fix/12029-dist-api_r1;
* bogus server-side bridge provider that imp
Hi all,
preferring existing code over shiny code and being mad late, I
* (re)wrote a simple but working churn control mechanism[1], which uses
* a general persistable storage system:
* in particular, the bot now has a central storage controller
which takes care of storage handlers which
Hi Karsten,
On Tue, Jun 17, 2014 at 10:13 AM, Karsten Loesing
wrote:
> Hi Kostas,
>
> On 11/06/14 04:48, Kostas Jakeliunas wrote:
>> Hi all!
>>
>> On Mon, Jun 9, 2014 at 10:22 AM, Karsten Loesing
>> wrote:
>>> On 09/06/14 01:26, Damian Johnson wrote
Hi all,
in the past couple of weeks I've been doing more of the same - namely,
fleshing out churn control in the bot; finishing a generic
challenge-response system (I'm also now considering making it into a
Zope Interface); subclassed text-based challenge-response;
incorporating isis' IRequestBrid
On Tue, Jun 10, 2014 at 10:38 AM, Karsten Loesing
wrote:
> On 10/06/14 05:41, Damian Johnson wrote:
let me make one remark about optimizing Postgres defaults: I wrote quite
a few database queries in the past, and some of them perform horribly
(relay search) whereas others perform re
Hi all!
On Mon, Jun 9, 2014 at 10:22 AM, Karsten Loesing wrote:
> On 09/06/14 01:26, Damian Johnson wrote:
>> Oh, and another quick thought - you once mentioned that a descriptor
>> search service would make ExoneraTor obsolete, and in looking it over
>> I agree. The search functionality ExoneraT
Hey all,
in the past weeks I've been working on understanding what can be done
using Twitter APIs and its media support in its CDN (for a later
captcha implementation), as well as on improving my existing Twitter
bridge distributor bot PoC. I've written some broken code, but it's
alright. More det
On Fri, Jun 6, 2014 at 1:18 PM, Philipp Winter wrote:
> On Wed, Jun 04, 2014 at 04:54:03PM +0200, Karsten Loesing wrote:
>> On 25/05/14 10:35, Karsten Loesing wrote:
>> > I'm continuously tweaking the Metrics Portal [0] in the attempt to make
>> > it more useful. My latest idea is to finally spin
Hi all,
I'm excited to be able to spend another summer-of-code together with
Tor (how impudent!) :) My name is Kostas (wfn on OFTC), primary mentor
is isis and secondary mentor is sysrqb.
I'll be working on writing a new BridgeDB Distributor[1]. I've set my
primary task to designing and implement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
With isis' and sysrqb's permission, moving the new BridgeDB
Distributor (and maybe general bridgedb distributor architecture
discussion) thread onto tor-dev@.
On 04/15/2014 10:30 PM, Kostas Jakeliunas wrote:
> On 03/29/2014 10:08 AM, M
Is there any English documentation available somewhere?
Consider posting to tor-talk@, not to tor-dev@ maybe?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Wed, Oct 23, 2013 at 2:32 PM, Karsten Loesing wrote:
> On 10/11/13 4:05 PM, Kostas Jakeliunas wrote:
>
> Oops! Sorry for the delay in responding! Responding now.
>
> > On Fri, Oct 11, 2013 at 12:00 PM, Karsten Loesing <
> kars...@torproject.org>wrote:
> >
&g
On Fri, Oct 11, 2013 at 12:00 PM, Karsten Loesing wrote:
> Hi Kostas,
>
> should we move this thread to tor-dev@?
>
Hi Karsten!
sure.
>From our earlier conversation about your GSoC project:
> > In particular, we should discuss how to integrate your project into
> > Onionoo. I could imagine tha
Just a small update, seeing as we've passed the hard pencils down date:
- latest Onionoo-like API documentation is at [1] (the latest version
will always reside there.)
- the branch 'gsoc' [2] contains the code that will be uploaded to
google melange for external review/check/whatnot.
Hi all,
TL;DR of TL;DR: all good as far as GSoC scope goes; work will continue; the
live torsearch backend has been updated; will update API doc today.
TL;DR:
- updated database / imported data up until current date
- hourly cronjob continuously rsync's latest archival data, imports to DB
(
Hello,
This status update is less extensive/dramatic compared to the last one, but
I'm still happy to report to be slowly moving ahead towards a stable
searchable archive system. In short, I've been working on what I said I
should work on in the last report, more or less:
I should now move on wit
On Mon, Sep 2, 2013 at 2:20 PM, Karsten Loesing wrote:
> On 8/23/13 3:12 PM, Kostas Jakeliunas wrote:
> > [snip]
>
> Hi Kostas,
>
> I finally managed to test your service and take a look at the
> specification document.
Hey Karsten!
Awesome, thanks a bunch!
The few
Hello,
this accompanies my status report [1], and includes info how to query the
searchable metrics archive for anyone curious. I also refer to the original
(now semi-outdated) project proposal/document. [0] Only sending to
tor-dev@for now.
The Onionoo-like backend is listening on
http://ts.mkj.
P.S. (sorry) - it will also be possible to launch the backend on an EC2
instance, depending on load / curiosity. For now, this is running on a
relatively fragile development server.
--
Kostas.
0x0e5dce45 @ pgp.mit.edu
On Fri, Aug 23, 2013 at 4:12 PM, Kostas Jakeliunas wrote:
> He
Hello!
Updating on my Searchable Tor metrics archive project. (As is very evident)
I'm very open for naming suggestions. :)
To the best of my understanding and current satisfaction, I solved the
database bottlenecks, or at least I am, as of now, satisfied with the
current output from my benchmark
Hi Karsten,
On Mon, Aug 19, 2013 at 3:49 PM, Karsten Loesing wrote:
> I wonder, is there a document describing the new API somewhere? If not,
> do you mind creating one?
>
I have an outdated draft that covers more than the API. Looks like it's
high time I updated and published it (at least the
On Wed, Aug 14, 2013 at 1:33 PM, Karsten Loesing wrote:
>
> Looks like pg_trgm is contained in postgresql-contrib-9.1, so it's more
> likely that we can run something requiring this extension on a
> torproject.org machine. Still, requiring extensions should be the last
> resort if no other soluti
On Tue, Aug 13, 2013 at 2:15 PM, Karsten Loesing wrote:
>
> I suggest putting pg_prewarm on the future work list. I sense there's a
> lot of unused potential in stock PostgreSQL. Tweaking the database at
> this point has the word "premature optimization" written on it in big
> letters for me.
>
ension.
On Mon, Aug 12, 2013 at 2:16 PM, Karsten Loesing wrote:
> On 8/10/13 9:28 PM, Kostas Jakeliunas wrote:
> > * I don't think we can avoid using certain postgresql extensions (if
> only
> > one) - which means that deploying will always take more than apt-get &&
Hello,
another busy benchmarking + profiling period for database querying, but
this time more rigorous and awesome.
* wrote a generic query analyzer which logs query statements, EXPLAIN,
ANALYZE, spots and informs of particular queries that yield inefficient
query plans;
* wrote a very simple
Last link of an unbroken email flood chain --
my (and perhaps only that one) last sentence may be aimed at a more general
audience, reiterating:
The usefulness of all this really depends on intended use cases, and I
> suppose here some discussion could be had who / *how would an Onionoo
> system*
It should also be possible to do efficient *estimated* COUNTs (using
reltuples [1, 2], provided the DB can be regularly VACUUMed + ANALYZEd
(postgres-specific awesomeness)) - i.e. if everything is set up right,
doing COUNTs would be efficient. This would be nice not only because one
could run very
>
> But would such arbitrary returned results make sense? It would look just
> like Onionoo results, but - a (small) subset of them.
Meant,
But would such arbitrary returned results make sense? It would look just
> like Onionoo results, but - a (small) subset of *all* the results in the
> new-On
Hi Karsten,
(not sure whom to CC and whom not to, I have a couple of fairly specific
technical questions / comments (which (again) I should have delved into
earlier), but then again, maybe the scope of the tor-dev mailing list
includes such cases..)
@tor-dev: This is in regard to the Searchable m
Hi everyone,
Some clean-ish working code is finally available online [1] (the old PoC
code has been moved to [2]); I'll be adding more soon, but this part does
what it's supposed to do, i.e.:
- archival data import (download, mapping to ORM via Stem, efficiently
avoiding re-import of existing d
Hey all,
I apologize for this unusual timing for a status report, but I ended up
delaying it beyond measure, so better now than later I guess. I can
reiterate it + any updates soon, it's just that I figure I'm long overdue
on informing tor-dev on what's going on.
I've started my project [1] later
As a separate thing/issue, I will try and write up a coherent design of
what we currently have in mind, since the discussion took place over
multiple places and some timespan. That way we can see what we have in one
place, and discuss parts of the system that are still unclear, etc.
___
Hi,
forgot to reply to this email earlier on..
On Tue, Jun 11, 2013 at 6:02 PM, Damian Johnson wrote:
> > I can try experimenting with this later on (when we have the full /
> needed
> > importer working, e.g.), but it might be difficult to scale indeed (not
> > sure, of course). Do you have any
Ah, forgot to add my footnote to the dirspec - we all know the link, but in
any case:
[1]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt
This was in the context of discussing which fields from 2.1 to include.
On Tue, Jun 11, 2013 at 12:34 AM, Kostas Jakeliunas
wrote
Hi folks!
> Indeed, this would be pretty bad. I'm not convinced that moria1
> provides truncated responses though. It could also be that it
> compresses results for every new request and that compressed responses
> randomly differ in size, but are still valid compressions of the same
> input. K
>
> > Here, I think it is realistic to try and use and import all the fields
> available from metrics-db-*.
> > My PoC is overly simplistic in this regard: only relay descriptors, and
> only a limited subset of data fields is used in the schema, for the import.
>
> I'm not entirely sure what fields
ook into the actual Onionoo backend implementation, namely, how
much of the "produce static JSON files including descriptor data" can be
reused.
In any case, I don't think that having Onionoo(-compatibility, etc.) as an
additional set of variables / potential deliverables should pose
On Tue, May 28, 2013 at 2:50 AM, Damian Johnson wrote:
> So far, so good. By my read of the man pages this means that gzip or
> python's zlib module should be able to handle the decompression.
> However, I must be missing something...
>
> % wget http://128.31.0.34:9131/tor/server/all.z
>
> [...]
>
Greetings!
I'm a student who will be working on the Searchable Tor descriptor archive
as part of Google Summer of Code. Yay!
I'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 a
Hello!
(@tor-dev: will also write a separate email, introducing the GSoC project
at hand.)
This GSoc idea started a year back as a searchable descriptor search
> application, totally unrelated to Onionoo. It was when I read Kostas'
> proposal that I started thinking about an integration with Onio
int.iacr.org/2012/494
On Sun, May 5, 2013 at 10:08 PM, Kostas Jakeliunas wrote:
> > have there been any attempts to produce a pluggable transport which
> would emulate http?
>
> (Ah, I suppose there've been quite a bit of discussion indeed. (
> https://trac.torproject.org/pr
> If we had a PT that encapsulated obfs3 inside
the body of http then this may work.
I'm probably missing some previous discussions which might have covered it,
but: have there been any attempts to produce a pluggable transport which
would emulate http? Basically, have the transport use http heade
> have there been any attempts to produce a pluggable transport which would
emulate http?
(Ah, I suppose there've been quite a bit of discussion indeed. (
https://trac.torproject.org/projects/tor/ticket/8676, etc.))
On Sun, May 5, 2013 at 9:58 PM, Kostas Jakeliunas wrote:
> >
Hello Karsten and everyone else :)
(TL;DR: would like to work on the searchable Tor descriptor archive project
idea; considering drafting up a GSoC application)
I'm a student & backend+frontend programmer from Lithuania who'd be very
much interested in contributing to the Tor project via Google S
45 matches
Mail list logo
