[Standards] Extended contacts
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 d...@ex1.com, d...@ex2.com, d...@ex3.com ... It would make more sense to have an "extended contact" or a "meta contact" that combines all of these addresses. * 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 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. 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 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. * 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 +1888444, client would check the main gateway servers setup by users +18884440...@example.org, +18884440...@whatsapp.example.org, and +18884440...@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 proposal7: contact-related features might need revision like XEP-0140 (contact groups), as this is implemented in vCard too. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Subscription and invites policy
When using gateways that create many users (e.g: https://slidge.im), XMPP clients are spammed with subscription and invitation requests. It would be useful for users to set a policy that rejects any incoming request and only manually approve subscriptions and invitations. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Bookmarks groups
I just remembered Gajim also has a similar feature called workspaces. It was first introduced in v1.4 (August 2021): https://gajim.org/post/2021-08-27-workspaces/ It included a draft on the standardization of XMPP spaces: https://md.roflcopter.fr/xmpp-spaces# ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Bookmarks groups
XEP-0402 only describes bookmarks as a single category, but it is useful to have different categories within bookmarks. This is similar to Telegram's "Folders" features where one can organize different chats within specific areas of life: e.g: 1. Work 2. Friends 3. Family 4. and so on... ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] XEP proposal: bookmark pinning for user chats
"XEP-0469: Bookmark Pinning" specifies the implementation for bookmark pinning but only for group chats? Not sure if there is already an existing XEP for that, but one for pinning user chats would be useful. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Send-only role
Here are more restrictions Telegram provides for controlling users in groups: https://i.imgur.com/w1mYzZ2.png Transcription: --- What can this member do? * Send messages * Send media * Add members * Pin messages * Change group info Restricted until: * Forever * For 1 day * For 1 week * Custom ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] XEP proposal: filtering chat notifications
I am an end-user using two XMPP clients: for desktop and mobile. Since there is no XEP standard for muting conversations, the two clients implement this in their own way, and they are out of sync: the contacts I have muted on phone are not automatically muted on desktop and vice-verse. While looking to see if XMPP have such XEP, I found these extensions from Tigase that might be helpful in writing an official XEP: https://xeps.tigase.net/docs/push-notifications/filters ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Send-only role
I am an end-user, and having used Telegram for some time, it offers a more fine-grained control over members of a group. One of those controls is to prevent group members (usually bots) from reading group messages, and only allow them to send messages, following the principle of least privilege. A more complex set up would be partially allow them to read messages directed to them and exclude the rest of messages. E.g: by specifying a command like /bot, the bot can read the content of that message to process it then reply back. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
