> The current contact implementation is lacking, which causes having lots of > fragmentation and duplicates in contacts. Here are some scenarios:
> * XEP proposal1: meta contacts. A single person John Doe has multiple > accounts [email protected], [email protected], [email protected] ... It would make more > sense to have an "extended contact" or a "meta contact" that combines all of > these addresses. XEP-0209 [1] already covers this; which clients implement it, however, is another matter. > * XEP proposal2: once meta contact is implemented, it would be desirable to > have a field for a personal note. For example, this is available in Slack and > Discord. In 2020 there was an XMPP sprint for "studying Discord and bringing > its interesting features" > (https://wiki.xmpp.org/web/Sprints/2020_November_Online), and I think this is > an interesting and useful feature. XEP-0145 [2] already covers this; which clients implement it, however, is another matter. > * XEP proposal3: better contact integration. The contacts data on XMPP apps > of Android is very isolated from the rest of apps. All other messaging apps > interact well with the device contacts and phone numbers, except for XMPP > because it doesn't use phone numbers as identifiers. But once we have XEP > proposal2 and we can add personal notes, we can also add a field for phone > numbers for contacts that would make it more interoperable with device > contacts that are identified with phone numbers. Adding phone numbers is already possible, but this doesn't magically integrate with the device contacts - that is entirely down clients implementing the necessary integration (and whether XMPP contacts want to connect their phone number with their account.) > For these 3 proposals, I was moving point by point to explain the motive > behind the next proposal which actually combines all of the three previous > points. > * XEP proposal4: vCard compatible contacts. The vCard standards solves all > three points since it 1) accepts multiple phone numbers and emails, 2) > Include note, birthday, company and other miscellaneous fields, and 3) are > supported natively by phone contacts. As of vCard v4, it has XML property > which "is used if the vCard was encoded in XML (xCard standard) and the XML > document contained elements which are not part of the xCard standard." XEP-0292 [3] already covers this; which clients implement it, however, is another matter. > * XEP proposal5: once vCard standard is supported, it would be easy to have > XMPP as a WebDav server. Android app like Conversation have access to all > contact information and can easily sync contact information with phone > contacts. As above, this is already possible, but would require an appropriate implementation. > * XEP proposal6: It remains to clarify how XMPP clients deal with contacts > that have no XMPP handle. Signal chose the position of not showing them in > app at all. WhatApp prepares an SMS to invite them. This might be left to the > client, but as a Slidge gateway user, it would be convenient to check phone > numbers as a username handle for the current server. E.g: if a phone number > is +18884440000, client would check the main gateway servers setup by users > [email protected], [email protected], and > [email protected]. If non of these exist, then the client can > proceed with inviting them to XMPP.. As for the security, a simple disclaimer > like: "XMPP found these gateway users but couldn't verify their ownership" > should suffice. XEP-0401 [4] provides an invite mechanism; which clients implement it, however, is another matter. Connecting to contacts via phone numbers brings many privacy concerns, but this is gateway specific anyway, so it's down to their implementation. > * XEP proposal7: contact-related features might need revision like XEP-0140 > (contact groups), as this is implemented in vCard too. XEP-0140 was retracted, in favour of XEP-0144 - however, I don't think these cover what you're actually looking for. Roster groups are already covered right there in RFC 6121 [5]; so all clients should implement this, though whether/how they expose it to users is another matter. XEP-0083 [6] also covers nested groups; which clients implement it, however, is another matter. It may be beneficial to familiarise yourself with the various XEPs [7] (yes, there are a lot) and features they provide. I expect your impression is more one of "these features are available on other networks, so why not on XMPP too?" and in most cases the answer is "it's already possible; which clients implement it, however, is another matter." [1] https://xmpp.org/extensions/xep-0209.html [2] https://xmpp.org/extensions/xep-0145.html [3] https://xmpp.org/extensions/xep-0292.html [4] https://xmpp.org/extensions/xep-0401.html [5] https://xmpp.org/rfcs/rfc6121.html [6] https://xmpp.org/extensions/xep-0083.html [7] https://xmpp.org/extensions/
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
