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

[Damian Johnson <atagar@xxxxxxxxxxxxxx>]

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.

>>> 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@xxxxxxxxxxxxxxxx
>>
>> ... 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.

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

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

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

> Also also, should this discussion happen on tor-dev@? :)

Perfectly fine with me - added.

Cheers! -Damian
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev