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