Version 0.1.1 of XEP-0473 (OpenPGP for XMPP Pubsub) has been released.
Abstract:
Specifies an OpenPGP for XMPP (XEP-0373) profile for the pubsub use
case.
Changelog:
Fix inconsistency between text and example; it's the 'key' attribute
that carries the shared secret ID (formerly it was 'secret'). (jp)
URL: https://xmpp.org/extensions/xep-0473.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.
I am intending to connfigure an existing node, which is particulatly
useful when intending to change routine (i.e. "default") configurations.
Is it a necessary requirement to request a form; or, is it possible to
configure a node at once, without requesting a form?
https://xmpp.org/extensions/xep-0060.xml#owner-configure
I thank you for any sort of help.
Kind reagrds,
Schimon
This message constitutes notice of a Last Call for comments on
XEP-0377.
Title: Spam Reporting
Abstract:
This document specifies a mechanism by which users can report spam and
other abuse to a server operator or other spam service.
URL: https://xmpp.org/extensions/xep-0377.html
This Last Call begins today and shall end at the close of business on
2026-01-05.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
Version 0.1.0 of XEP-0511 (Link Metadata) has been released.
Abstract:
This specification describes how to attach metadata for links to a
message.
Changelog:
Accepted as Experimental by council vote (dg)
URL: https://xmpp.org/extensions/xep-0511.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: Link Metadata
Abstract:
This specification describes how to attach metadata for links to a
message.
URL: https://xmpp.org/extensions/inbox/link-metadata.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-0510 (End-to-End Encrypted Contacts Metadata) has
been released.
Abstract:
This specification describes how to encrypt contacts metadata to
minimize server exposure.
Changelog:
Accepted as Experimental by council vote (dg)
URL: https://xmpp.org/extensions/xep-0510.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.8.0 of XEP-0353 (Jingle Message Initiation) has been
released.
Abstract:
This specification provides a way for the initiator of a Jingle
session to propose sending an invitation in an XMPP message stanza,
thus taking advantage of message delivery semantics instead of sending
IQ stanzas to all of the responder's online resources or choosing a
particular online resource.
Changelog:
Adapt usage of JID types to real-world usage:
* Send JMI responses to full JID of initiator instead of bare JID
* Send JMI <finish/> element to full JID of both parties (melvo)
URL: https://xmpp.org/extensions/xep-0353.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.
I quite like XEP-0392. I didn't honestly think I would when it first
proposed and published, but it's really handy.
But, XEP-0392 doesn't - anywhere - specify what the "input" should be. I
can see some options:
1) Pick the relevant jid. I'm currently using the bare jid for 1:1
conversations, and the XEP-0045 occupant jid (including nickname) for MUCs.
That seems the most obvious, but means nickname changes also change colour.
2) Pick the display name. I could use the name for 1:1 (the one I display,
from Roster etc) and the nickname from a MUC. That has the advantage that
where those are the same, the colour will be consistent - "Zash" will be
coloured the same on all MUCs, for example.
3) Pick the most stable identifier I can. So occupant_id in MUC,
though still bare Jid for 1:1. This would mean the bright pink occupant
would remain bright pink no matter what nickname change they tried. No
escape!
Any suggestions? Or doesn't it matter?
Dave.
