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.
Basic architecture: network of sites sharing an API (not an interface). A site can have a web client as part of the site (or several), but at least some clients can be written independently of a site. Users can choose to use different/customizable clients, and in particular, aggregate and cross-link content and users across sites. It should be possible, at least in theory, to write a non-web cross-site client with lots of custom features and use it as one’s only interface to all discussion forums without any loss of functionality.
We need at least feature parity with LW, which is the most feature-full of diaspora blogs and forums; other sites tend to have subsets of the same features, so they should be able to disable e.g. private messages if they want to. So: top-level posts with trees of comments, both of which can be edited or retracted; posts have special status (tags, categories, require permissions to post, etc); authenticated users (unless the site allows anonymous or pesudonymous comments), so a user’s comments can be collated; permalinks to posts and comments; RSS feeds of various things; etc.
Users should follow the user@host pattern, so they can be followed across sites. Different authentication methods can be integrated (Local/Google/Facebook/OpenID/...) but the spec doesn’t concern itself with that. User permissions should be stored at each site, and be powerful enough to allow different configurations, mod and admin powers, etc. Posts and messages should allow pubkey signatures, and users should be able to configure a signing key as part of their account, because some people really enjoy that.
In the LW 2.0 discussions, people proposed different variations on karma. The API should include the concept of a user’s karma(s) on a site, but for voting etc. it should probably limit itself to storing and querying data, and let the implementation decide how to use it. So e.g. the server implementation could disallow posting to a user with insufficient karma, or the client implementation could hide downvoted comments. The API would specify the mechanism, not the policy.
Finally, there need to be implementations that are pain-free and cost-free for site admins to install. At the very least, it should not involve running completely custom server software, or completely rewriting existing web clients and their UX. Ideally, there would be easy adapters/plugins/… for existing client and/or server software.
I agree with most of this, with the exception that top-level posts should not have any special status at the protocol level other than not having a parent. Clients are free to present them specially, though, including whatever ‘default’ interface each site has. Whatever moderation layer exists may do the same.
I also dislike private messaging systems—not so much because they shouldn’t exist, but because they should be implemented as email accounts that only deliver mail among local users, so you can handle them in your regular email client if you want.
[Edit: Note that tags and a lot of other post metadata could be implemented as extra headers in a news article. Not karma, though.]
Your description of basic architecture in particular is an excellent summary of what I want out of a discussion protocol.
top-level posts should not have any special status at the protocol level other than not having a parent.
Those are implementation details. The point is that top-level or parent-less posts have a special semantic status: they start a new conversation.
I also dislike private messaging systems—not so much because they shouldn’t exist, but because they should be implemented as email accounts that only deliver mail among local users, so you can handle them in your regular email client if you want.
It’s a matter of integration: I want the same settings, and client software, that you use for the rest of the forum to apply to privmsgs. For instance, blocking a user’s messages, sending privmsgs as replies to forum threads (and displaying that correctly in the client), …
And I don’t want to have to use two different client applications at the same time (email & forum) for private vs public messages.
And most people only use webmail, and you can’t tell gmail.com to display messages that live on the lesswrong.com IMAP server, if that’s what you intended.
It’s a matter of integration: I want the same settings, and client software, that you use for the rest of the forum to apply to privmsgs.
I don’t share the preference, but I don’t think this represents a conflict. There’s no reason a web client couldn’t present one UI to its users while doing two different things on the back end, IMAP for PMs and whatever else for the forum. Newsreaders do exactly that to support reply-by-email, and it works fine from what I’ve seen.
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.
You should think about it as “What kind of a new discussion framework can we bestow on the soon-to-be-grateful world” :-)
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.
Higher in the sense of specifying desirables from some set of more-or-less terminal goals. For example, you say “centralized from the user perspective”—and why do we want this? What is the end result you’re trying to achieve?
Deeper in the sense of talking about base concepts. Will there be “posts” and “comments” as very different things? If so, will the trees be shallow (lots of posts, mostly with few comments, no necroing) or deep (few posts, mostly with lots of comments, necroing is encouraged)?
Will there be a “forum”? “subforums”, maybe? Or will there be a pile of tagged pieces of text from which everyone assembles their own set to read? Will such concept as “follow an author” exist? How centralised or decentralised will things be? Who will exercise control and what kind of powers will they have?
That’s not a complete set of questions at all, just a pointer at the level which will have to decided on and set in stone before you start discussing protocols.
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.
Here’s my shortlist of requirements:
Basic architecture: network of sites sharing an API (not an interface). A site can have a web client as part of the site (or several), but at least some clients can be written independently of a site. Users can choose to use different/customizable clients, and in particular, aggregate and cross-link content and users across sites. It should be possible, at least in theory, to write a non-web cross-site client with lots of custom features and use it as one’s only interface to all discussion forums without any loss of functionality.
We need at least feature parity with LW, which is the most feature-full of diaspora blogs and forums; other sites tend to have subsets of the same features, so they should be able to disable e.g. private messages if they want to. So: top-level posts with trees of comments, both of which can be edited or retracted; posts have special status (tags, categories, require permissions to post, etc); authenticated users (unless the site allows anonymous or pesudonymous comments), so a user’s comments can be collated; permalinks to posts and comments; RSS feeds of various things; etc.
Users should follow the user@host pattern, so they can be followed across sites. Different authentication methods can be integrated (Local/Google/Facebook/OpenID/...) but the spec doesn’t concern itself with that. User permissions should be stored at each site, and be powerful enough to allow different configurations, mod and admin powers, etc. Posts and messages should allow pubkey signatures, and users should be able to configure a signing key as part of their account, because some people really enjoy that.
In the LW 2.0 discussions, people proposed different variations on karma. The API should include the concept of a user’s karma(s) on a site, but for voting etc. it should probably limit itself to storing and querying data, and let the implementation decide how to use it. So e.g. the server implementation could disallow posting to a user with insufficient karma, or the client implementation could hide downvoted comments. The API would specify the mechanism, not the policy.
Finally, there need to be implementations that are pain-free and cost-free for site admins to install. At the very least, it should not involve running completely custom server software, or completely rewriting existing web clients and their UX. Ideally, there would be easy adapters/plugins/… for existing client and/or server software.
I agree with most of this, with the exception that top-level posts should not have any special status at the protocol level other than not having a parent. Clients are free to present them specially, though, including whatever ‘default’ interface each site has. Whatever moderation layer exists may do the same.
I also dislike private messaging systems—not so much because they shouldn’t exist, but because they should be implemented as email accounts that only deliver mail among local users, so you can handle them in your regular email client if you want.
[Edit: Note that tags and a lot of other post metadata could be implemented as extra headers in a news article. Not karma, though.]
Your description of basic architecture in particular is an excellent summary of what I want out of a discussion protocol.
Those are implementation details. The point is that top-level or parent-less posts have a special semantic status: they start a new conversation.
It’s a matter of integration: I want the same settings, and client software, that you use for the rest of the forum to apply to privmsgs. For instance, blocking a user’s messages, sending privmsgs as replies to forum threads (and displaying that correctly in the client), …
And I don’t want to have to use two different client applications at the same time (email & forum) for private vs public messages.
And most people only use webmail, and you can’t tell gmail.com to display messages that live on the lesswrong.com IMAP server, if that’s what you intended.
I don’t share the preference, but I don’t think this represents a conflict. There’s no reason a web client couldn’t present one UI to its users while doing two different things on the back end, IMAP for PMs and whatever else for the forum. Newsreaders do exactly that to support reply-by-email, and it works fine from what I’ve seen.
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.
I had a list of...not features, exactly, but desirable elements, in the first post. I intended to update it from comments but didn’t.
I want higher and deeper X-)
Higher in the sense of specifying desirables from some set of more-or-less terminal goals. For example, you say “centralized from the user perspective”—and why do we want this? What is the end result you’re trying to achieve?
Deeper in the sense of talking about base concepts. Will there be “posts” and “comments” as very different things? If so, will the trees be shallow (lots of posts, mostly with few comments, no necroing) or deep (few posts, mostly with lots of comments, necroing is encouraged)?
Will there be a “forum”? “subforums”, maybe? Or will there be a pile of tagged pieces of text from which everyone assembles their own set to read? Will such concept as “follow an author” exist? How centralised or decentralised will things be? Who will exercise control and what kind of powers will they have?
That’s not a complete set of questions at all, just a pointer at the level which will have to decided on and set in stone before you start discussing protocols.