What do you think about the following alternative approach?
Expose all LW features via a convenient, well designed, documented/stable API. (I don’t know how much work that would be, but let’s ignore that for a moment.)
You’re now free to write and use a non-web client for LW. You can add whatever features you want that make sense as clientside-only features. Perhaps you can add support to an existing email/usenet/… client instead of writing one from scratch.
You can also add support for other sites, such as wordpress or tumblr blogs. Naturally, the client will have to enable for each site only the ‘shared’ features that site supports, like voting on LW. Then you can use that client to improve your personal experience on all sites, to the degree that’s possible without changing each site’s server software.
In fact, you will naturally create (or adopt, or adapt) a middleman protocol which clients will talk with per-server plugins. If you’re sufficiently masochistic, you can even use NNTP here.
If many people like your client and start using it, we can at that much later date consider issues like encouraging more newcomers to use it, or otherwise making it the ‘main’ client for some sites.
This would be very reminiscent of the multi-protocol, interoperable, and open-standard IM scene of the 90s and early 2000s, before the big providers (Google, Yahoo, Facebook, et al) all killed off their Jabber support and became closed gardens. And if such a protocol or client ever comes close to succeeding on a world-wide scale, I expect it would be killed in the same manner. In practice, of course, it would fail much sooner: the HTTP traffic of a typical website isn’t meant to be an API and can’t be easily reverse engineered to behave like one, never mind stability guarantees. But if we only want it for a few friendly sites, then it’s not technologically problematic.
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.
So why not write a bridge between the LW API (serverside) and NNTP (clientside), so you can use it with your favorite NNTP software?
Obviously it would have to be a complex, stateful bridge, probably with own copy of the content and so on. But it’s not a priori clear to me that this would require much more work than your original proposal. And it has the great advantage of being unilateral: you don’t need to convince anyone else (like the lesswrong.com admins) to do anything.
Which would be a good thing in and of itself, as a matter of software design, even if no-one planned on ever writing new clients. But the ability to write new clients (or change the existing one for private use, if it is open source) is much more important.
The two aren’t contradictory or unrelated :-) More to the point, the idea of multiple interoperable clients is hardly a “new way for humans to collaborate”, or even just “new”.
At this level of abstraction what is it that you want to change? LW does have an API expressed through HTTP and we have multiple interoperable clients called “browsers”.
Like I said, I have no idea how far LW is from having a good API already. (Not all HTTP traffic is a proper API, but maybe it’s a well written site.) If an API already exists, so much the better; move on to step 2.
By “client” I mean the actual client-side content and code of the website, or a client application for non-browser implementations. Not the browser (or equivalently, the OS).
Error, if I understand correctly, seems to want the ability to modify the UX and add new clientside features, with different users (like Error) choosing different features, and without requiring the server to be changed, everyone to agree, and the people who can actually change the server to spend time on it. If this is indeed Error’s main motivation, I suggested that it might be more easily (almost unilaterally) achieved by writing a new client. The new client might be web-based or not; that’s unimportant to the argument.
What do you think about the following alternative approach?
Expose all LW features via a convenient, well designed, documented/stable API. (I don’t know how much work that would be, but let’s ignore that for a moment.)
You’re now free to write and use a non-web client for LW. You can add whatever features you want that make sense as clientside-only features. Perhaps you can add support to an existing email/usenet/… client instead of writing one from scratch.
You can also add support for other sites, such as wordpress or tumblr blogs. Naturally, the client will have to enable for each site only the ‘shared’ features that site supports, like voting on LW. Then you can use that client to improve your personal experience on all sites, to the degree that’s possible without changing each site’s server software.
In fact, you will naturally create (or adopt, or adapt) a middleman protocol which clients will talk with per-server plugins. If you’re sufficiently masochistic, you can even use NNTP here.
If many people like your client and start using it, we can at that much later date consider issues like encouraging more newcomers to use it, or otherwise making it the ‘main’ client for some sites.
This would be very reminiscent of the multi-protocol, interoperable, and open-standard IM scene of the 90s and early 2000s, before the big providers (Google, Yahoo, Facebook, et al) all killed off their Jabber support and became closed gardens. And if such a protocol or client ever comes close to succeeding on a world-wide scale, I expect it would be killed in the same manner. In practice, of course, it would fail much sooner: the HTTP traffic of a typical website isn’t meant to be an API and can’t be easily reverse engineered to behave like one, never mind stability guarantees. But if we only want it for a few friendly sites, then it’s not technologically problematic.
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.
So why not write a bridge between the LW API (serverside) and NNTP (clientside), so you can use it with your favorite NNTP software?
Obviously it would have to be a complex, stateful bridge, probably with own copy of the content and so on. But it’s not a priori clear to me that this would require much more work than your original proposal. And it has the great advantage of being unilateral: you don’t need to convince anyone else (like the lesswrong.com admins) to do anything.
At this point, is LW itself anything more than a database with a schema? You’re pushing pretty much everything into the client.
Which would be a good thing in and of itself, as a matter of software design, even if no-one planned on ever writing new clients. But the ability to write new clients (or change the existing one for private use, if it is open source) is much more important.
Yes, but we’re leaving the territory of “let’s make LW work well” and entering the territory of “let’s design a new way for humans to collaborate”.
The two aren’t contradictory or unrelated :-) More to the point, the idea of multiple interoperable clients is hardly a “new way for humans to collaborate”, or even just “new”.
At this level of abstraction what is it that you want to change? LW does have an API expressed through HTTP and we have multiple interoperable clients called “browsers”.
Like I said, I have no idea how far LW is from having a good API already. (Not all HTTP traffic is a proper API, but maybe it’s a well written site.) If an API already exists, so much the better; move on to step 2.
By “client” I mean the actual client-side content and code of the website, or a client application for non-browser implementations. Not the browser (or equivalently, the OS).
Error, if I understand correctly, seems to want the ability to modify the UX and add new clientside features, with different users (like Error) choosing different features, and without requiring the server to be changed, everyone to agree, and the people who can actually change the server to spend time on it. If this is indeed Error’s main motivation, I suggested that it might be more easily (almost unilaterally) achieved by writing a new client. The new client might be web-based or not; that’s unimportant to the argument.