You're looking at Less Wrong's discussion board. This includes all posts, including those that haven't been promoted to the front page yet. For more information, see About Less Wrong.

Lumifer comments on Turning the Technical Crank - Less Wrong Discussion

43 Post author: Error 05 April 2016 05:36AM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Article Navigation

Comments (134)
Tags: technology meta

Comments (134)

You are viewing a single comment's thread. Show more comments above.

Comment author: DanArmak 05 April 2016 06:24:15PM *  6 points [-]

What do you think about the following alternative approach?

  1. 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.)
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Comment author: Lumifer 05 April 2016 06:37:16PM *  1 point [-]

Expose all LW features via a convenient, well designed, documented/stable API.

At this point, is LW itself anything more than a database with a schema? You're pushing pretty much everything into the client.

Comment author: DanArmak 05 April 2016 06:43:53PM *  2 points [-]

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.

Comment author: Lumifer 05 April 2016 06:51:50PM *  1 point [-]

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".

Comment author: DanArmak 05 April 2016 06:59:31PM *  3 points [-]

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".

Comment author: Lumifer 05 April 2016 07:07:35PM 1 point [-]

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".

Comment author: DanArmak 05 April 2016 07:19:47PM *  2 points [-]

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.

Powered by Reddit Powered by Reddit