Optional server operator contact field for directory registrations?

[hoffie]

I haven't thought about this idea a lot, but what about extending the --serverinfo field to permit submitting a contact address for the server operator, which will get sent and saved in the directory (but won't be shown publicly)?
This would be fully optional, but this way we had a slight chance to reach (some) (public) server operators in case of urgent updates or coordinated response against misuse/problems (such as the recent empty-name client).

[ann0see]

The idea sounds good, but I'm not sure if it will be used in practice. At the moment some people use the Welcome message.

[pljones]

• I know at least two directories (@jp8 @sthenos, just a nudge ;) ) not running 3.9.1, so we'd have to make the feature on the server side compatible with old directories
• We're all aware of the majority of servers that just don't get upgraded, so we'd have to make the feature on the directory side compatible with old servers

That's not to say "no", just "more compatibility code" needs putting in place and maintaining going forwards for a feature that brings very little benefit to anyone, in my view. I don't see it helping server operators. I can't see it helping directory operators significantly.

The ideal way of "reaching" registered directory operators is the 15 minute "ping" doing a version check and sending a locally configurably alert.

[ann0see]

The ideal way of "reaching" registered directory operators is the 15 minute "ping" doing a version check and sending a locally configurably alert.

That's a good idea. Maybe a user could set a contact string via CLI which can be requested by the ping message, however we should at least try to limit it in a way such that normal clients can't request the data.

[pljones]

I was more thinking that the "ping" would return the version and the server would raise its own alert if it needed updating. The only thing we can really do to fix any problem is provide a new version of the software. The new version may attempt to update firewall rules or anything - which might trigger the server operator to read the change log or notice.

Basically, unless the server operator is prepared to install a new version of the software, we have no channel of communication with them, in my view.

[hoffie]

Basically, unless the server operator is prepared to install a new version of the software, we have no channel of communication with them, in my view.

Right. The idea was to make it easier after first installation or installation of the first update with this feature.

It was an idea, but I guess I'll now agree that the benefit is low while it would carry implementation overhead.