[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mailing list vs "the futur"

On Tue, Aug 28, 2018 at 02:03:05PM +0100, Mark Rousell wrote:
Isn't this true of, say, HTTP too?

Not in the same way, because you have a sender and a receiver, without the potentially infinite number of other machines that might be getting a copy of the content just in case someone might want it someday.

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.

Sure. But in that context, there's not really much benefit to NNTP either. It's just a dumb transport protocol with fewer deployed clients than HTTP.

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

How? Let's just drop the discussion about how horrible usenet was and focus on what the potential benefits of NNTP are. I can't think of many (definitely none significant) over SMTP, and none at all over a well implemented modern web based discussion with a cacheable REST interface.

   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.

Well, you also seem to like to jump back and forth in talking about one or the other, without actually offering any specifics. :) You brush off the problems of (the only) large scale NNTP implementation by offering a closed environment with close to zero users as a counterexample. But I'm happy to stop talking about usenet...except that you bring it up again:

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.

There was, in that you could use a throwaway account to broadcast a message to a large number of effectively anonymous but long-term users. In the SMTP context it's really hard to have throwaway accounts send to other throwaway accounts, allow the content to be durable, and be discoverable. The closest analogy was shared mail accounts used as dropboxes, but the clients of those were easily tracked once the account was identified.

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.

You've asserted it many times, but you haven't actually shown with numbers how it's more efficient in practice to any degree that matters in the real world. When sending via SMTP you consolidate messages per ISP/mail domain, and the backend mail server can deduplicate (or avoid duplicating) the incoming messages if that's an administrative priority. In practice, the volume of something like the debian lists is so low compared to the volume of background spam it doesn't even really matter. If reading via REST in a caching HTTP environment it's even more efficient since you won't retrieve even a single copy of a message unless it's requested. In practice there's not much caching these days for a variety of reasons but again, compared to the overall volume of web traffic the load of debian discussion groups is too small to matter.

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?

Make sure that your NNTP implementation is interoperable with your web forum, because if it doesn't it's a dead end. (And duplicative--we already have a lot of unused NNTP server code.) It's not that NNTP is necessarily complicated in itself, it's that making it interoperate with the expectations of a modern web forum is hard--potentially impossible without proprietary extensions, at which point you've thrown away the entire point of sticking with NNTP instead of using something else. The conceptual split between transit and reading functionality is a lot of legacy to carry forward if you're basically trying to create a reader interface for smart clients. Enough to make it debatable whether it's worth trying to implement all that vs exposing a REST API.

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.

And yet, those things have made web forums the de facto replacement for NNTP. As much as greybeards don't understand why the like button matters, it's really hard to convince actual users these days that the reason you don't have one is that they don't need it and you know better than they do. There are a lot of other usability issues that basically boil down to the change in user behavior from using a smart client at one location (possibly telnetting/sshing into there from elsewhere) to using a variety of dumb clients to access centralized resources. Protocols that transfer dumb messages but allow a lot of endpoint customization are great in the smart client model but tend to not have a good user experience in the dumb client model. (And vice versa--if you have the ability to highly customize a specific workstation, it's frustrating to not be able to.) Given demographic and technological trends, ignoring the dumb client paradigm is short sighted at best.

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

This is exactly what I was talking about earlier. Yes, it's theoretically possible. But for a variety of real-world reasons, large scale NNTP-accessible web forums haven't succeeded. (If you look, you can find a lot of attempts that never really gained much traction.) It was more practical in the tapatalk case to invent a new protocol than to use NNTP. I'd suggest that it's worth understanding why rather than just insisting that everybody is wrong and NNTP is the answer that they just haven't figured out.

Reply to: