I think this reduces to problem 5. Namely, you can’t replace lesswrong.com with a completely new NNTP-backed site as your opening move.
Ordinary Markdown is insufficient because it doesn’t do inline images and tables, which are sometimes important for posts. There are more powerful alternatives, and some markdown supersets. But I’ll bet they’re not supported by NNTP clients. At best you’ll find one client (or client plugin) that supports what you want. But forcing everyone to use the same client negates the point of NNTP, and isn’t plausible anyway because we need clients for different platforms including mobile.
This definitely requires proof. In addition to the issue with reply threads, NNTP clients expect to be able to cache articles. Propagation of supersede/replace is at best delayed and at worst out-of-order, and will vary between clients. This is IMO a critical issue, a major LW feature.
I’m surprised that you say “anyone using a native client presumably knows what they’re getting into”. You’re proposing NNTP as a superior solution, but also saying anyone who actually chooses to use NNTP will have a hard time and/or fewer features. And I think this applies to other, more important features and not just server based state.
Adoption, for site owners, will at minimum require a significant time/money investment, and at least trivial inconveniences to web-based readers due to unavoidable minor undesirable UX differences. So moving to the new platform needs to make people better off, not just no worse than before. The same applies to posters/readers: they won’t switch over without a compelling reason, nor should we expect them to.
I completely forgot about karma, but it’s so important that I’m promoting it to a new item. I think karma is pretty good, and some alternatives may be better, but nothing at all is much worse.
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.
2, 4, and 6 all collapse to “client feature sets differ”; this is a meta-feature, not a meta-bug.
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).
I think this reduces to problem 5. Namely, you can’t replace lesswrong.com with a completely new NNTP-backed site as your opening move.
Ordinary Markdown is insufficient because it doesn’t do inline images and tables, which are sometimes important for posts. There are more powerful alternatives, and some markdown supersets. But I’ll bet they’re not supported by NNTP clients. At best you’ll find one client (or client plugin) that supports what you want. But forcing everyone to use the same client negates the point of NNTP, and isn’t plausible anyway because we need clients for different platforms including mobile.
This definitely requires proof. In addition to the issue with reply threads, NNTP clients expect to be able to cache articles. Propagation of supersede/replace is at best delayed and at worst out-of-order, and will vary between clients. This is IMO a critical issue, a major LW feature.
I’m surprised that you say “anyone using a native client presumably knows what they’re getting into”. You’re proposing NNTP as a superior solution, but also saying anyone who actually chooses to use NNTP will have a hard time and/or fewer features. And I think this applies to other, more important features and not just server based state.
Adoption, for site owners, will at minimum require a significant time/money investment, and at least trivial inconveniences to web-based readers due to unavoidable minor undesirable UX differences. So moving to the new platform needs to make people better off, not just no worse than before. The same applies to posters/readers: they won’t switch over without a compelling reason, nor should we expect them to.
I completely forgot about karma, but it’s so important that I’m promoting it to a new item. I think karma is pretty good, and some alternatives may be better, but nothing at all is much worse.
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).