- Standards

Proposed XMPP Extension: Pubsub Node Bookmark

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Pubsub Node Bookmark Abstract: This specification defines a bookmark element pointing to a Pubsub node URL: https://xmpp.org/extensions/inbox/pubsub-node-bookmark.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

4 weeks

1
0
0 0

UPDATED: XEP-0317 (Hats)

by Daniel Gultsch

Version 0.3.1 of XEP-0317 (Hats) has been released. Abstract: This specification defines a more extensible model for roles and affiliations in Multi-User Chat rooms. Changelog: Typos, completed some examples and paragraph clarifications thanks to badlop feedback. (tj) URL: https://xmpp.org/extensions/xep-0317.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.

4 weeks

1
0
0 0

( XEP-0449) Are packless stickers legal?

by Nicolas Cedilnik

Hi all and llarma (XEP-0449 author) in particular, It's not clear in the spec whether it is allowed to have a <sticker> element without "pack" attribute. I know that the XEP is mostly about specifying how packs work; but I am looking for a way to convey the information that an attachment is a sticker. My use-case is between slidge and movim (for now, but maybe other client devs are interested…), and not in a "pack" context. We could use a non-standard element, but if you intended to make packless XEP-0449 stickers legal, let's use your XEP! Basically, we would just add an empty <stickerxmlns='urn:xmpp:stickers:0' />to an attachment (specified via oob and/or SIMS and/or SFS -_-). Did you intend to make this legal or should we use something else? Thanks for your reply, -- nicoco

1 month

1
0
0 0

New ProtoXEP: Pubsub Node Bookmark

by Timothée Jaussoin

Hi, I'm submitting a new XEP named Pubsub Node Bookmark after the work we did with nicoco on the XEP-0503: Spaces. This XEP is quite simple and defines a new <pubsub-node/> element that act as a bookmark that point to a Pubsub Node. The goal is to have something very similar to the <conference/> node defined in XEP-0402: PEP Native Bookmarks, a <pubsub-node/> is even having an <extensions/> item that is compatible with the ones of XEP-402, allowing Pubsub Node Bookmarks to be pinned (https://xmpp.org/extensions/xep-0402.html) or having custom notifications settings (https://xmpp.org/extensions/xep-0492.html). As you see in the example bellow the id is defined the same way as the ids in XEP-0402 but this time by using a Pubsub URI. Here is an example: <itemid='bookmarks.library.org?;node=books'><pubsub-nodexmlns="urn:xmpp:pubsub-node_bookmark:0"jid="bookmarks.library.org"node="movies"><extensions><pinnedxmlns='urn:xmpp:bookmarks-pinning:0'/></extensions></pubsub-node></item> Why this XEP ? A Space is defined as a list of items in a Pubsub Node, those items can be MUCs but also Pubsub Nodes (for example if you want to have a Blog or Newsletter in your Space). Movim is using something a bit similar in an old XEP I defined in 2013: https://xmpp.org/extensions/xep-0330.html, if Pubsub Node Bookmark is published, I'll update XEP-0330 to be based on that one. You can find a HTML version there: https://movim.eu/xeps/pubsub-node-bookmark.html I'd be happy to get feedbacks to see how things can be improved :) Regards, edhelas

1 month, 1 week

2
1
0 0

XEP-0503: Spaces update proposal

by Nicolas Cedilnik

Hi all, I just submitted a revision to XEP-0503: Spaces. This is something edhelas and I have been working on last week. I intend to implement it in slidge, and he intends to implement UI for it in movim. It is an almost complete rewrite vs the current state, which should not be an issue since it has not been implemented anywhere yet. I tried to incorporate the feedback I got, not only from the mailing but in various MUCs and private conversations I had about the XEP here and there. In short, a space is now just a pubsub node with appropriate configuration and payload, and a space service is a pubsub service with feature requirements. As per the previous revision, the goal of this XEP is to establish a minimal viable protocol for clients and servers to build around the general concept of grouping several entities together. It requires little to no additional support server-side and should work, in a very basic form, with what's already available out there. I believe, that, even in this basic form, it would be nice to have. edhelas and I will also submit soon(ish) another XEP which could be _a_ way of defining how space-wide affiilations/roles/hats could work, by using a "space's main MUC". That would allow for both optimising presence traffic and enforcing consistency between the various rooms of a space. This, of course, would require some additional server and client support, but it looks like we can do something that is relatively usable on any MUC-supporting client. I think it is best to have this in a separate XEP, for future-proofness, since GC3 is just around the corner. ;o) Let me know what you think. -- nicoco

1 month, 1 week

4
9
0 0

XMPP Council Agenda 2025-09-16

by Daniel Gultsch

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, September 16 2025 at 15:30 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update • UPDATED: XEP-0503 (Server-side spaces) https://xmpp.org/extensions/xep-0503.html 4) Items for voting a) XEP-0060 / XEP-0248: Improve separation of 'collections' https://github.com/xsf/xeps/pull/1455 b) XEP-0060 & XEP-0248: Default node-type specific configuration https://github.com/xsf/xeps/pull/1460 c) XEP-0070: extend security section https://github.com/xsf/xeps/pull/1453 d) Issue Last Call on 'XEP-0440: SASL Channel-Binding Type Capability' https://xmpp.org/extensions/xep-0440.html 5) Pending votes none See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEU… 6) Date of Next 7) AOB 8) Close

1 month, 1 week

1
0
0 0

UPDATED: XEP-0503 (Server-side spaces)

by Daniel Gultsch

Version 0.2.0 of XEP-0503 (Server-side spaces) has been released. Abstract: This document defines an XMPP protocol to cluster several groupchat rooms together. Changelog: Rewrite using pubsub semantics. (nc) URL: https://xmpp.org/extensions/xep-0503.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.

1 month, 1 week

1
0
0 0

Fwd: XEP-0376 (Pubsub Account Management): some feedbacks

by Goffi

Hello, I'm forwarding this old message, as it has never been answered, and the author (namely Dwd) is more active these days. PAM is very useful in Pubsub toolbox, and I would like to see this specification in a better state :). Thanks! Goffi ---------- Message transmis ---------- Objet : [Standards] XEP-0376 (Pubsub Account Management): some feedbacks Date : vendredi 15 avril 2022, 10:41:49 heure d’été d’Europe centrale De : Goffi <goffi(a)goffi.org> À : standards(a)xmpp.org Hi, I'm currently implementing XEP-0376 both client and service side, and here are my feedbacks. # Form: - a small typo in example 1, it's "xmlns" ("s" is missing) - § 3.3 Unsubscribing: even if it's obvious, an explicit example would be welcome for unsubscribe too - there are a lot of questions on this XEP, I'm not sure if it's the best location for that, IMHO discussing this on standard@ would be more appropriate. - § 5 XMPP Registrar Considerations: even if it made me smile a bit, I don't think that XEP (beside humourous ones) is a location for this kind of jokes. It's not a big deal for experimental XEPs though. # Substance: * § 3.5 auto-subscriptions and § 3.6 Filtering I don't really understand the sentence "this implies that servers would gradually acrue any node type which the user has had a capable client at any time.". Could you formulate it more clearly or at least explain it? Regarding auto-subscription, XEP-0060 is not great itself about it as it's mentioning "root collections" and "subsciption_depth" which are notions of XEP-0248 (and I don't think that there are many complete implementations of it, if any). But that's a topic which should be discussed on a different thread. That put aside, I'm not sure that XEP-0376 should take care at all of auto- subscription regarding that we have already the filtering with +notify. This is done on a per-client basis, and if client wants to get says OMEMO public keys or user mood because it supports those features, I don't see the need to keep track of it at the server level. Sure it's broadcast. To my experience this is not a problem: I use +notify to auto-subscribe when I want update from all users to which I'm presence subscribed, and if I want only events for a specific user/node, I use an explicit subscription (in which case PAM is useful). Thus I would remove entirely § 3.5 and § 3.6, or replace them by a text indicating that PAM service ignores them and they work as usual with XEP-0060/ XEP-0163 auto-subscription and filtering. This would make the whole thing simpler, but please explain me with a clear use-case if I'm missing something. * § 3.7 interaction with MAM I guess events should be archived normally by MAM (at least to be sure that all clients receive them correctly), and I really don't see the need to filter them out (that's only events about explicit (un)subscription to nodes, the traffic should not be high). [this par below is forwarded from a follow-up email] > * § 3.7 interaction with MAM > > I guess events should be archived normally by MAM (at least to be sure that all clients receive them correctly), and I really don't see the need to filter them out (that's only events about explicit (un)subscription to nodes, the traffic should not be high). Second thought: are you talking about the (un)subscribe notification as explained at § 3.2, or XEP-0060 items events? In the later case yes, filtering is probably desirable: if my client doesn't handle blogging, it probably doesn't want all the XEP-0277 items notifications. That's it for now. It's a useful addition to pubsub in XMPP, and I hope to see more implementation in close future. Cheers Goffi

1 month, 2 weeks

3
2
0 0

XSF membership application period Q4 2025

by Alexander Gnauck

I have setup the XSF membership application Wiki page for the application period Q4-2025 Applications are encouraged from developers and others who are involved in the Jabber/XMPP community. To apply, create a page about yourself on the Wiki here: https://wiki.xmpp.org/web/Membership_Applications_Q4_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 When you need help with your application then don't hesitate to contact me directly Apply now!!! Thanks, Alex

1 month, 2 weeks

1
0
0 0

Navigation instructions for Atom Over XMPP (XEP-0277 and XEP-0472)

by Schimon Jehudah

Good day. About ===== I have recently suggested at project Movim to add navigational instructions to Atom entries (i.e. posts). I am still experimenting it, and it currently seems useful. Technicality ============ The idea is realized in a similar fashion to the classification of comments node with rel='replies' and title='comments'. https://xmpp.org/extensions/xep-0277.xml#comments Navigation ========== I advise to enable navigational instructions with rel='navigation' and title='previous' and title='proceed', and perhaps also title='index'. At the bottom of this page there are proceed or previous links to navigate and are generated from the instructions proposed above. https://journal.woodpeckersnest.eu/posts/2024-11-05-xmpp-as-the-internet/ Advantages ========== Navigational instructions would conveniently facilitate the creation of a CMS even over a single PEP node, without a compulsory need of having a PubSub service with multiple nodes to do so, by relating from post to post from within each posts. Navigational instructions would also incentivise the creation of articles that are segmented into parts of a series of posts, and portability thereof. Kind regards, Schimon

1 month, 3 weeks

1
0
0 0

2025

2024

2023