bug#40676: 28.0.50; gnus locks when reading email

[Philip K.]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Philip K." <philip@warpmail.net> writes:
>
>> That was part of the rationale behind #40355, but the best way I see to
>> fix this would be to implement asynchronous DNS, since a libravatar
>> lookup has two phases (DNS lookup + image retrieval), compared to
>> Gravatar's single request.
>
> A cache would be a band-aid -- it still will have to do these lookups
> occasionally, and the user experience in Gnus suffers.

Another idea would be to only wait for a few milliseconds (or whatever
is reasonable) and only return an image if the backend manages to find
something in that time. But the request is still finished and cached for
the next query.

> As it stands, librgravatar shouldn't be the default gravatar provider.

I'm somewhat split on this. On the one hand, the reason I implemented
libravatar support is to increase it's audience and make more people
aware if it's existence, as a free and federated alternative to
Gravatar.

On the other hand, there is a privacy issue in the system, as explained
by [0]. The problem basically is that if I send you an email and set up
a libravatar server, by querying my server, I can know if you opened my
message or not. I can imagine spammers being very interested in
something like this.

> But, yes, Emacs should have asynchronous DNS support, and adding that
> probably isn't too difficult, I'd have thought?

I started writing something a few months ago, but didn't have the time
to finish it. But you're right, it shouldn't be too much work to come up
with a rough draft.

[0] https://lobste.rs/s/nwgljm/libravatar_federated_avatar_hosting#c_00fsba

-- 
        Philip K.