5 ms·

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 in

by snaky 10y ago

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 http://perldoc.perl.org/perltie.html

jandrese 10y ago
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/.
- ArkyBeagle 10y ago
  Spam filtering works reasonably well now, for any of the free services. Trolls? Ignore 'em.
- snaky 10y ago
  NNTP is transport protocol, orthogonal to moderation - like HN or Reddit or any other site moderation to HTTP.
jcranmer 10y ago
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.
- dredmorbius 10y ago
  What specific issues with 822?
  - jcranmer 10y ago
    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)
    - dredmorbius 10y ago
      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.

by snaky 10y ago

jandrese 10y ago

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

ArkyBeagle 10y ago
Spam filtering works reasonably well now, for any of the free services. Trolls? Ignore 'em.
snaky 10y ago
NNTP is transport protocol, orthogonal to moderation - like HN or Reddit or any other site moderation to HTTP.

jcranmer 10y ago

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.

dredmorbius 10y ago
What specific issues with 822?
- jcranmer 10y ago
  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)
  - dredmorbius 10y ago
    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.