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.
This message constitutes notice of a Last Call for comments on
XEP-0424.
Title: Message Retraction
Abstract:
This specification defines a method for indicating that a message
should be retracted.
URL: https://xmpp.org/extensions/xep-0424.html
This Last Call begins today and shall end at the close of business on
2025-01-06.
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!
Greetings!
I am drafting a post to next Tuesday evening about Metalink.
I did a superficial search, and I did not find a mention of Metalink in
the XEP index.
Metalink is known as standard RFC 5854, and RFC 6249.
> Metalink supports listing of multiple partial and full file hashes
> along with PGP signatures. It supports listing any URI (i.e. FTP,
> Gemini, HTTP, rsync, BitTorrent, eD2k, IPFS, magnet link etc.).
It also has a "description" field, which is crucial in messaging
system, as it can save the effort of sending an extra message to
describe the content. This saves in half the number of messages upon
sharing files via messages.
See the example Metalink file in the following post.
https://portal.mozz.us/gemini/woodpeckersnest.space/~schapps/journal/2024-1…
In the example Metalink file, the content is available via BitTorrent,
eD2k, FTP, HTTP, and Kad.
Handling Metalink would be of benefit to XMPP.
Sending of a file:
> http://hfu.xmpp.i2p/StealThisFilm.Part1.avi
> This is the first part of the movie "Steal This Film I" from 2006.
Sending of a Metalink file:
> http://hfu.xmpp.i2p/StealThisFilm.Part1.metalink
XMPP client parses the Metalink file (StealThisFilm.Part1.metalink),
and displays the given description which is found in that file.
I advise to create an XEP for handling of Metalinks.
I would be greateful to whom who would want to intstruct me.
Kind regards,
Schimon
Hi,
as a member of the SCAM Team¹ I’m proud to announce that the 27th XMPP
Summit will take place on Thursday January 30th and Friday January
31st 2025 in Brussels, Belgium.
As usual we picked the two days before FOSDEM² takes place in the same city.
https://wiki.xmpp.org/web/Conferences/Summit_27
If you are planning on coming please sign up on the wiki. (We have
somewhat limited capacity)
If you are unsure if the Summit is right for you, I (not in my
capacity as a member of the SCAM team) wrote a short thread on
Mastodon describing what the Summit typically looks like:
https://gultsch.social/@daniel/113385481055735606
See you in Brussels!
cheers
Daniel
¹: Summits Conferences & Meetups Team https://xmpp.org/about/xsf/scam-team/
²: https://fosdem.org/2025/
This message constitutes notice of a Last Call for comments on
XEP-0421.
Title: Anonymous unique occupant identifiers for MUCs
Abstract:
This specification defines a method that allows clients to identify a
MUC participant across reconnects and renames. It thus prevents
impersonification of anonymous users.
URL: https://xmpp.org/extensions/xep-0421.html
This Last Call begins today and shall end at the close of business on
2025-01-06.
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!
Hi all,
Further to the note in the LC thread on XEP-0424, I'd really like to have a
document (XEP, probably) that answers these questions:
What are the risks of choosing an stanza identifier that is not unique?
Does this still matter if the stanza identifier is unique to the session?
To the sending jid? To the bare jid of the sender?
What about missing off the stanza id attribute entirely?
What about MUC? PubSub? Etc?
If people have opinions, write away, and I'll volunteer to collate these
into a XEP (or, possibly, a patch against XEP-0359).
My reasoning is that we seem to vaguely know things can get Bad, but I for
one can't find where we've documented these Bad Things. I'd be delighted to
be corrected, as ever.
Dave.
Hey hey,
Boring incoming:
https://github.com/xsf/xeps/pull/1407
This is draft to avoid the XSF Board accidentally approving it before the
community has had a chance to discuss.
The main change is the paragraph added in Section 6 (Discussion Process),
covering changes to the XEP during Experimental:
The XEP author incorporates the feedback by creating source control patches
> (such as Pull Requests), in line with the preferred method in &xep0143;.
> Direct changes to an Experimental XEP, such as a contributor providing a
> patch (or Pull Request on GitHub), are still the responsibility of the XEP
> author, and are only applied if the XEP author agrees. If a XEP has
> multiple authors, while agreement is sought from all authors, only those
> opinions from responsive authors are considered. If the Approving Body
> feels that the XEP author is not responsive, another author may be added
> unilaterally by the Approving Body.
This is trying to do two things:
1) Document the existing practice that the XMPP Council has followed,
whereby changes to Experimental XEPs need "agreement" (PR approval, or
similar) from the XEP Author.
2) Document the existing practice that the XMPP Council has followed.
whereby if a XEP Author isn't responsive (ie, doesn't respond to emails,
etc) the XMPP Council can add a new XEP Author.
3) Document the *new practice* that if a contribution isn't a PR, it's the
XEP Author who is responsible to turn it into one.
The rest of the changes surface and restate existing process/policy/URLs
and aren't that interesting (well, even less interesting).
There is one additional possible process deviation we should document (or
call the Process Police out, or something). Submission of a XEP, as per
XEP-0143, occurs via email tot he Editor. Is this really still the case? Or
are these now by PR? That'll need changing in XEP-0143, which I'm happy to
do if that's the case. It'd be nice to have a non-PR variant of the process
(post here?)
Dave.
Version 0.1.0 of XEP-0502 (MUC Activity Indicator) has been released.
Abstract:
This specification provides querying entities an approximate
indication of the level of activity in a given XEP-0045 Multi-User
Chat room.
Changelog:
Promoted to Experimental (XEP Editor: dg)
URL: https://xmpp.org/extensions/xep-0502.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.2.0 of XEP-0501 (Pubsub Stories) has been released.
Abstract:
This specification defines a way of publishing Stories over XMPP.
Changelog:
Add pubsub#item_expire in the node configuration (tj)
URL: https://xmpp.org/extensions/xep-0501.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 have setup the membership application Wiki page for the application
period Q1 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_Q1_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
