Not that anybody in a position to do anything about it is likely to be listening, but it would be really cool if I could reply to comment notification emails and have LJ do the right thing.
That is, when I get an email from LJ that someone has replied to my <post|comment>, I want to be able to reply using my email client and have my reply appear in the appropriate comment thread, threaded correctly. It wouldn't be hard, and it would be really helpful not to have to open a web page just so I can read what I've already read and then enter my reply into a textarea (or use "It's All Text...") instead of using the editor my mail client is already configured to use.
Tags:
no subject
The trouble arises from LJ correctly recognizing the incoming email and routing it to the right spot without the user having to do anything special. Since different mail clients handle replies differently (some quote text, some quote html, some presumably do other strange or unpredictable things, some may simply send a reply with no trace of the original message) and users can often change the thing a mail client does by default, or do their own strange and unpredictable things (such as reply in-line), LJ would invariably end up receiving tons of unroutable emails. Basically, I can't think of any way for LJ to make people's email clients behave properly, and so LJ would have to include instructions for the user that the user would have to follow. Since the process breaks down so easily at the user level, LJ would also have to bounce unroutable emails back to the user to let the user know their comment failed. Add to that the difficulty of securely authenticating incoming comment emails (the user would again have to follow some instructions, and if authentication failed the email would have to be bounced) and the problem does become hard. Not impossible, but hard, at least to produce a clean, elegant, idiot-proof, secure, and robust solution.
Using http to authenticate and route is easy because there are already reams of built-in features that people regularly use. Cookies, for instance. When your browser goes to post the reply from the email, odds are good that your browser already has your security information and a cookie that will get you access to posting without authentication. Authenticating by email requires encryption features that most users don't use, which is why, for instance, when a website sends you a confirmation email, you have to click a link in the email rather than reply to it to complete the confirmation process.
no subject
Authentication is a greater issue. I suggest requiring that the From: address of the incoming email match the To: address to which the notification email was sent. This should work correctly for most users. You could even let the user specify the email address they'll reply back from if they have a forwarding account and a weird configuration. Reject any comments not apparently from the correct user.
As for parsing, take the incoming comment as-is. If you need, implement something which strips quotes, make it the default, and allow power users to turn it off in their settings if they really want things posted as-is. This is all a formatting problem, not a routing problem.
If you look at the html form, it's got a bunch of hidden fields containing the sorts of identifiers I'm talking about. It doesn't use cookies (my links install doesn't have a login cookie for livejournal, and it posted just fine). This is why I say they've probably already done the overwhelming bulk of the necessary work.
Many websites allow you to reply to a confirmation email rather than clicking/copy-and-pasting a link. Just like I describe above, they encode the confirmation code into the reply address.
no subject
no subject