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