26 Jun
2024
26 Jun
'24
11:17 a.m.
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 doe1(a)ex1.com, doe2(a)ex2.com, doe3(a)ex3.com ... 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 +18884440000(a)example.org,
+18884440000(a)whatsapp.example.org, and +18884440000(a)telegram.example.org. 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/