[metrics-team] Bringing back Tor Weather - volunteering developer

[nusenu]

>> once an hour should be fine 
>> (even though onionoo's update process
>> is not done in a single transaction and you might get different data
>> for the same relays_published timestamp).
> 
> I see. Any reason why it onionoo doesn't switch the data in a single
> transaction? I would assume it relates to the way it reads the data,
> however in 2 hours I assume it can read the consensus data for the
> whole network.

everytime you fetch 
https://onionoo.torproject.org/details?type=relay&running=true
you should get all relays that were running at consensus time
matching the relays_published timestamp and we should do so at least once
an hour, karsten might tell us what is a good time past the hour


>> if this service will NOT use its own email infrastructure I think
>> we should have a discussion on which provider is used and what
>> requirements it should meet. I have a few things in mind here.
>> I'll add that to the ticket eventually.
> 
> I truly think that in today's email climate its almost impossible to
> run your own SMTP server and have emails be deliverable in a reasonable
> rate. If TorProject.org already have an SMTP email that is known and
> valid it would be great at some point to use it, but for now we'll have
> to use a 3rd party for the email alerts to be useful.

as far as I have seen, @torproject.org addresses are aliases.
tpo does not appear to be running their own email infrastructure (IMAP, ...)
most are just redirects.

If we start with RSS we can worry about this later.

>> Eran: Since this is not an official tor service, which issue tracker
>> do you want to use? Github repo? I wouldn't mind something other than
>> trac since trac has
>> no email integration.
> 
> I'll be doing the dev on github so I guess github issues should be more
> than fine.

great, let me know when the repo is born

>>> All of these system assumes there is a domain for that. I'll get
>>> one
>>> (or use some domain I already have).
>>
>> please ensure it supports DNSSEC
> 
> Sure. Might need a bit help in configuring DNSSEC (haven't done that
> before but I'm sure can figure most of it out).

unless you plan to run your own nameservers - I assume you don't -
this is usually just a button to click in your DNS provider's 
web interface. In practice the task is limited to simply ensure
that your DNS provider supports DNSSEC.


>> this is a great point! so we no longer (or at least less) have to
>> worry about 
>> who runs the service or the SMTP servers
> 
> Perhaps we should start with this approach. 

+1
but I'd like to see SMTP (and maybe even more) eventually

> It also make things rather easier in terms of running this on limited
> hardware. Consider this design:
> 
> * Process to read data from onionoo and generate the "events" based on
> that data, storing it in a database.

depending on how much history you are going to retain per relay the DB
might become big

> * Process to generate static feed files (RSS/Atom/JSON/Whatever). 
> 
> * Serve these files from a predefined directory structure (probably
> have the node fingerprint as the filename or part of the path).
> 
> Since there are only ~8123  relays and ~439 bridges (so total of ~8562
> nodes to generate feeds every 1 hour or so).

+ families



> it shouldn't take more
> than a simple VPN to do all that.

I assume you meant VPS here.


-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20180720/84e909c7/attachment-0001.sig>