On 28/08/2018 12:42, Michael Stone wrote: > Yes and no. NNTP is inherently open to abuse because it wasn't > designed with mechanisms to account for the cost of a transaction. > (This is true of all the early internet protocols, not just NNTP, > which is why we have, e.g., such a spam problem on SMTP.)
Isn't this true of, say, HTTP too? As with your other comments about Usenet, this is not an issue for a non-publicly federated system. I.e. The problem that affected Usenet (the ultimate in publicly federated systems) in this context does not affect NNTP in general for discussion group usage. Remember that we're having this discussion over email. As you observed above, SMTP-based email suffers from a spam problem due to this very issue. And yet this discussion list works. If this list was a NNTP-based discussion group, it would be even more bandwidth-efficient, it would not suffer from deliverability problems that email over SMTP can bring, and moderator-ability would not be an issue either (see below for more on this). > But certainly you can identify or deal with an abusive customer on > HTTP much easier than you can identify and remediate abuse within the > noise of an NNTP feed. This is the issue with what I called "moderator-ability" above. What "noise of an NNTP feed"? A NNTP feed need have no more "noise" than this mail list does. Once again you seem to be conflating NNTP (used in the context of a discussion group like this one or a group of such discussion groups) with the massive volume of Usenet. In fact, there is no difference whatsoever in the ability of moderators to identify and/or deal with abusive users on NNTP-based discussion groups compared to web-based forums. Equally in both cases, abusive messages can be seen by moderators, pre-moderation is potentially possible in both cases, messages can be deleted, and users can be suspended/banned or whatever. The only difference is that deletion of previously posted messages in a web-forum is always visible to everyone whereas message deletion is not retrospectively visible for already-downloaded messages received by NNTP (although this does depend to some extent on client software implementation). Let me say again that the problems that you often ascribe to NNTP are actually problems with Usenet (i.e. a massively and publicly federated system that happened to use NNTP) and are nothing to do with NNTP itself in the scenario under discussion here. > I remember the heroic efforts that abuse staff were trying in the mid > to late 90s, but it just wasn't possible. SMTP was able to mitigate > the worst problems by instituting spam filters and dropping > connections from shady corners of the internet--especially open > relays. But this was possible even to approach because SMTP involves a > known sender and a known receiever, so if a message is lost either the > sender or receiever can try to resolve the problem. It's much less > clear how you cut off NNTP servers without getting > silently-disconnected islands of news and a horrible user experience > for everyone. Again, this is an issue with Usenet, not NNTP. Whilst these things were a problem, I think you are further wrong to compare email to Usenet in this context. The reason I say this is because email in this context is a one-to-one system (i.e. as you say, one known user to one known user in this context) whereas NNTP fulfilled a different use case entirely: It was one-to-many (i.e. one known user to many unknown users). Therefore there was no point in trying to 'fix' Usenet in this context. It was working as intended. Email was fixable because its use case was fundamentally different (even though email can be used for similar things to Usenet). I suspect you might criticise my description of Usenet (or NNTP) as a "one known user to [...]" system but the sender of a Usenet message was known to *exactly* the same extent as a SMTP email sender. In the timeframe under discussion, both Usenet and SMTP email carry the same requirement (or lack thereof) for authentication. There was no difference (either in practice or theory) whatsoever. > You can "solve" the problem by keeping NNTP in a walled garden > (disconnecting from usenet) but then you lose a lot of the inherent > advantages of NNTP and end up with a protocol that's kinda overweight > for the simple problem of transferring a few text messages in a > client/server fashion. Where did you get that idea from? You're still seeing things from a Usenet-centric perspective. There is no need to see things that way. We're not talking about "disconnecting from usenet", as you put it. The use case under discussion here never was connected to Usenet. As I mentioned in another recent message, ISPs were hosting private NNTP-based discussion groups long before they dropped Usenet-connected NNTP servers. There is nothing about NNTP that requires it to be connected to Usenet. You lose nothing whatsoever in the context under discussion here: That is private discussion groups like this mail list. Sharing with Usenet adds nothing whatsoever to this scenario. Furthermore, you characterise NNTP as "kinda overweight for the simple problem of transferring a few text messages in a client/server fashion" and I could not disagree more. NNTP is ideally suited to sharing messages in a client/server fashion. As I have observed, it is more efficient in this regard (in terms of bandwidth-efficiency as well as management efficiency) than email lists and it is at least as efficient in these terms (and likely more bandwidth-efficient) than web forums. > But this isn't a thing that's done much; the NNTP protocol is both too > complicated and also too lacking in functionality that modern > discussion group members look for. It's not done much because NNTP (as well as email lists, albeit slightly less so with mail lists) has fallen out of favour as web forums have increased in popularity. However, as many members of this list have observed, NNTP is still, for those who like it, an ideal method of accessing this kind of discussion. I am surprised to see you say that NNTP is "too complicated". In the medium term future I'll have to implement a NNTP server and, having looked at the RFCs, it doesn't look too bad. Have you experience of implementing NNTP? As for "lacking in functionality", it all depends on what you expect it to provide. As a way of getting messages from place to place, it seems ideal. As a way of providing other features, it depends. I would not, for example, expect NNTP on its own to provide a moderation UI or avatars. Note that modern web forums often provide email alerts (and some allow email participation). The fact that email is as 'primitive' as NNTP in this respect compared to web forums native interfaces does not detract from the fact that it is useful for many users. > There are probably more people using tapatalk for that purpose--even > though it's hideous and proprietary--simply because it's a better fit > than NNTP for a modern discussion group. It all depends. I'm a member of a number of discussion groups: Mail lists, NNTP-based discussion groups, web forums. For me, Tapatalk is, as you say, hideous and proprietary and so it's not a good fit for my uses. For me, all those discussion groups could perhaps better be transmitted to me over NNTP. That would work better for my use case. It would be ideal for me, in fact. Yes, as I have observed, web forums (for which Tapatalk is a front end) have grown in popularity as NNTP and email have declined in popularity but what works best really does depend on the user (and type of user). Note also that the front end user experience is not necessarily directly dependent on the transport protocol. For example, it is entirely feasible for a front end that looks and works much like Tapatalk or like the mobile web versions of popular web forums to communicate with its back end via NNTP, or to communicate with different back ends using a range of protocols (e.g. NNTP, email, REST, and so on). -- Mark Rousell
