NNTP is just the right abstraction to wrap any discussion-based thing. It would be nice to have just nntp://news.ycombinator.com, nntp://reddit.com and so on instead of bunch of incompatible APIs actually. It's like beautiful Perl's TIE [1] where you wrap an object in it and it exposed as regular scalar, array, hash or filehandle instead of 'an object' with it's own methods users need to learn to use it.

I think Gmane 2.0, if it ever will be born, would have a mechanism of plugins, that allow easy wrapping any web-forum in it, by writing a little template describing the layout of pages like 'this is topic, this is message body' and so on. And the crawler to use the plugins, of course.

[1] http://perldoc.perl.org/perltie.html

A version of NNTP where groups were automatically moderated and strong controls were in place to weed out spammers and trolls could work. The moderation would have to be baked into the core of the protocol and not some weird half measure bolted onto the side however. Once a community is large enough you either moderate it or you get another /b/.

NNTP is transport protocol, orthogonal to moderation - like HN or Reddit or any other site moderation to HTTP.

Spam filtering works reasonably well now, for any of the free services. Trolls? Ignore 'em.

NNTP is a very nice, simple protocol to implement, both server and client-side.

Well, except for the mess that is RFC 822. At least NNTP decided to go 8-bit safe eons ago, so you just have to shove everything in UTF-8 and you can screw RFC 2047 in the face.

What specific issues with 822?

Major issues:

* RFC 2047 is a pain in the butt

* Handling attachments can be difficult (particularly the inability to safely add binary data)

* The display name/address is both painful in terms of syntax.

* CFWS in general (you can tell who's written an email client by their reaction to the letters CFWS)

* Header fields in general have way too lenient handling, so there's no way to, e.g., guarantee non-ASCII handling (RFC 2047 needs to be handled differently in the Subject: header than from the From: header, and the Content-Type: header does something else entirely).

* Mandatory line-length limits, which means you need to be able to insert line breaks in however you encode custom header values

* No way to get attachments without the body or vice versa

* All metadata needs to be shoved into a header (see above about i18n, line length, and CFWS)

What would you change given a greenfield opportunity?

What would you add? Remove?

Why?

For myself: the basic RF282 concept of sender, subject, recipient (or newsgroup), date, and references, plus body, seem reasonable.

How best to take these to present capabilities (and needs) is another question.