tigase / beagle-im

(M) XMPP client for macOS based on TigaseSwift XMPP library
GNU General Public License v3.0
184 stars 21 forks source link

Integration of CardDAV Contacts #17

Open ghost opened 4 years ago

ghost commented 4 years ago

Is your feature request related to a problem? Please describe. Finding XMPP contacts can be problematic. There is no central directory of XMPP users (which is good!), but how to know if someone you know has an XMPP account?

Describe the solution you'd like On Mac you can add information about social networks to your contacts in Contacts.app. XMPP is one of the options there. Of course this would only help with contacts where you already know the XMPP address. So, make it also an option to lookup mail addresses and check if there is an _xmpp-client._tcp.domain.tld or _xmpp-server._tcp.domain.tld, maybe on startup or in settings page as a button "check addressbook". If a new XMPP contact has been found, ask the user to add it to roster/addressbook as XMPP address or dismiss it.

woj-tek commented 4 years ago

If I get it right - you are proposing somewhat "brute-forcing" approach? Check if email's domain from Contacts also points to XMPP server? And if yes, assume that localpart (before @) being identical with XMPP address and try to send subscription request to that address?

hantu85 commented 4 years ago

I would say that in this case, you are exposing your JID and you need to add permission for Beagle IM to access your address book. While it may be working fine for you (personal usage), it may cause issues related to data protection, etc.

While having this as the optional feature might be cool, I'm not convinced this will be really used by people.

ghost commented 4 years ago

If I get it right - you are proposing somewhat "brute-forcing" approach? Check if email's domain from Contacts also points to XMPP server? And if yes, assume that localpart (before @) being identical with XMPP address and try to send subscription request to that address?

Yes, I don't think that it is common to have different services like mail and xmpp on the same domain part, but with different local parts. In most cases those will even share the same source for authentication like LDAP or SQL databases.

Comparing this to well-accepted (sigh) way of uploading your personal addressbook to some strange servers like in WhatsApp, Signal, Facebook or others, I think handling this locally on the client of the user is the better approach and more GDPR compliant. It's just a matter how this is implemented. Of course, this shouldn't be "brute-forcing" something... How about this, for example:

hantu85 commented 4 years ago

If you have many XMPP accounts in BeagleIM (and it is allowed) then for which account those newly added contacts should be added?

I'm not convinced that this will be useful for people. This only solves and issue when you have a list of users and you want to add them from the address book - in most cases, it is a one-time operation.

ghost commented 4 years ago

I would say that in this case, you are exposing your JID and you need to add permission for Beagle IM to access your address book. While it may be working fine for you (personal usage), it may cause issues related to data protection, etc.

While having this as the optional feature might be cool, I'm not convinced this will be really used by people.

As outlined in the other comment, I think it could be implemented in a GDPR compliant manner. In the end, it's your personal addressbook and you don't upload anything to any other server. As I titled this Feature Request "Integration of CardDAV Contacts" this could also mean that you can implement this by supporting a CardDAV link, e.g. on Nextcloud, instead of directly integrating with Contacts.app. But this would leave out local contacts of course. Also keep in mind my question about integration in Mail.app as mentioned in tigase MUC on Mar. 2nd at 21:03 CET: users will use features that are easy to use or be "just there". If they see that there are more people use XMPP as they've previously thought, this increases acceptance and usage of XMPP. And people will prefer clients that make are easy to use and will have a benefit to them. Often I hear in discussions about XMPP that people are thinking that nobody is using XMPP anymore. This is due to a missing central directory like Facebook. Of course, a central directory is nothing that is desireable in regards of GDPR. So, how can people discover then if other people in their addressbooks are reachable by XMPP? It's not like you would implement a new feature. You are just using and clueing together what is already there: personal addressbook, CardDAV, service/user discovery (isuser) in XMPP, XEP-0401, etc...

ghost commented 4 years ago

If you have many XMPP accounts in BeagleIM (and it is allowed) then for which account those newly added contacts should be added?

I'm not convinced that this will be useful for people. This only solves and issue when you have a list of users and you want to add them from the address book - in most cases, it is a one-time operation.

No, IMHO it's not a one-time task... new XMPP accounts are created all the way. Like new people are joining Signal app everyday... just today I received a notification in Signal that there an old friend joined Signal. I would like to be notified as well when a friend joines XMPP network as well.

ghost commented 2 years ago

Coming across this again...

I'm thinking about this feature request or creating another one:

Basic idea is to have wider support of XMPP in other applications. The Addressbook.app is just one of those. Another one is Mail.app (which in turn also make use of the addresses in Addressbook.app). For Mail.app it would be nice to have some kind XMPP integration as well, for example through an extension/plugin:

Basically another option would be thinkable as well: if the user doesn't have BeagleIM installed, but for some reasons the Mail.app extension, the extension could offer a "Reqister & Chat" box when a JID of a remote recipient has been found, e.g. in Addressbook.app. The registration process could then lookup the own XMPP SRV RRs for own domain (e.g. in case of such providers like mailbox.org) and/or make use of the curated XMPP server provider list at KDE project.

The intention of all this is to make it easy for users to discover if a contact has a JID and make chats easy to use. Sometimes people write mails, because the don't know that the other person is also reachable by chat and some questions are easier to discuss by chat and not by mail. Additionally the user get the benefit of a deeper integration of XMPP and mail, ideally when both a the same. But with additional header lines for JIDs the addresses can also be different or you can provider additional JIDs. It seems that JIDs in mail header are already supported by Evolution MUA.

The Mail.app extension could also offer a "Call" button to start voice/video calls when it discoveres that the other end supports this as well.