I think that there's still a question of where the appropriate split between client and server is. I mean, to a certain extent crossposting is a client function: a client takes input from a user, maybe formats it up some, and then sends it to the appropriate server. If a user wants to crosspost that content, then the simplest solution to that in a client context would just be to have the client take that same input, connect to the second server, and do the crossposting itself. No need to configure crosspost accounts (and passwords) on the server at all. That would also mean that if the client author wanted to do nicer things, like make the crosspost messages customizable (before we get around to it), they could do that.

Now, of course, that approach would mean that the server would not keep track of those crossposts, so if the user came back and edited the original post via the web, then those changes wouldn't be propagated to the various crossposts. (You could actually get around that by exposing the crosspost mapping to the clients, so that they could register the crossposts with the server themselves.) It would also mean that the clients would have to duplicate the various server configurations, so if we find that IJ doesn't support some particular metadata, then that information would have to exist both in the DW code and in each client that does crossposting.

I guess what I'm saying is that, yes, of course, clients should be able to crosspost between DW and other services. But I also think that at least some of the support for that should be done on the client side. Now, whether that should be just that the client says, yes, crosspost this to my other accounts, or that it does all of the crossposting on its own, or something in between... Well, I'm less sure about that.

Now if only we had someone who was actually coding for a client to give an opinion on that... :)