Version 0.1.4 of XEP-0284 (Shared XML Editing) has been released.
Abstract:
This specification defines a protocol that enables two or more
endpoints to collaboratively edit an XML object. The protocol is
intended for use mainly over the Extensible Messaging and Presence
Protocol (XMPP), either by existing instant messaging clients or by
specialized editing clients. However, the protocol could also be used
over a direct TCP connection rather than over XMPP.
Changelog:
* Fix the registrar section.
* Format the glossary better.
* Add missing <state/> wrappers in examples.
* Write an XML Schema. (egp)
URL: https://xmpp.org/extensions/xep-0284.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.
Greetings.
Preface
-------
I would want to advise to extend XEP-0107 (User Mood) and XEP-0108
(User Activity), so that it would be possible to selectively advertize
of activities and moods.
This is beneficial for both humans and machines.
Because the examples for humans may be vague, I will write an obvious
case for machines.
Service
-------
KaikOut is a moderation service (i.e. "bot", so called) for group chats.
As with traffic signs, and unlike status messages, activity and mood
are fixated, even though both have an option for custom text, and
because of it, they can be used as constant and accurate indicators for
activity and state of machines.
That is, activities and moods can be used as signs, and also to signal
of events. See further examples.
Additionally, status messages, activities and moods serve different
purposes, which is another reason to have an option of selective
advertizing for activity and mood.
Example
-------
This is a realization of using activities and moods in a selective
fashion over different group chats simultaneously.
Ideas with XEP-0107: User Mood
------------------------------
amorous:
When KaikOut writes good scores.
annoyed:
When KaikOut writes bad scores.
ashamed:
When KaikOut demotes a moderator.
calm or bored:
When group activity is under a certain level.
happy or relaxed:
When moderation activity is under a certain level.
restless:
When moderation activity is above a certain level.
cautious or serious:
Routine mood.
remorseful or frustrated or sleepy:
When KaikOut is disabled.
proud:
When KaikOut bans or kicks an occupant.
ashamed or shocked:
When a group chat owner pormotes a moderator which was demoted by
KaikOut.
surprised:
When KaikOut is demoted.
thankful:
When KaikOut is set to be a moderator.
Ideas with XEP-0108: User Activity
----------------------------------
working:
When KaikOut writes scores.
sleeping:
When KaikOut is inactive.
Reference:
https://git.xmpp-it.net/sch/KaikOut/issues/36
Kind regards,
Schimon
I have setup the membership application Wiki page for the application
period Q3 2025
Applications are encouraged from developers and others who are actively
involved in the Jabber/XMPP community. To apply, create a page about
yourself on the Wiki:
https://wiki.xmpp.org/web/Membership_Applications_Q3_2025
If you don't have a wiki account, send your full name, preferred
nickname and email address to me or one of the other Sysops:
https://wiki.xmpp.org/web/Sysops
Apply now!!!
Thanks,
Alex
Hi,
Section 8.5.4 provides a summary of earlier sections. It uses the term
"active resource" twice. This term is not used in any of the earlier
sections.
Conversely, the earlier sections use the term "Connected Resource" a couple
of times. A "Connected Resource" is defined by RFC6121/6120 as "[has] bound
a resource to the stream"
Although the term "Connected Resource" is used in section 8.5, none of the
specifications therein seem to apply to Connected Resources.
The usage of the term "active resource" in section 8.5.4 could be an
artifact of RFC3921/3920, which defines an "active resource" as: "Upon
establishing a session, a connected resource (in the terminology of
[XMPP-CORE]) is said to be an "active resource."
Although section 8.5 advertises that it will define how stanzas related to
connected resources are to be processed ("If there is at least one
available resource or connected resource, how the stanza is processed
depends on the stanza type.") it does not seem to do that. All definitions
seem to depend on having at least one available resource (which is defined
as a connected resource that has sent initial presence), leaving scenarios
in which only connected resources are present, undefined.
Am I misinterpreting this? If not, is this something that should be cleared
up (or explicitly be left undefined)?
As a practical example of a question that I believe is left unanswered: How
should a server process a message stanza of type 'normal', addressed to a
bare JID that represents a local user (the scenario of section 8.5.2.1.1 of
RFC 6121) if the corresponding user only has one or more Connected
Resources (but not any Available Resources)? I believe that there are many
possible variations on this question, I'm limiting it to one to illustrate
the larger issue that I described in this email.
For additional context: this was discussed in the XSF's Discussion MUC
earlier. Logs of that conversation can be found at
https://logs.xmpp.org/xsf/2025-05-28#2025-05-28-a5d887bd6428222c
Kind regards,
Guus
Version 0.1.1 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:
Fix wrong shortname and add tags. (jp)
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.1 of XEP-0485 (PubSub Server Information) has been
released.
Abstract:
This document defines a data format whereby basic information of an
XMPP domain can be expressed and exposed over pub-sub.
Changelog:
* Fixed references to XEP identifier. (gdk)
URL: https://xmpp.org/extensions/xep-0485.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.3 of XEP-0388 (Extensible SASL Profile) has been released.
Abstract:
This document describes a replacement for the SASL profile documented
in RFC 6120 which allows for greater extensibility.
Changelog:
* Add missing minOccurs='0' to additional-data in <continue/> in XML
schema. (lnj)
URL: https://xmpp.org/extensions/xep-0388.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.9.0 of XEP-0384 (OMEMO Encryption) has been released.
Abstract:
This specification defines a protocol for end-to-end encryption in
one-to-one chats, as well as group chats where each participant may
have multiple clients per account.
Changelog:
Device labels must be signed
Allow empty device list in XML schema
Reworded security consideration that could be interpreted as
forbidding trust mechanisms like BTBV/TOFU
Added section about dealing with lack of presence subscription
Removed reference to omemo-session-healing (th)
URL: https://xmpp.org/extensions/xep-0384.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.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: PubSub Server Information
Abstract:
This document defines a data format whereby basic information of an
XMPP domain can be expressed and exposed over pub-sub.
URL: https://xmpp.org/extensions/inbox/pubsub-server-info.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
