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: