![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
Entry tags:
Banyan Speak (Permitting cross-posting of threads) - GSOC
As someone who came to DW from the LJ community (and who's still more active over there than over here), one of the biggest barriers I find to participation is that while DW provides very good cross-posting, there's no way to cross-post comment threads. So in order to avoid discussions fragmenting across the two services it's currently necessary to tell people from one service to go to the other to comment. While this isn't always a barrier to participation (with OpenID implemented), it does provide an extra step, and the "friction" involved in that interaction seems to decrease the amount of participation.
Since my primary use of either service is focused around social interaction, the lost comments from people just not feeling up to logging into another site (even if they don't have to register an account or anything) mean lost chances for interaction, and that's a shame.
Which brings me to my project.
Basically I propose to construct a framework for synchronizing comment threads across multiple instances of DW (with the hope of making the code changes light/modular enough to let them be applied back to the LJ codebase with little or no modification). I've got a working implementation of this in WordPress at the moment, but there would need to be some changes for it to work for DW.
Initially I'll be using Disqus for synchronization (using their account system to handle the 'canonical' central version of a thread, and then synchronizing to and from that for all accounts/posts/services that need it).
What I'm aiming for is something that's almost UI-invisible. There will be a couple of user-facing changes.
The rest of the code changes will be on the back-end.
In the long-run, there may be some structural changes as well. I'm a bit uncomfortable using a third-party system such as Disqus to handle synchronization. They're a good bunch of guys, but they're outside the control of anyone working on a DW deployment. I'd like to begin looking at alternative systems such as building a synchronization API into the DW codebase directly, or implementing something like the Salmon Protocol.
To sum things up: the project I want to work on adds to the existing cross-posting systems by allowing the cross-posting of threads as well as posts. This means that no matter where a reader is seeing a post, they see the same conversation attached to it.
Since my primary use of either service is focused around social interaction, the lost comments from people just not feeling up to logging into another site (even if they don't have to register an account or anything) mean lost chances for interaction, and that's a shame.
Which brings me to my project.
Basically I propose to construct a framework for synchronizing comment threads across multiple instances of DW (with the hope of making the code changes light/modular enough to let them be applied back to the LJ codebase with little or no modification). I've got a working implementation of this in WordPress at the moment, but there would need to be some changes for it to work for DW.
Initially I'll be using Disqus for synchronization (using their account system to handle the 'canonical' central version of a thread, and then synchronizing to and from that for all accounts/posts/services that need it).
What I'm aiming for is something that's almost UI-invisible. There will be a couple of user-facing changes.
- In account settings there will be a section for users to enable the system and save their Disqus credentials. This will be a simple username and password update which will save a token. (Sort of like OAuth, but not exactly. It's a Disqus-specific credential system, but the users don't have to deal with it.)
- When writing a new post the user will be given a new option in the meta box (probably in-column with the "comments"/"comment screening" drop-downs) which allows them to either create a new thread for the post (the default) or pick an existing thread (from a previous post that they've made. Existing threads can be from any service that the user has connected to Disqus, so it allows bridging across multiple journals, and potentially multiple instances of DW (or in the future, possibly LJ).
The rest of the code changes will be on the back-end.
- There will need to be a comparison between the way DW stores comments in the database and the way Disqus does. Since they're both threaded systems they should be relatively similar, so I anticipate little needed in the way of modification here. Possibly an extra column or two in the DW system.
- Helper functions to make calls to the Disqus API will be needed.
- A function which automatically synchronizes comments/threads between the two services whenever comments are viewed on DW, and one that posts them to both services whenever new comments are posted.
In the long-run, there may be some structural changes as well. I'm a bit uncomfortable using a third-party system such as Disqus to handle synchronization. They're a good bunch of guys, but they're outside the control of anyone working on a DW deployment. I'd like to begin looking at alternative systems such as building a synchronization API into the DW codebase directly, or implementing something like the Salmon Protocol.
To sum things up: the project I want to work on adds to the existing cross-posting systems by allowing the cross-posting of threads as well as posts. This means that no matter where a reader is seeing a post, they see the same conversation attached to it.
no subject
Also, would this affect the DW comment front-end? I've heard complaints about Disqus' accessibility, and we don't want to introduce their problems into our system.
no subject
Which doesn't serve to solve the concerns with letting someone else's back-end touch your threads (no matter who's used as the controlling, 'canonical' version of those threads). I'd definitely be open to suggestions, and there is a reason I'm looking at Salmon, but at the moment I can't seem to come up with something that would be broadly workable that doesn't use some third-party service...