[tor-dev] [tor-assistants] Finding a maintainer for Weather

[Karsten Loesing]

Hey Damian,

I thought about your email for a while (though that's not the reason it
took me so long to reply), but I didn't really come up with a good
solution.  But I have a few comments on details, so I decided to reply
anyway.

On 10/11/13 9:57 AM, Damian Johnson wrote:
> For those on tor-dev@, this is a thread where Karsten and I have been
> talking about the future of Tor Weather. Present thoughts are to do
> one of the following...
> 
> a. Attempt to tap the community to find a maintainer (the service has
> been unmaintained for years).
> 
> b. Hire a developer from odesk to address its present issues. Karsten
> and I aren't especially thrilled about this idea since it would mean
> continuing to have an unmaintained service linger on.
> 
> c. Replace the functionality Weather provides with something else
> (that's most of what our recent discussion has been about).
> 
> d. Simply deprecate and later shut down the service.

Just to be clear about shutting down the service, it's already scheduled
to be shut down in 3 months from now, unless we find a maintainer:

https://trac.torproject.org/projects/tor/wiki/org/operations/Infrastructure

(Along with the Tor website, by the way.  Fun!)

>>>> 3. We redesign Weather based on stem.
>>>
>>> As mentioned earlier this is already done to the extent that a patch
>>> exists. Weather's use of TorCtl was pretty simple so it was easy to
>>> map to stem, making some general improvements to the codebase in the
>>> process. If we opt for any plan involving the continuation of Weather
>>> than I'd like to see us do this since it's both easy, and will let
>>> Weather move off a deprecated dependency. We can then shift the
>>> service to Onionoo or rewrite it afterwards.
>>
>> There's a patch for this?  Sounds like a new Weather maintainer should
>> apply this patch as their first action.  (However, I'm not sure if we
>> should apply it without having a maintainer, because if it breaks, who's
>> going to pick up the pieces?  Unless you'd want to do that?)
> 
> Yup, a patch but untested (I didn't invest time into starting up a new
> Weather instance). So we definitely do need a maintainer before
> applying it.
> 
>>>> 5. (Even smarter ideas go here)
>>>
>>> What about my earlier suggestion? I'd like to replace weather with a
>>> new torrc parameter, say...
>>>
>>> SendNotifications me at some_address.com
>>>
>>> ... which is then included in the extrainfo descriptors. DocTor (or a
>>> new Weather if we really don't want to merge services) could then send
>>> notifications when a relay that previously set this goes down, or has
>>> reached a point of deserving a t-shirt. The only trouble with this is
>>> that it would expose real addresses in descriptor data (and hence,
>>> possibly spam).
>>>
>>> Maybe there's something smart we can do to overcome this issue?
>>> Providing relay operators with a method for including real contact
>>> information would be helpful (as mentioned with the upgrade scenario
>>> earlier in the thread).
>>
>> But we already have ContactInfo lines.  What's the difference between
>> the two?  I'd find this rather confusing as a relay operator.
> 
> Differences are...
> 
> * This option would be an opt-in for receiving notifications about their relay.

I still think a) that relay operators will be confused that they can
enter their email address in two different places and b) that we
shouldn't integrate Weather (or DocTor or however we call it) into
little-t-tor by moving configuration options there.

> * It resides in extrainfo descriptors rather than server descriptors
> (not sure if that'll lessen spam, but ContactInfo's definitely in the
> wrong spot).

In theory, there's no big difference between adding these fields to
server descriptors or extra-info descriptors.  Recent clients only
download microdescriptors which don't contain contact lines, AFAIK.  And
spammers can download tarballs of either descriptor type to learn
contained email addresses.

> * We've already trained users to throw garbage information into the
> ContactInfo. Since SendNotifications would be for automated systems
> like DocTor we could clearly state that it requires un-munged
> addresses, lest it doesn't work (and hence is pointless to set).
> 
> This said, without a solution to the spam issue I don't think this is
> a good idea. I'm hoping others on this list will have some ideas
> around this since a solution for the spam problem is the only thing
> standing in our way for having a good replacement for Weather.

I disagree that spam is what prevents us from replacing Weather.  The
Weather codebase is unmaintained, which is why it needs to be replaced
or cleaned up.  The model of people opting in by registering their email
address is not a bad one.  We can even dump the part where Weather sends
out welcome mails to new relay operators and instead make Weather more
visible on the Tor website.

>> Also, I dislike the fact that we're adding a config option to tor that
>> is mostly used by the Weather service.  What if we want to discontinue
>> the Weather service?  The config option will be around for another two
>> years after that, but it won't do anything, which will make people think
>> the tor program is broken.
> 
> Actually, DocTor rather than Weather - I want to shut Weather down.

Okay, I guess that's just a question of scope.  The old Java DocTor was
only a consensus-health checker written for directory authority
operators.  If you want to extend scope to relay operators, sure, why not.

> In
> theory this is a more general field for 'hey, automated services may
> send me notices regarding my relay', maybe also with 'here's tags for
> the notices I want'. Anyway, food for thought - an opt-in flag and
> email address is really most of what Weather provides us.

Agreed, Weather doesn't do much.  Though, as I said earlier, that opt-in
flag and email address don't belong into torrc, IMHO.

>> Also also, should this discussion happen on tor-dev@? :)
> 
> Perfectly fine with me - added.

Thanks.

All the best,
Karsten