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

[Nicolas Cedilnik]

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 idea would be to provide the following as a fallback:

Content of the original message

😀
…and that's actually what Cheogram Android does. You can see an example 
of such reaction+fallback stanza in this test case: 


Is there any reason why there is currently no fallback mechanism in XEP-0444?


It gets rapidly messy in groups. One of the values of emoji reactions is 
to improve signal to noise in large groups, and non-supporting clients 
will have a ton of noise with fallbacks. There are also other 
not-so-edge cases that are annoying to handle: reaction to attachments, 
modification of reactions.


That said, I think in 1:1 chat it would be quite reasonable to include a 
fallback, as the signal to noise ratio is not an issue there. Again, 
XEP-0444 does not forbid it, it's a up to client (and gateways ;)) 
developers.


--
nicoco

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

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

[Nicolas Cedilnik]

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, but I think it falls under the "advanced" use case 
that this specification allows as children of the dedicated element.


Let me know if your concerns have been addressed in this latest revision 
and if you have any other comments, suggestions, or anything else to add!


Cheers,

-- nicoco

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

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

[Nicolas Cedilnik]

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 for it to work, and allowing 
slidge to subscribe to your relevant PEP node(s)).


> fourth possible notification setting "on reply"

From the business rules:

> The "on-mention" notification SHOULD rely on the user's nickname 
being spelled out in an incoming message in a group-chat, but MAY rely 
on other mechanism to "ping" the user, such as a Message Replies 
(XEP-0461)  or Message 
Reactions (XEP-0444)  element 
referring a user's previous message.


I can see use cases for "on-reply" vs "on-mention" but only because we 
don't have "explicit mention/pings" used yet, ie, no way of writing the 
nickname of someone with no intent on pinging them (or it's just not 
implemented in clients I use). Also, thinking about it more, maybe a 
reaction to a message should not be considered a mention, in large group 
chats especially, we probably don't want that. Maybe I should change 
this to:


> The "on-mention" notification MAY rely on the user's nickname being 
spelled out in an incoming message in a group-chat, but SHOULD rely on 
an explicit mechanism to "ping" the user, such as a Message Replies 
(XEP-0461)  [2 
] referring a 
user's previous message or intent>.


> different option for mobile devices > child-less XML element
>Maybe this could be anticipated in this specification by allowing 
explicitly several  elements?


So maybe we could have:


  
  


The context attribute would be optional if there is only child but 
required if there are several ones. And (notif-setting, context) pairs 
MUST be unique (can we express that in them schema?).


> different kind of notifications depending on hours

What do you say if we allow context = 'mobile', 'desktop' or 'advanced', 
with 'advanced' meaning that rules are defined as children of the 
element, eg 

  
    9:00
    17:00
  
  type='super-subtle' />



We could make that similar to bookmarks extensions in the sense that 
clients MUST preserve what's in there, especially if they don't 
understand the content?


--

nicoco

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP proposal: filtering chat notifications

[Nicolas Cedilnik]

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 opened a PR on github: .

Feedback welcome!

-- nicoco

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP proposal: filtering chat notifications

[Nicolas Cedilnik]

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 this covers the specific use case of a push server, which 
unfortunately limits its scope.


For MUCs, it is a perfect fit for XEP-0402: PEP Native Bookmarks 
, in the spirit of XEP-0469: Bookmark Pinning? eg:


Play's the 
Thing'autojoin='true'>JC 
with when= taking 3 possible values "always", "never" and "on-mention".


For contacts, a PEP (XEP-0163: Personal Eventing Protocol) node would 
work. wouldn't it?




I am not entirely sure about the real life use-case for muting 
notifications from a contact when you can just block them via other 
ways, but maybe I'm just not imaginative enough. :)


List, any feedback on these ideas?

-- Nicolas___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Send-only role

[Nicolas Cedilnik]

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 like things an XMPP server could choose to support. I 
don't think there's any standards work blocking such an implementation.


It could be implemented, but wouldn't it require breaking compliance 
with XEP-0045 by introducing a new send-only role, cf 
?



A more complex set up would be partially allow them to read messages directed 
to them and exclude the rest of messages.


MUC PMs would work for this, wouldn't they?


E.g: by specifying a command like /bot, the bot can read the content of that 
message to process it then reply back.


This sounds a bit too complex to me, especially when using E2EE.

-- Nicolas

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Small fixes for XEP-0424

[Nicolas Cedilnik]

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 Example 4.

I hope that's useful.

Cheers,

-- Nicolas
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

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

[Nicolas Cedilnik]

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 
about language models/conversational agents only. AI is an improper 
term, but widely used to design machine learning, I don't like it but I 
made my peace with it. But "AI" is not limited to language models (think 
image-generating models, for instance).


About the content, these MUSTs are weird:

> The ** element MUST be present in the message package, MUST be 
qualified with the 'urn:xmpp:ai:0' domain, and the *model* attribute 
value MUST be entered.


I already use "AI" models I interact with via XMPP chat messages, and I 
am not sure why we would need to make it mandatory to use an  
element when "asking questions to AI"? It sure works fine without it. 
SHOULD, maybe?


Besides that, I can see why such XEP would be useful, my main concern is 
the use of AI when it really targets conversational agents.


-- nicoco
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] Re: Chat Markers and Read Status

[Nicolas Cedilnik]

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 probably need a 
new XEP especially for this. AFAIR the problem with chat markers is that 
we end up writing a lot of them in MAM. Ideally clients would avoid 
fetching all MAM including markers, but a server-side support, similar 
to what you described would be needed. I believe it would help with 
startup times of client too. (I have a computer I use once every week or 
two and it is a bit annoying to see MAM sync for 15-30 minutes on 
startup before it is fully usable.)


There was an attempt here: https://xmpp.org/extensions/inbox/inbox.html 
but it's a draft, and doesn't mention public, semianon MUCs, which I 
believe are the hardest problem.


Anyway, I'm just sharing what I gathered on this topic here. I haven't 
put up any work on it, and well, working on it is probably what needs to 
be done to see this happen.


Cheers,

-- Nicolas

___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

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

[Nicolas Cedilnik]

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:


- preventing offenders to come at moderators directly

- moderation with external (eg, CLI) tools

- service-wide moderation, where a MUC service admin might want to 
remove all messages with a certain attachment, eg disturbing awful 
pictures, URLs, from a certain author, etc.


- gateways to services where there the moderator is not known

Would a PR in this direction be acceptable?

-- nicoco


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Nicolas Cedilnik]

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/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Nicolas Cedilnik]

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 of how to reject a invalid reaction is added (message 
error/not-acceptable)


Let me know if this looks good now.

-- Nicolas

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Nicolas Cedilnik]

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 it explicit that only a 
single emoji is available for this entity.


The other part this PR tries to address is to specify how clients should 
behave when they receive an error in reply to a reactions payload. I 
think that without clarification, the clients should "revert to the 
previous reaction state", but I proposed to make "empty my reactions for 
this message". Any feedback about this?


-- Nicolas

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Nicolas Cedilnik]

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 message), but 
after discussion with Marvin (author), we decided that it's a bad idea, 
since, as you said, most instances are probably happy to accept any 
reactions.

blindly sending and seeing if they stick.


This is the current behavior described in this patch indeed. At the very 
least, this PR clarifies what clients should do when they receive an 
error after sending a reactions payload. I believe that the default 
behavior would be "revert to previous reactions state" but we made it 
"reset reactions to null" instead.


Would it work to advertise a disco feature of 'limited-reactions' so 
that e.g. a MUC that's going to filter such things could advertise the 
feature, and clients would know they need to fetch first, and 
otherwise wouldn't need to bother?


Outside of a gateway context, this is probably something that should be 
configurable by room admins, so wouldn't it be better as a muc#config 
field? Clients supporting it can adapt their UIs accordingly, and 
clients that don't can at least not display a bogus reaction state by 
taking into accounts the  they receive when trying to send a 
forbidden reaction payload.


-- Nicoco


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0444 update: restrict reactions

[Nicolas Cedilnik]

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 to a small subset of emojis. However, I 
think that it could also be useful in MUCs, where implementations may 
want to allow admins to use such restrictions.


My first draft had many issues, and after discussion on the github PR 
thread with marvin, I changed it to just mentioning that clients that 
send a reaction and then receive a  in return, 
should reflect that in their UI - removing all reactions from themselves 
to this message.


However, after further OOB discussion with marvin, we thought it might 
useful to add an additional "emoji correction" mechanism, in the form of 
a  element in the error payload.


With XMLove,

-- Nicoco

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Nicolas Cedilnik]

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?


Cheers,

-- Nicoco
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0461 (Replies) pull request

[Nicolas Cedilnik]

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 
accomplishes much in 1:1 chats, so I added:


    In a 1:1 chat context, a bare jid MAY be used instead of a full jid.

3. The character counting for the fallback text in the example was wrong 
(it did not count new lines). Also, because of the stanza "pretty 
formatting", indent and 2 other newlines that should not be counted are 
added, so I mentioned it in the text. This may not seem much, but 
edhelas, deuill and I all had trouble getting our heads around how this 
worked, so I believe this is helpful for implementators. "Explicit is 
better than implicit", they say.


3. I also wanted to relax the constraint on the quoted author, ie, not 
make the `to` attribute of the `` tag mandatory. I confess this 
is in big part for self-centered reasons, since it's not always trivial 
to retrieve or determine the "quoted gatewayed contact's JID". After OOB 
discussion with marvin, we agreed to change my first iteration:


A client MAY omit the 'to' attribute

to

    The  element SHOULD have a 'to' attribute

It this last point is too controversial, I'm OK to remove it and will do 
my best to enforce it in my bridge implementation. I do think the other 
points are not controversial and make the XEP better overall.


Thanks in advance for you feedback.

Cheers,

-- Nicoco
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___