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

[nusenu]

> I agree that Onionoo is probably the best data source. Is there a way
> to reduce the 2 hours delay to something shorter? 

no matter what kind of effort is put into increasing onionoo's
processing speed it will never be as fast as it's
data source - by design

> I know that the previous Tor Weather service would alert me after a few
> days that the node is down, which was a bit annoying. 

that was probably already at a time where it wasn't working/maintained
properly anymore - at its best time it would send you emails as soon
as your relay dropped out of consensus (if you subscribed for that)
and we should aim for that

> 2 hours means that a new weather system would be calling Onionoo every
> 1 hour (to make sure we don't miss the 2 hours update window too much)
> or even every 30min.

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).

> (maybe have newer Tor clients push notifications
> instead of pulling and discovering alone - but I guess that's a
> discussion for another place). 

I'm not sure I understood you here. Tor network data is updated once an hour
by dir auths, anything faster than that will not make much sense unless 
the tor network consensus interval is also changed.
onionoo is about relays and bridges only (not Tor clients)

the service should support subscribing to hashed bridge fingerprints as well
(note: This will allow the party running or observing the service emails to learn
bridge operator information)

> I think that actually Onionoo is the right place to parse the contact
> info and serve it as part of its meta data. 

I like the idea of having this in onionoo but I guess this will not happen anytime soon and
Tor Weather shouldn't depend on it.


>> * The volume of email being sent should be quite low. We would
>> probably
>> fit into the SendGrid free plan. This would further reduce code
>> complexity by offloading email functionality from the new service.
>>
> 
> Yeah, either SendGrid or Mailgun or whoever will give a reasonable free
> plan. Later we can ask to get some larger free tiers if we can show
> what's its used for. I really don't think one can really run an SMTP
> server these days and have Email actually get delivered.

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.

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.

> 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


>> * All events could be stored in a log and presented via an RSS feed
>> that
>> you could subscribe to. This could be a feed for all relays, for a
>> relay's family or for a single relay.
> 
> Having a feed is a good alternative for using an email as it will allow
> people to get the data without giving out information at all. 

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

> That kind of makes me think of a system that will keep a log of node
> changes. For example:
> 
> * An event for when the node first appeared

that sounds a bit like onionoo's first_seen timestamp


as the operator of a onionoo dependend service you might like to subscribe
to the metrics-alerts list which tells you when onionoo has problems.


-- 
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/924c393d/attachment-0001.sig>