AMP for email allows you to package a mini-application in an email (think of those Google Doc emails where you can comment within the email). Would be neat if Echo emails could do that (e.g. you could respond to a talk page message without leaving your email client).
See also:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T232454 Support replying directly from a talk page notification (e.g. AMP Email) | ||
| Open | None | T64661 Echo: Emailed Notifications for new usertalkpage messages should include more or all of the message | |||
| Resolved | kostajh | T335535 Make Flow notification content truncation length configurable |
The "AMP for email" approach is quite different from general AMP (T124243) and its anitrust concerns and questionable performance benefits thus don't really apply here.
It would enable a new capability that basically no email application supports today (assuming basic sanitized HTML rendering), so it seems appealing in that regard.
The downside, though, would be that at least today it only works for Gmail recipients and specifically those using the Gmail app.
Perhaps a more widely beneficial approach, with less vendor lock-in, could be to support replying by replying to the e-mail itself. This is a growing idiom that most issue trackers support, and online discussion systems are picking it up as well (e.g. Discourse, GitLab, Phabricator, GitHub).
This would effectively do the same as what an AMP widget would do, which is taking a submitted text message through an API that then makes the edit on your behalf. We'd need to do our best to recognise quoted parts and strip those out, something the aforementioned open source projects offer prior art for that we can probably build on, perhaps even re-use if we work with Phabricator's PHP code and build on it (if it's complex enough to warrant sharing).
With the recent work on DiscussionTools, the server-side part of this in terms of serialising and inserting new replies is also pretty much done.
My impression is that all existing implementations are mediocre and a better-than-mediocre implementation would be hard due to the wide variety of email clients and their diverse quoting and signature conventions and formatting capabilities. Just dealing with bottom-quotes (likely unintentional, should be stripped) vs. inline quotes (likely intentional, should be turned into {{quote}} or some such) is a pretty hard problem in itself. The user will probably assume the email client's WYSIWYG capabilities work, and supporting that would be another layer of complexity; otherwise, we could only offer source editing. Basic discussion features like pinging could not be reasonably implemented. IMO the advantage of providing an editing interface we can control would be huge. It would be Gmail-only (mostly - Yahoo Mail for example supports it), but Gmail is something like 30% of the email market so that's still pretty significant. And Google did go through the effort of making a public standard so competitors could theoretically implement it.
The dynamic nature of these mini-apps is quite useful as well: it would be possible to show replies or edits to the original comment that happened after the email was spent, moderator actions could be applied etc. And the functionality is not limited to replying, you could mark as read or hide trolling/spam from your email client for example.
One possible disadvantage is increased phishing surface (although Google does manual review of these mini-apps). Another one is privacy (the converse is that we could track email opens for analytics, but I imagine we wouldn't want to do that).
Depends on T64661: Echo: Emailed Notifications for new usertalkpage messages should include more or all of the message - doesn't make sense to allow the user to reply in-place if they can't even read the message.
…and the feature could apply to DiscussionTools’ topic subscription notifications in addition to user talk page notifications, making it much more useful.