[Standards] Re: XEP-0444: fallback mechanisms?

Hi, I noticed that, in the current implementations of XEP-0444 are not really backwards-compatible. Non-compliant clients completely miss the emoji reactions and the users are completely unaware that the reaction has been sent. Even if it not mentioned in XEP-0444, XEP-0428 can be used… One i

[Standards] Re: Proposed XMPP Extension: Chat notification settings

Hi all, I updated https://nicoco.fr/xep-notification-filter.html and the github PR accordingly to the list feedback. Unless I forgot something, I think the only thing I did not incorporate (yet?) is the "on-mention"/"on-reply" distinction singpolyma suggested. I'm not 100% against adding it,

[Standards] Re: Proposed XMPP Extension: Chat notification settings

Thanks for the feedback! ♥ > Once this XEP will move forward I'll update my code to implement it accordingly :) Cool! I did not mention it but (with lovetox's approbation) I will probably implement it in gajim, and certainly in slidge too (although it will require privileged entity support f

[Standards] Re: XEP proposal: filtering chat notifications

Hi all, I gave an attempt at this, you can read a built version here: I made it so it can be a bookmarks child, but did not make that a requirement, to leave the door open for use in other places, possibly best suited for 1:1 chats. I opene

[Standards] Re: XEP proposal: filtering chat notifications

I agree that it would be nice to have fine-grained notifications synchronization across clients. 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 I think t

[Standards] Re: Send-only role

I also think that having "publicly available bots" that non-technical users could invite to their private room while maintaining decent privacy would be good. Hosting a bot may be trivial to readers here, but I think we can't reasonably expect all users to be able to set it up. These all seem

[Standards] Small fixes for XEP-0424

Hi all, I opened a pull request to contribute small fixes to XEP-0424: - Fixes the schema of the || element: * The is no 'from' attribute * There is a mandatory 'id' attribute * 'by' and 'stamp' are not mandatory - Add a fallback 'for' attribute in

[Standards] Re: Proposed XMPP Extension: Communicate & Ask to AI

Hi all, Title: Communicate & Ask to AI Abstract: This document defines a protocol for asking questions to an artificial intelligence or requesting it to make predictions. URL:https://xmpp.org/extensions/inbox/xep-ai.html I have concerns about using the term "AI" here, when the XEP really is

[Standards] Re: Chat Markers and Read Status

Hello, I’m sorely missing it. I can’t believe I’m the only one missing it. You are not alone. ;-) I believe it can be easily introduced by modifying Chat Markers I had the same idea and discussed it in the XSF room a while ago and the consensus was that it was not a great idea and that we

[Standards] Moderation (XEP-0425) by anonymous moderator/admin

Hi all, XEP-0425 is explicit about the "by" attribute of being mandatory: > The element MUST have a 'by' attribute specifying the JID of the moderating entity. > Following up on a jdev@ discussion, I believe there are legitimate use cases where this requirement should be alleviated:

Re: [Standards] XEP-0424: Message Retraction - Remove Fastening

Hi Daniel, If fastening is dead indeed, but retraction is not, I think it's reasonable to remove references to fastening in retraction. Looks good to me. -- Nicolas ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/stan

[Standards] Fwd: XEP-0444 update: restrict reactions

Hi all, Thanks a lot for your feedback. I updated the PR accordingly https://github.com/xsf/xeps/pull/1249 Briefly: - entities can advertise which emojis they accept/how many emojis per user via a service discovery extension, so that clients can adapt their UIs if they want - an example o

Re: [Standards] XEP-0444 update: restrict reactions

Hi, I haven't updated the pull request yet, but do you think it would OK to have an optional, caps-cachable disco extension along the lines of:      urn:xmpp:reactions:0:restrictions         1     💘❤️💜       Besides the allowed emoji list, this would make i

Re: [Standards] XEP-0444 update: restrict reactions

Thanks for the feedback. I suspect that in most instances, you're happy to accept any reactions, and forcing a poll of available ones before that would be unhelpful, My earlier iteration of the PR did include a mechanism to fetch the available emojis (and rules, eg 1 emoji per reacter per messa

[Standards] XEP-0444 update: restrict reactions

Hello all, About https://github.com/xsf/xeps/pull/1249 My main reason for submitting a patch to this XEP is that most other walled garden IM networks are not as permissive when it comes to emoji reactions: most only allow 1 emoji per message per "reacter", some restrict the available emojis t

[Standards] XEP-0045: add MUC service shutdown example (pull request)

Hello all, Following a discussion on jdev@ where Zash suggested that I added an example for something I had failed to understand by myself: https://github.com/xsf/xeps/pull/1250 I think that even for a small change like that, sending an email here is to discuss is the appropriate workflow?

[Standards] XEP-0461 (Replies) pull request

Hello all, I've submitted this PR about message replies: https://github.com/xsf/xeps/pull/1251 1. It was missing a disco#feature that I added. 2. The XEP required ("MUST") that the quoted author is referenced with a full JID, which I think makes sense in a groupchat context, but does not ac