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

[nusenu]

> First, I think that it's great that you'd like to volunteer to help
> bring back Tor Weather. Unfortunately we cannot be sure how much time we
> could commit to helping you with this, 

is this statement for the metrics team specifically or all tor project?
(i.e. the relay advocate (phoul/Colin) which also is a software developer according to his
twitter bio)


> As this would not at least at the start be considered an official
> project, we would ask that you don't call the new service Tor Weather.

lets go with "Unofficial Tor Weather"?
if the Tor Project objects the use of "Tor":
"OrWeather"
 
> We have previously thought about what a new Tor Weather service would
> look like when roadmapping. Some thoughts:
> 
> * It should use Onionoo as a data source. I know nusenu has raised
> concerns about the delay, but I don't believe that 2 hours will make a
> huge difference.

this is not just about the delay, this is also about reliability. You
get a new tor network consensus very reliably once an hour, you don't get a new 
onionoo details file once an our at the same reliability (yes it got better but 
assume it will never be at the consensus' reliability), which means you
run into the risk of being blind to interm. outages when onionoo "jumps" consensuses

but I agree that for all but one(?) check/test using onionoo should be fine.

> This greatly reduces code complexity

using stem to check if a relay is in consensus and running shouldn't
increase complexity a lot?


> * It should allow operators to subscribe by email to all relays, for a
> relay's family or for a single relay.

this is mentioned on trac

> * It should not, at least initially, attempt to parse contactinfo. At a
> later time this feature could be added but initially it would be best if
> we were not sending emails to relay operators that they are not
> expecting. This is especially the case during early development where we
> may inadvertently spam operators with garbage messages.

Did anyone intend that? (I played with the idea of adding a notify field to
the contactinfo sharing spec but the problem is you don't want to authorize all
- just one)

> * The volume of email being sent should be quite low.

shouldn't it up to the subscriber to decide how often they want to
get email?

> We would probably
> fit into the SendGrid free plan. This would further reduce code
> complexity by offloading email functionality from the new service.

I dislike the idea of using a(n additional) 3th party service (basically giving
them the subscriber data) and I'd expect that
100 emails per day (that is their free plan) is to few emails if this service
gets used by many operators - which we should aim for,
but adoption of the service will be reduced due to the fact that is (apparently)
no Tor Project service in the first place.

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

I like this idea, also via email (which will certainly cause the 100 emails/day limit to be
exceeded)



-- 
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/61476bfd/attachment-0001.sig>