GNOME Bugzilla – Bug 763176
add "reply" option for replying with voice/video/SIP/XMPP
Last modified: 2021-05-19 11:45:51 UTC
When the user looks at a message, they can click reply to send a message. Why not make the "reply" button more versatile, so the user can reply by voice or video or chat using SIP or XMPP? Making this as convenient as clicking URLs in messages will make a big difference to the success or failure of open protocols like this.
Thanks for a bug report. I'm not sure whether it's a good idea. How do you know that the sender uses these protocols? Trying blindly may expose your mates (their email addresses) to the service serving these protocols. Of course, evolution could lookup user address books, but it proved to be slow in the past.
There are a few ways to optimize the user experience: - it could use DNS NAPTR or SRV queries to check if the other party's domain supports SIP and/or XMPP and the "reply by voice/video" option would only be clickable if a DNS entry was found - when somebody clicks the "reply by voice/video" option the first time, it could display a popup alerting the user that most domains that have the DNS records use exactly the same URI for email, SIP and XMPP but there are some cases where the email address can't be contacted - a more elaborate scheme could work through the address book entries, normalize their phone numbers with libphonenumber and then run ENUM queries on them and display a popup with all the ways of calling the person. The Lumicall app does this already, the code is Java but it could be easily adapted to C/C++. I'm not sure what you mean about "expose your mates (their email addresses) to the service serving these protocols". If their provider is not completely trustworthy then they have bigger issues anyway as their email could be abused.
(In reply to daniel from comment #2) > There are a few ways to optimize the user experience: > ... Right, and all of them require some time to validate whether the UI should be shown or not. It is the main pita about it. > I'm not sure what you mean about "expose your mates (their email addresses) > to the service serving these protocols". I meant with that that if I want to avoid any asynchronous lookups whether the sender can accept such calls, then the only information I have about the sender is his/her email address. I can use it for SIP like "calling URI": sip://user@example.com a) I do not know what is registered for this protocol (I can check it, but it might be part of the above asynchronous lookup) b) I cannot validate the application as such, thus if it does any remote checking with the given URI, then it possibly exposes the email address evolution gave it. I'm afraid of this particular exposure. Maybe not a big deal, but I remember people being unhappy of a gravatar.com lookups, which use MD5 checksum, not the email address in the clear form. Similarly with a new account lookup, which tries only with the user emails' domain, not with the full address; still some people are concerned about those things going to the Internet. I know, you can tell that these people will most likely not use such options in the Evolution.
On the issue of asynchronous lookups: I agree it is inconvenient, the more elaborate solution I suggested (a popup) might be better. Then the option is always active in the reply button, but it only starts doing async lookups if the user clicks to call. In Lumicall, we display the popup and do the lookups in different threads (see the DialCandidateHarvester) https://github.com/opentelecoms-org/lumicall/blob/master/src/org/lumicall/android/sip/HarvestDirector.java The privacy leak is a valid concern but I think that is manageable too. The DNS lookups for NAPTR and SRV records only look for the domain and not the whole email address. Maybe some global setting is needed where the user can choose to enable or disable all network activity (gravatar.com+whatever) and the first time Evolution tries to do such a lookup, it could ask the user if they want to enable or disable lookups.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.