October 2024 - Standards

Proposed XMPP Extension: PubSub Server Information

by kevin.smith＠isode.com

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.

3 months, 3 weeks

3
3
0 0

Join us at the 27th XMPP Summit

by Daniel Gultsch

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/

8 months, 4 weeks

1
1
0 0

XEP-0163 (Personal Eventing Protocol) Allow multiple publishers; XEP-0045 (Multi-User Chat) Allow PEP

by Schimon Jehudah

Good day! I am the developer of Slixfeed news bot, which is a syndication feed reader (Atom/RDF/RSS). This matter is also related to Morbot. See https://codeberg.org/TheCoffeMaker/Morbot/issues/13 Concern ------- I have to attempted experiment with PEP nodes, and my attempt has failed due to: XEP-0045 service-unavailable The feature requested is not supported by the conference XEP-0163 forbidden You're not allowed to create nodes Proposal -------- I suggest to enable PEP nodes for MUC JIDs too. I suggest to change the approach "One publisher per node.". See https://xmpp.org/extensions/xep-0163.html#approach-publisher > There is no need for multiple publishers to a PEP service, since by > definition the service generates information associated with only one > entity. The owner-publisher for every node is the bare JID of the > account owner. In order to allow a secondary "channel" interface for people and group chats, and also for other reasons (see further), it would be useful to: 1) Allow multiple publishers. 2) Allow PEP for MUC JIDs. By a "channel" interface, I mean, that should a news bot be included for a group chat, the updates would be sent to a PEP node of the group chat JID instead to the chat itself, which would keep the chat view cleaner. Example use cases: Number #3 represents the use of Morbot and Slixfeed, and is useful for forwarding of news journals. 1) Use : Inbox Affiliation : Publish-Only Publishers : JIDs which Presence is shared with or in Roster 2) Use : Collaboration (e.g. Pad, Whiteboard etc.) Affiliation : Publisher Publishers : Determined manually 3) Use : Updates Affiliation : Publish-Only Publishers : Determined manually Note ---- Slixfeed can use its own PEP nodes named after its subscribers respectively, albeit that would be more demanding on the server of which Slixfeed is operated on, than publishing to PEP nodes of other JIDs, and yet it would not be practical for group chat JIDs, which the bot also supports. Please advise. Kind regards, Schimon

9 months, 4 weeks

4
13
0 0

LAST CALL: XEP-0490 (Message Displayed Synchronization)

by Daniel Gultsch

This message constitutes notice of a Last Call for comments on XEP-0490. Title: Message Displayed Synchronization Abstract: This specification allows multiple clients of the same user to synchronize the displayed state of their chats. URL: https://xmpp.org/extensions/xep-0490.html This Last Call begins today and shall end at the close of business on 2024-10-31. 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!

11 months

4
3
0 0

Problem with the mailing list

by Schimon Jehudah

Good day! Am I the only one to not receive emails that are sent by Mr. Jérôme Poisson? (Email "goffi") Kind regards, Schimon

11 months, 1 week

6
10
0 0

Proposed XMPP Extension: Pubsub Extended Discovery

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Pubsub Extended Discovery Abstract: This specification extends the discovery requests used with the XMPP PubSub protocol by introducing mechanisms to discover linked nodes, descendants, or metadata. URL: https://xmpp.org/extensions/inbox/pubsub-extended-discovery.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

11 months, 1 week

3
2
0 0

Proposed XMPP Extension: Pubsub File Sharing

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Pubsub File Sharing 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. URL: https://xmpp.org/extensions/inbox/pubsub-file-sharing.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

11 months, 1 week

3
2
0 0

Proposed XMPP Extension: Pubsub Extended Subscriptions

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Pubsub Extended Subscriptions 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. URL: https://xmpp.org/extensions/inbox/pubsub-extended- subscription.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

11 months, 1 week

3
2
0 0

XMPP Council Agenda 2024-10-29

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, October 29 2024 at 16:00 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * UPDATED: XEP-0394 (Message Markup) * UPDATED: XEP-0491 (WebXDC) * Proposed XMPP Extension: Pubsub File Sharing * Proposed XMPP Extension: Pubsub Extended Discovery 4) Items for voting a) Proposed XMPP Extension: Pubsub File Sharing https://xmpp.org/extensions/inbox/pubsub-file-sharing.html b) Proposed XMPP Extension: Pubsub Extended Discovery https://xmpp.org/extensions/inbox/pubsub-extended-discovery.html 5) Pending votes * Dan and Daniel on 'Proposed XMPP Extension: Pubsub Node Relationships' See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

11 months, 1 week

2
1
0 0

A public profile page

by Schimon Jehudah

Good day, one and all! I want to work on an XEP which would define "link collections", which I think would also be useful for FASI (HTML invite page for XMPP), which already indicates of articles, when articles are present (see attached image). See example profiles under "New Members" at https://libertylinks.io Would Data Forms be the appropriate mean to achieve it? Kind regards, Schimon

11 months, 1 week

3
6
0 0

2025

2024

2023

Standards October 2024