Feature request: Support for body in mailto links

Feature request: Support for body in mailto links

[Siddh Raman Pant]

Hello,

It would be nice if mailto links also contained the body of the
email one is replying to in quoted form (i.e. have leading "> ")
so that one can directly start replying when the client opens. It
seems the "body" hname allows this behaviour.

Thanks,
Siddh

Re: Feature request: Support for body in mailto links

[Eric Wong]

Siddh Raman Pant <code@siddh.me> wrote:
> Hello,
> 
> It would be nice if mailto links also contained the body of the
> email one is replying to in quoted form (i.e. have leading "> ")
> so that one can directly start replying when the client opens. It
> seems the "body" hname allows this behaviour.

How many mail clients does it work on?  And do people even use
mailto: links?  It would roughly double the the size of HTML
responses for /$INBOX/$MSGID/ endpoints and probably increase
browser memory use a similar amount.

Fwiw, I'm not a fan of quoting publicly-archived mail;
especially with our "archives first" philosophy.

Quotes makes messages significantly bigger than they need to be;
thus more expensive to mirror when the replied message is
readily accessible in public archives.  I end up skipping over
quotes 99% of the time.

Re: Feature request: Support for body in mailto links

[Siddh Raman Pant]

On Thu, 22 Dec 2022 02:34:19 +0530, Eric Wong, wrote:
> Siddh Raman Pant code@siddh.me> wrote:
> > Hello,
> > 
> > It would be nice if mailto links also contained the body of the
> > email one is replying to in quoted form (i.e. have leading "> ")
> > so that one can directly start replying when the client opens. It
> > seems the "body" hname allows this behaviour.
>
> How many mail clients does it work on? And do people even use
> mailto: links?

I tried it on mutt, Thunderbird, GMail web and mobile, Outlook web,
and Samsung's mobile mail app. So it does seem to have wide support.

If mailto is unused, why would the option and its support be there
in this project, and also in proprietary clients on mobile and web?

Debbugs also has the behaviour I mentioned, you may try it on any of
their bug report email pages. For example:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018118
(I know it's not exactly an archival project like this.)

> It would roughly double the the size of HTML
> responses for /$INBOX/$MSGID/ endpoints and probably increase
> browser memory use a similar amount.

That makes sense, thanks.

While I can't say much about performance in general (I am not much
familiar with the project internals, and came across this due to
lore.kernel.org), but regarding browser memory, the threaded view
already shows multiple messages, so I don't think it would be too
much of an issue, and the mailto links are apparently only shown
when you open permalinks.

I just tried loading on w3m an 896 KB HTML thread from lore.kernel.org
(containing 2-3 kernel configs, which you'd agree is normally huge
spam), and w3m seems to take 33MB of memory, a normal amount.

> Fwiw, I'm not a fan of quoting publicly-archived mail;
> especially with our "archives first" philosophy.
> 
> Quotes makes messages significantly bigger than they need to be;
> thus more expensive to mirror when the replied message is
> readily accessible in public archives.  I end up skipping over
> quotes 99% of the time.

Isn't quoting when replying to the convention? And most mailing lists
I have seen use quoting...

Thanks,
Siddh

Re: Feature request: Support for body in mailto links

[Eric Wong]

Siddh Raman Pant <code@siddh.me> wrote:
> On Thu, 22 Dec 2022 02:34:19 +0530, Eric Wong, wrote:
> > Siddh Raman Pant code@siddh.me> wrote:
> > > Hello,
> > > 
> > > It would be nice if mailto links also contained the body of the
> > > email one is replying to in quoted form (i.e. have leading "> ")
> > > so that one can directly start replying when the client opens. It
> > > seems the "body" hname allows this behaviour.
> >
> > How many mail clients does it work on? And do people even use
> > mailto: links?
> 
> I tried it on mutt, Thunderbird, GMail web and mobile, Outlook web,
> and Samsung's mobile mail app. So it does seem to have wide support.

Thanks for checking.

> If mailto is unused, why would the option and its support be there
> in this project, and also in proprietary clients on mobile and web?

Nobody really knows if it's used or not, or if people opt to use
`git send-email' instead.  But it is currently inexpensive to
support mailto: with headers-only.

> Debbugs also has the behaviour I mentioned, you may try it on any of
> their bug report email pages. For example:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018118
> (I know it's not exactly an archival project like this.)

Noted.  Yet they also have mailto:$NUM@bugs.debian.org w/o any
args at the top, too.  It really seems like overkill given debbugs
is in the same situation where mail is publicly archived.

> > It would roughly double the the size of HTML
> > responses for /$INBOX/$MSGID/ endpoints and probably increase
> > browser memory use a similar amount.
> 
> That makes sense, thanks.
> 
> While I can't say much about performance in general (I am not much
> familiar with the project internals, and came across this due to
> lore.kernel.org), but regarding browser memory, the threaded view
> already shows multiple messages, so I don't think it would be too
> much of an issue, and the mailto links are apparently only shown
> when you open permalinks.
> 
> I just tried loading on w3m an 896 KB HTML thread from lore.kernel.org
> (containing 2-3 kernel configs, which you'd agree is normally huge
> spam), and w3m seems to take 33MB of memory, a normal amount.

All the HTML generation on the server is already too expensive
for my tastes and I'm always trying to find ways to make it
faster without requiring XS modules nor any AOT compiler.

The /[Tt]/ endpoints are meant to be convenient for downloading
and viewing offline, but yes, they are farily expensive for
browsers.

The permalink endpoints are linked directly from Atom feeds and
may end up being hit more by crawlers.

I also remember the old days when people would be considerate
enough to 'grep ^CONFIG_' to trim down configs before posting.
I don't think that's common, anymore :<

> > Fwiw, I'm not a fan of quoting publicly-archived mail;
> > especially with our "archives first" philosophy.
> > 
> > Quotes makes messages significantly bigger than they need to be;
> > thus more expensive to mirror when the replied message is
> > readily accessible in public archives.  I end up skipping over
> > quotes 99% of the time.
> 
> Isn't quoting when replying to the convention? And most mailing lists
> I have seen use quoting...

Yes, it's from the old Usenet days when NNTP servers would
routinely drop messages during propagation.  Quoting messages
when they miss the archives is fine.  But in the case we're
discussing, messages shown on the web are already archived.

So yes, I believe in evolving the convention towards something
more lightweight to reduce disk/network/memory footprint for
everyone.  But I still follow old conventions when replying to
this message :x

Unfortunately; over-quoting seems more common, and corporations
seem to be pushing the convention towards HTML and top-posting;
or worse: proprietary vendor-locked crap.


Fwiw, the very earliest revisions of public-inbox HTML output
would try to truncate/hide quotes behind another link.  I
eventually decided against it since I wanted to show readers
how wasteful quotes are, so now they're shown in full.

I suspect clients hiding quoted text by default encourages
people to over-quote and waste bandwidth.