python-nbxmpp issueshttps://dev.gajim.org/gajim/python-nbxmpp/-/issues2023-03-02T13:36:05Zhttps://dev.gajim.org/gajim/python-nbxmpp/-/issues/138Implement XEP-0424 Message Retraction2023-03-02T13:36:05ZDaniel BrötzmannImplement XEP-0424 Message Retraction[XEP-0424 Message Retraction](https://xmpp.org/extensions/xep-0424.html)
Before implementing, some changes are on their way: https://github.com/xsf/xeps/pull/1270[XEP-0424 Message Retraction](https://xmpp.org/extensions/xep-0424.html)
Before implementing, some changes are on their way: https://github.com/xsf/xeps/pull/1270https://dev.gajim.org/gajim/python-nbxmpp/-/issues/137Update XEP-0425 Message Moderation implementation2024-03-19T05:37:40ZDaniel BrötzmannUpdate XEP-0425 Message Moderation implementationChanges are planned here: https://github.com/xsf/xeps/pull/1271Changes are planned here: https://github.com/xsf/xeps/pull/1271https://dev.gajim.org/gajim/python-nbxmpp/-/issues/133Implement XEP-0410: MUC Self-Ping (Schrödinger's Chat)2023-02-22T11:11:22ZDaniel BrötzmannImplement XEP-0410: MUC Self-Ping (Schrödinger's Chat)From [XEP-0410: MUC Self-Ping (Schrödinger's Chat)](https://xmpp.org/extensions/xep-0410.html):
> The Multi-User Chat (XEP-0045) protocol was not designed to handle s2s interruptions or message loss well. Rather often, the restart of a ...From [XEP-0410: MUC Self-Ping (Schrödinger's Chat)](https://xmpp.org/extensions/xep-0410.html):
> The Multi-User Chat (XEP-0045) protocol was not designed to handle s2s interruptions or message loss well. Rather often, the restart of a server or a component causes a client to believe that it is still joined to a given chatroom, while the chatroom service does not know of this occupant.
> This specification aims to provide the most efficient, albeit not the most elegant, way for clients to periodically check whether they are still joined to a chatroom. However, it can not ensure that a client remains joined to a room without any interruptions.https://dev.gajim.org/gajim/python-nbxmpp/-/issues/115IBB sequence overflow2020-12-18T13:01:23ZZashIBB sequence overflowAccording to [XEP-0047](https://xmpp.org/extensions/xep-0047.html#send) the `seq` number must overflow after 65535 but I don't see `nbxmpp/modules/ibb.py` doing anything about this. Maybe it doesn't need to, seems Gajim does.
It may be ...According to [XEP-0047](https://xmpp.org/extensions/xep-0047.html#send) the `seq` number must overflow after 65535 but I don't see `nbxmpp/modules/ibb.py` doing anything about this. Maybe it doesn't need to, seems Gajim does.
It may be appropriate to reject `seq > 65535`.https://dev.gajim.org/gajim/python-nbxmpp/-/issues/98Use XEP-0198 ack requests instead of iq pings when available2020-02-10T19:37:17ZzimioUse XEP-0198 ack requests instead of iq pings when availableIn xep-198 it says:
"When an \<r/> element ("request") is received, the recipient MUST acknowledge it by sending an \<a/> element to the sender containing a value of 'h' that is equal to the number of stanzas handled by the recipient of...In xep-198 it says:
"When an \<r/> element ("request") is received, the recipient MUST acknowledge it by sending an \<a/> element to the sender containing a value of 'h' that is equal to the number of stanzas handled by the recipient of the \<r/> element. The response SHOULD be sent as soon as possible after receiving the \<r/> element, and MUST NOT be withheld for any condition other than a timeout."
Gajim doesn't have a timeout for requests. There should be a timeout for that, and it should attempt reconnection.