The XMPP Extensions Editor has received a proposal for a new XEP.
Title: MUC Slow Mode
Abstract:
This specification describes a way to rate limit messages a single
user can send to a MUC room. It includes room configuration option,
and how servers and clients can handle such a feature.
URL: https://xmpp.org/extensions/inbox/xep-slow-mode.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Version 0.1.0 of XEP-0500 (MUC Slow Mode) has been released.
Abstract:
This specification describes a way to rate limit messages a single
user can send to a MUC room. It includes room configuration option,
and how servers and clients can handle such a feature.
Changelog:
Promoted to Experimental (XEP Editor: dg)
URL: https://xmpp.org/extensions/xep-0500.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 1.0.1 of XEP-0490 (Message Displayed Synchronization) has been
released.
Abstract:
This specification allows multiple clients of the same user to
synchronize the displayed state of their chats.
Changelog:
* Fix some examples, and their indentation.
* Add the XML Schema. (egp)
URL: https://xmpp.org/extensions/xep-0490.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Good morning newly elected Council
the first XMPP Council Meeting will take place on, Tuesday, November
26 2024 at 16:30 UTC in xmpp:council@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Elect new Chair
4) Editors update
* NEW: XEP-0496 (Pubsub Node Relationships)
* NEW: XEP-0497 (Pubsub Extended Subscriptions)
* NEW: XEP-0498 (Pubsub File Sharing)
* NEW: XEP-0499 (Pubsub Extended Discovery)
* Proposed XMPP Extension: MUC Slow Mode
5) Items for voting
a) XEP-0490: Add the XML Schema and fix some examples
https://github.com/xsf/xeps/pull/1400
b) Proposed XMPP Extension: MUC Slow Mode
https://xmpp.org/extensions/inbox/xep-slow-mode.html
c) Make Daniel (co-)author of 'XEP-0343: Signaling WebRTC datachannels
in Jingle'
https://xmpp.org/extensions/xep-0343.html
6) Pending votes
none yet
Here is the all new spreadsheet:
https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEU…
7) Date of Next
8) AOB
9) Close
P.S.: This is the first council email that does not get send to the
council mailing list. The previous council has decided to get rid of
that list and only use 'standards'.
Version 0.1.0 of XEP-0499 (Pubsub Extended Discovery) has been
released.
Abstract:
This specification extends the discovery requests used with the XMPP
PubSub protocol by introducing mechanisms to discover linked nodes,
descendants, or metadata.
Changelog:
Promoted to Experimental (XEP Editor: dg)
URL: https://xmpp.org/extensions/xep-0499.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 0.1.0 of XEP-0498 (Pubsub File Sharing) has been released.
Abstract:
This specification explains how to share files and optionally include
directory structures similar to filesystems over XMPP Pubsub. It
leverages XMPP Pubsub to enable notifications about file changes and
manage permissions, providing users with real-time updates and control
mechanisms. An optional mechanism is also specified for managing
uploaded files.
Changelog:
Promoted to Experimental (XEP Editor: dg)
URL: https://xmpp.org/extensions/xep-0498.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 0.1.0 of XEP-0497 (Pubsub Extended Subscriptions) has been
released.
Abstract:
This specification extends the XMPP PubSub protocol by introducing
mechanisms for users to subscribe to an entire node hierarchy or to
receive notifications on node metadata updates.
Changelog:
Promoted to Experimental (XEP Editor: dg)
URL: https://xmpp.org/extensions/xep-0497.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 0.1.0 of XEP-0496 (Pubsub Node Relationships) has been
released.
Abstract:
This specification describes how to establish links between pubsub
nodes, allowing for optional hierarchical organization.
Changelog:
Promoted to Experimental (XEP Editor: dg)
URL: https://xmpp.org/extensions/xep-0496.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Hi,
TLDR: It is common practice for CSI (Client State Indication)
implementations to withhold (and deduplicate) PEP notifications and/or
headline messages. Due to the rise of XEPs such as Message Displayed
Synchronization (MDS) those implementations need to be changed to
immediately let through PEP notifications from nodes that are on the
account itself.
I noticed the MDS problem in theory a while ago but didn’t care too
much because due to a lack of implementations I’m not using MDS on a
daily basis. (MDS needs to be able to dismiss notifications even if
the client is in background)
However today I ran into a related problem with Bookmarks 2 and User Nickname.
I was writing code that actually performs a rename in a MUC if the
desired nick changes (either pulled from the bookmark or if that one
is unset from XEP-0172) instead of only using these sources on initial
join. I think it is somewhat obvious that the rename should be done
fairly instantly on all clients once a client has made the change
(either to the bookmark or to 0172). Otherwise other users would see
the user as being joined multiple times with different nicks until all
clients have come to the foreground.
I guess letting through all PEP notifications from the account
(instead of allow listing certain nodes) is good enough. That’s
beneficial for Nick, Bookmarks, OMEMO. The only one for which we
technically don’t need it is Avatar. But how often do you change that
one (meaning how many false positives would you generate?!)
cheers
Daniel
Version 1.0.0 of XEP-0490 (Message Displayed Synchronization) has been
released.
Abstract:
This specification allows multiple clients of the same user to
synchronize the displayed state of their chats.
Changelog:
Accept as Stable as per Council Vote from 2024-11-05. (XEP Editor
(dg))
URL: https://xmpp.org/extensions/xep-0490.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.