= 27d567bc2d48d9f40e9ccc20ea370b15)
gjm comments on Turning the Technical Crank - All
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (134)
I (too?) am nostalgic for the good ol' days of Usenet. I'm very very unconvinced that an NNTP-based system could realistically replace Less Wrong. I'm interested in what you have to say, but wonder whether there's value in some kind of brief overview post along the lines of "Here's the one-paragraph summary of why I think this is probably a good idea. Here are one-sentence summaries of the strongest five objections and why they don't change my mind."
(But maybe not; the effect might be to put off people who could have been persuaded with a gentler run-up.)
I do wonder whether you can really need twenty posts to make your case. Perhaps much of the material will be useful in other ways (e.g., to inform future attempts at community-building, collaboration, etc.)?
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]
I assumed you didn't want people to raise technical objections to this post, and let you present your argument first. But if you want them now, here are some objections that gjm didn't mention:
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.
(ETA: I am answering this in moderate detail not to encourage technical back-and-forth but to demonstrate that I have thought this through)
Meta: replying in a list-based format is inconvenient and I tentatively suggest making a separate reply for each significant list item.
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.
That misses my point. Some features, like voting, can't be implemented as clientside features, because clients would need to communicate about them (and establish consensus).
Contemporary HTML. On the other hand the original HTML (of the early 90s vintage) is a simple page description language designed to be hand-coded.
A well-defined limited subset of HTML would probably be easier to implement than some superset of markdown.
A subset of HTML is still unsuited to human editing. Even more so than full HTML, because it doesn't have the justification of being a complex and extendable syntax. A superset of markdown would be much more usable, for people writing plaintext, than a subset of HTML. Especially if, as now, the majority of posts and comments require more or less only regular markdown and no superset features like tables.
People from the 90s would disagree and rich text editors can output whatever. Of course markdown is better for specifying minor formatting while you write the content -- that's what it was explicitly designed for. However the advantage of HMTL is ubiquity.
The majority of posts and comments use only links, bold/italics, and an occasional bulleted list. Inline images are culturally disapproved of and tables are rare. At this level pretty much anything would work.
I don't get your point here. HTML's ubiquity is important for display, not for editing. Markdown is converted to HTML for display. As a user I prefer writing in markdown to writing in HTML. Don't you?
That doesn't mean anything would be equally as comfortable as anything else.
We are talking about the acceptable format for messages as they are processed and stored by the system, right? Ease of input is a separate issue and your editor can and should allow you to write in whatever way you find most comfortable.
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)
When you say "input" here you mean "what the client sends to the server". When DanArmak is talking about input, he is talking about the user experience, ease of writing and editing. These are obviously not the same thing.
It is, now. When designed, it wasn't.
If all users input in the same format, then it should be the storage format too. Rendering to HTML can be done when it's actually needed. (Plus or minus caching/prerendering for performance.)
If users can choose to input in different formats, and we can't convert between these formats (e.g. from HTML to markdown), then I think it would be easiest to just store whatever the user originally input. The main reason for original-format storage is editing, and users normally edit only their own content, so they shouldn't mind the format it's in.
If I write in markdown, but my editor has to send HTML to the server, then it has to implement an HTML-to-markdown conversion for editing, which raises all kinds of issues (like supporting the HTML output of an old version of the editor, never mind of different editors) and trying to solve them just doesn't seem worth the bother. What does adopting HTML as a storage format get you?
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.
The suggestion in your edit seems possibly reasonable. For what it's worth, I think my main objections (not all of them at all well thought through) are:
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 completely agree that comments on SSC and other blogs are incredibly annoying. I would participate far more in those comment threads if they used something like LW/reddit. I would happily pay money to make it so, but there's no cause I can donate to that would replace all Wordpress blogs in the world with reddit, or even with something halfway decent like Disqus.
I also think pre-Web discussion systems did some things better than LW/reddit. My own experience is with 90s email, not usenet, but I think they were fairly similar. On the other hand, there are important innovations like editing, voting, and moderation, which classic email and usenet lack. So just going back to one of those systems isn't a solution in itself. And while user features should be located at the client when possible, these particular features can't work unless all clients communicate about them, at which point they become protocol extensions - and everyone is forced or at least strongly encouraged to use on the few clients that support your community's favorite extensions, removing much of the value of a client-neutral protocol.
Of course this deals with the Google Groups objection simply by making it impossible to use Google Groups :-).
That is a feature, not a bug. :-P
The perennial cry is "LessWrong needs more high-quality content!" And when such is offered you go "Eh, condense it into a tl;dr"?
Nope, that's not what I intended to say. (My apologies for any lack of clarity.) Rather, I think that