If I remember right, the most recent survey asked those exact questions. So we may well find out.
Error
Karma: 3,368
One of the interesting things about NNTP’s structure is that the moderator and the host don’t need to be the same entity or even use the same software. The same goes for UX elements. It would be entirely possible to run something-that-looks-like-a-blog on your own site, have it use hypothetical-lesswrong-hosted NNTP for hosting its content (buying you native-client support for users who want it), and still have ultimate control over who can post what. I’ll be describing how that works at some point.
It would rely on goodwill from the LW hosts, of course; but the worst they could do is stop hosting you—and they could not hold your content hostage as long as someone, somewhere, has kept a local cache of it. You could even self-host and still interoperate with the site, because the system was designed to be decentralized even though it doesn’t have to be used that way.
My opinion? Convenience. It’s more convenient for the user to not have to configure a reader, and it’s more convenient for the developer of the forum to not conform to a standard. (edit: I would add ‘mobility’, but that wasn’t an issue until long after the transition)
And its more convenient for the owner’s monetization to not have an easy way to clone their content. Or view it without ads. What Dan said elsewhere about all the major IM players ditching XMPP applies.
[Edited to add: This isn’t even just an NNTP thing. Everything has been absorbed by HTTP these days. Users forgot that the web was not the net, and somewhere along the line developers did too.]
Solving such integration and interoperability problems is what standards are for. At some point the Internet decided it didn’t feel like using a standard protocol for discussion anymore, which is why it’s even a problem in the first place.
(http is not a discussion protocol. Not that I think you believe it is, just preempting the obvious objection)
It is a non-starter, but there are ways to get the equivalent of a client in a web browser without using javascript to do it.
I appreciate both your encouragement and your criticism.
That is a feature, not a bug. :-P
Fair enough. :-)
ETA: Also, it is relevant that there is an RFC for you to skim, and that it gets read by many, many people not necessarily associated with us.
The format for server-side processing and storage should be the input format unless there is specific cause not to use it (3.2). Conversion to display formats should be done client-side and as late as possible. HTML, as Dan says, is a display format.
(this distinction exists even for server-side clients, e.g. web clients)
Asciidoc might be an alternative when more power is needed. I haven’t used it, but ESR once said that it does markdown’s job better than Markdown itself.
HTML is wholly unsuited to human editing or even reading. I blame it for ruining email. Well, that and top-posting.
This would be a second-best approach. The main benefit that the use of NNTP has over such an approach is the ability to leverage the huge existing library of NNTP server and client software. The only from-scratch development required would be a forumesque in-browser client—which might already exist, though I am aware of no good ones.
What you describe would be very similar to designing an NNTP 2, a goal that I find laudable but that I really do think is socially (not technically) impossible. If it were possible, I wouldn’t recommend implementing it on top of HTTP. “Cram the round peg of semantic information over http no matter how badly it fits that square hole” is my major beef with the entire direction of software development over the last ten years.
The comparison to Jabber is apt, and I hate the death of jabber for reasons very similar to my hate for the death of nntp. Mechanism should not be a closed garden. Individual communities, sure; and, as you say, what I want it for here is a few friendly sites. But mechanism, never.
The inferential distance is significant; looking through this thread, the impression I get is that the people who have actually used NNTP in the past do not need to be convinced. Or rather, they need to be convinced only that it is possible, not that it is desirable. Dagon above, for example.
Agreed that it’s inconvenient. Rather than separate it I’ll cut it down. 2, 4, and 6 all collapse to “client feature sets differ”; this is a meta-feature, not a meta-bug. The downside of client control is that not everybody sees the same thing. The upside of client control is client competition, which has similar benefits to market competition.
Solving adoption is the point of section 2 and is too long to describe here. Note that, as mentioned, I do not actually expect this to be adopted. The world isn’t that kind.
3 is a legitimate problem and will be addressed, but it’s the sort of thing where I need to spin up INN and see how it actually behaves when presented with edit-style supersedes. If there is a weak point in my “this is possible” argument, this is it.
This is one I’m glad someone asked about because I thought it was clear and it wasn’t: I am not advocating a native-client-only approach. I am aiming for something that uses NNTP as mechanism on the back end, so invested users have better options than “bug the 1.5 guys in a position to fix things to fix things” and interoperability between LW and the diaspora is easy rather than hard.
Inbound users should not have to know or care that NNTP is involved (1.7), for exactly the reason you mention: to the average user, the web is the internet (1.1, first because I expect most people here don’t realize it either), and explaining to them why they are wrong is not helpful. I want the answer to the eventual, inevitable question “how do I do X” (where X is not some fundamental operation like “read” or “post”) to be “install this app today and be happy,” as opposed to “bug person Y for six months and hope they take the time to implement X.”
The ‘cooperate’ action I need has to come from diaspora authors, not inbound new users; they are the ones that would need to be convinced to join the network and use blog software that supports it. Making that cooperate action as close to costless as possible (I would settle for “no harder than setting up your own blog”) is a hard problem—but, I believe, solvable.
The only LW-specific community feature my proposal takes advantage of is our cultural applause of “I cooperate in Prisoner’s Dilemmas.”
It scales in the specific sense that it allows for incoming users and authors to be added incrementally. It fails to scale in the sense that it can never be an open system in the same sense that Usenet is an open system. However, that is no worse than our existing situation.
Graceful degredation is a hard problem. Please don’t bring up graceful degredation, that’s for a future post. :-P
I am waffling on whether to encourage people to anticipate issues. On the one hand, it’s helpful for me to know what I need to address along the way. On the other, I really don’t want the comment threads bogged down by material that only makes sense to our technical contingent.
I love it that you jumped to the correct interpretation of The Proper Placement of User Features.
I disagree that existing NNTP clients are clunky. If anything, I find existing web forum software clunky. SSC is my go-to example because it’s where I ended up in the diaspora fallout. It gets on the order of seventy comments a day and is incredibly unwieldly to navigate. And it’s a single site. In Usenet days, with native clients, I routinely perused groups with an order of magnitude more discussion and had zero trouble navigating—and the same interface worked for all groups. It is this form of convenience I would like to revive. It cannot be done in a browser—but it doesn’t need to be. The end goal is for the browser to be the non-trivial-inconvenience-provoking default, but for native clients to be an option for people who want or need the kind of power they provide.
It’s relevant to the GG and ephemerality objections that while I’m suggesting NNTP, I’m not going to suggest Usenet itself; but rather, a private network, containing only LW-related groups, with infinite retention and programmably dumpable content. i.e. there is no risk of losing anything. Sequences may be an issue, but because of curation limitations, not retention. (also, yes, GG is a godawful sack of shit and Google has atrociously mismanaged their possession of a cultural treasure trove)
I actually think the existing LW/reddit-style interface has the least-horrible UX of web-based discussion software out there. I wouldn’t object to keeping it looking more-or-less the way it does; my problem is with mechanism more than policy.
I didn’t, but I was assuming people would anyway. I was actually hoping for higher-level objections like the problems I listed in the post, but, well. I’ll answer you anyway and maybe edit the post later. Most of these fall under 3.2 and 3.3 in the outline.
is actually the only part of the problem for which no off-the-shelf solution exists. The short version is that the site UX, instead of talking to a database directly on the backend, would talk to NNTP on the backend. Links to arbitrary posts (as a non-exhaustive example) could be as simple as https://newlesswrong/message-id. Top level posts could support some subject-generated shorthand, perhaps.
I actually do want a plaintext-oriented interface, but I know I’m in the minority. You’ve expressed the solution to the markup problem yourself, though: Markdown is already the effectively-default format on Usenet and all extant NNTP clients. In fact it’s the rise of lightweight markup in general and Markdown in particular that convinced me this could ever be more than a pipe dream. There are more powerful forms of lightweight markup that could be used; the key is that the input format must be readable as plaintext for interoperability between the web and native clients to be possible.
I believe that cancels and supersedes can be kludged to support something that looks like editing even if it isn’t. I may be wrong about this; in particular I’m not sure how supersedes interact with reply chains, because they’re unusable for that purpose on Usenet proper.
User management has an established solution, and DMing can be implemented as a LW mailbox (that only takes local messages) or a forwarding address, or both. RSS is probably easy. Server based state is easy for the ‘default’ website (really an in-browser client, covered in 1.1 and 1.7) but may be hard for native clients (but anyone using a native client presumably knows what they’re getting into). Tagging may be hard, I’m not sure. Karma is definitely hard, but may be unnecessary.
The short version of this is that, designed correctly, any author or site can adopt the network without being any worse off than they currently are; that is, cooperate-defect leaves you no worse off than defect-defect. The long version is...pretty much all of section 2, actually.
(ETA: I am answering this in moderate detail not to encourage technical back-and-forth but to demonstrate that I have thought this through)
There’s not necessarily a one-to-one bullet-point-to-post correspondence in that list; I won’t know exactly how much space it takes to make each point until I’ve done it. It seems excessively long to me too, but it’s how my notes map out.
A summary post is more or less what I tried to start with and failed. It kept coming out in arguments that only ‘work’ for people that already know where I’m coming from, e.g. it assumed the superiority of specialized protocols and the Rule of Separation, neither of which means anything to nontechnical users or even most power users. Our base is tech savvy but it’s mostly post-2000 tech-savvy, I think.
[edit: I might add a bullet-point summary to the bottom of this post without justifications after I’ve had a chance to see the comments and which objections people actually raise]
Note that there is now a Lamp2. Going by the quoted parts of this subthread, he appears to be reposting his own deleted comments verbatim.
I’m a sometime admin. Ban evasion irritates me.