= 27d567bc2d48d9f40e9ccc20ea370b15)
DanArmak comments on The Web Browser is Not Your Client (But You Don't Need To Know That) - Less Wrong
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 (47)
It's a pity that whatever energy exists on LW for discussing technological changes to the diaspora is exhausted on a non-serious proposal.
When you argue for something you don't expect to be accepted, you lose any reason to make reasonable compromises, lowering the chances of finding a mutually beneficial solution.
I may share your feelings. But if you want an API to be accessible to Web clients, it pretty much has to be JSON over HTTP. Any other format you support will have to be in addition, not instead of that.
Json isn't actually bad as a slightly-structured, self-describing, human-readable format. Maybe you prefer YAML or something, but I don't feel there's a lot of difference to be had. Certainly it's far better than non-self-describing, non-textual formats unless you really need to optimize for parsing performance or for size on-the-wire. And I'd argue you don't, for this usecase.
HTTP is horrible (and I say this as someone who wrote a lot of low-level HTTP middleware, even a parser once). Using maybe 50% of the semantics, and pretty much 0% of the syntax, and adding the features of HTTP/2 and some others they couldn't fit into the spec, would be wonderful. But we don't really have that option; we're stuck with it as something we can't change or avoid using. And I too hate having to do that.
But you know what? The same is true of TCP, and of IPv4, and of the BSD socket API, and a thousand other fundamental API designs that have won in the marketplace. At some point we have to acknowledge reality to write useful software. A forum / discussion protocol doesn't conflict with JSON over HTTP (much). We need to to focus on designing a good API, whatever it runs on.
If it helps, you can put the HTTP/JSON encoding in a separate specification, and be the happy user of a different-but-compatible encoding over a gateway.
You don't address the point I feel is most important: the NNTP model (distributed immutable messages, users not tied to servers, mod powers and karma not in the spec, ...) just isn't the one we use and want to keep using on discussion forums.
But they don't work with supercedes, because they link to immutable message IDs. So the server has to dereference the link, has to have kept all the old (superceded) versions, and has to prove the supercede chain validity to the client in case of signed messages. This is just unnecessarily ugly.
Besides, they are URIs, not URLs. That's not something the web can handle too well. You can include a server in the link, making a URL, but NNTP doesn't have a concept of an authoritative host (origin), so once again, why use NNTP if you're not going to move messages between servers, which is the whole point of the protocol? If you just want to store them at a single place, it would make as much sense to use shared IMAP. (Which is to say, not much.)
Before we get deep into protocols, is there any kind of a spec sheet anywhere?
Saying you want better software for discussions is... horribly vague. I have a strong feeling that we should figure out things like lists of desirable features, lists of undesirable misfeatures, choices of how one list will be traded off against the other list, etc. before we focus all the energy on stomping JSON into tiny little pieces.
I'm very willing to engage in this. (And I described what I want in some of my other comments). I'll post my spec sheet (which I think includes most of Error's) in a separate reply. But first, before we get deep into feature lists and spec sheets:
Suppose we agree on a protocol (or whatever). Suppose it's so good that we can convince most people it's technologically and socially superior to existing solutions - not counting the unavoidable costs of using custom software and of changing things, which are significant.
Given all that, how likely will we be to 1) write all the code needed, to the quality of a production project (actually, multiple ones), and provide support etc. for the foreseeable future (or convincing others to help us do so); 2) convince enough diaspora site admins, and readers/commenters/users if applicable, to switch over?
Obviously this depends on how much our proposal improves (or promises to improve) on what we have now.
See my answer to Error, but for the "how likely" question the only possible answer that I can see is "One step at a time".
First you need an idea that's both exciting and gelled enough have some shape which survives shaking and poking.
If enough people are enthusiastic about the idea, you write a white paper.
If enough people (or the right people) are enthusiastic about the white paper, you write a spec sheet for software.
If enough people continue to be enthusiastic about the idea, the white paper, and the spec sheet, you start coding.
If you get this far, you can start thinking about OSS projects, startups, and all these kinds of things.. :-)
P.S. Oh, and you shouldn't think of this project as "How do we reanimate LW and keep it shambling for a bit longer". You should think about it as "What kind of a new discussion framework can we bestow on the soon-to-be-grateful world" :-)
I get the impression most projects do that backwards, and that that's a large part of how we got into this giant mess of incompatible discussion APIs.
Somewhere later in this sequence I'm going to address the social problem of convincing people to buy back in. The very short version is: Make it more powerful than what they've got, so they have an incentive to move. Make sure they are still running their own shows, because status and sovereignity matters. And make it more convenient to migrate than to manage what they've got, because convenience is everything.
Once you get three or four diasporists back, network effects does the rest. But it needs to be an improvement to the individual migrant even if nobody else does it, otherwise the coordination problem involved is incredibly hard to beat.
Sometimes I think the best way to promote my ideas would be to start an NNTP-backed forum hosting service. I know it's within my capabilities.
Then I realize that 1. that would be a lot of work, and I have a day job, 2. nobody cares except me, and 3. I would be competing with Reddit.