- Standards

XSF membership application period Q4 2024

by Alexander Gnauck

I have setup the membership application Wiki page for the application period Q4 2024 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 at: https://wiki.xmpp.org/web/Membership_Applications_Q4_2024 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

2 days, 7 hours

1
0
0 0

Atom Over XMPP (XEP-0277 and XEP-0472) classifying comments and reactions

by Schimon Jehudah

Good day! I am working on Rivista[1], which is a journal publisher for XMPP. I test instances of Libervia and Movim against Rivista. Most of the tests are conducted against the official instance of Movim. The matter of this message is concerning to Adding a Comment[2] (clause 3.2 to XEP-0277). I have noticed that "reactions" are manifested exactly the same as comments, inside element title. The couple of indications that a comment is a reaction are: 1) Element title has a single character; or 2) The character or character combination is included in the range of characters that are dedicated for reactions. I would suggest to use a classifier. 1) Use element title as a classifier of post type, either a comment or a reaction, and use element summary as a handler for the comment itself; or 2) Use element category (e.g. xmpp:comment and xmpp:reaction); or 3) Utilize "Extension Elements" (clause 6.4 to RFC 4287). I think that solution #3 would be the ideal solution. Current ------- <entry xmlns='http://www.w3.org/2005/Atom'> <author> <name>Juliet Capulet</name> <uri>xmpp:juliet@capulet.lit</uri> </author> <title type='text'>She is so pretty!</title> <published>2008-05-08T18:39:02Z</published> </entry> Title as an indicator --------------------- <entry xmlns='http://www.w3.org/2005/Atom'> <author> <name>Juliet Capulet</name> <uri>xmpp:juliet@capulet.lit</uri> </author> <title type='text'>comment</title> <summary type='text'>She is so pretty!</summary> <published>2008-05-08T18:39:02Z</published> </entry> Category as an indicator ------------------------ <entry xmlns='http://www.w3.org/2005/Atom'> <author> <name>Juliet Capulet</name> <uri>xmpp:juliet@capulet.lit</uri> </author> <title type='text'>She is so pretty!</title> <category term='xmpp:comment'/> <published>2008-05-08T18:39:02Z</published> </entry> A dedicated extension --------------------- <feed xmlns="http://www.w3.org/2005/Atom" xmlns:reactions="http://xmpp.org/2024/reactions"> For comments:  <entry xmlns='http://www.w3.org/2005/Atom'> <author> <name>Juliet Capulet</name> <uri>xmpp:juliet@capulet.lit</uri> </author> <title type='text'>She is so pretty!</title> <reactions:reaction type="💡️"/> <reactions:reaction type="👍️"/> <published>2008-05-08T18:39:02Z</published> </entry> For posts:  <reactions:reaction type="✒️" count="10"/> <reactions:reaction type="💡️" count="2"/> <reactions:reaction type="👍️" count="5"/> Kind regards, Schimon [1]: https://git.xmpp-it.net/sch/Rivista [2]: https://xmpp.org/extensions/xep-0277.html#comment_add

1 week, 1 day

1
2
0 0

XEP-0077: In-Band Registration - Account creation via XMPP and HTTP

by Melvin Keskin

Hi, At the moment, it is not recommended to provide a web registration URL if the server supports account creation via IBR. I created https://github.com/xsf/xeps/pull/1299 to provide a web registration URL in addition to account creation via IBR. The client or user can decide which one to choose. Please let me know what you think about it. To the Council: 1. What exactly do you mean by *The language is weird*? 2. I tried to describe the use case. Could you please explain your doubts? 3. Why would such a change be problematic for a final XEP? 4. Where should I add that change instead? Thanks in advance :)

1 week, 3 days

3
2
0 0

UPDATED: XEP-0402 (PEP Native Bookmarks)

by Daniel Gultsch

Version 1.2.0 of XEP-0402 (PEP Native Bookmarks) has been released. Abstract: This specification defines a syntax and storage profile for keeping a list of chatroom bookmarks on the server. Changelog: Encourage clients to immediately leave the room if they receive a bookmark notification with autojoin set to false (mye) URL: https://xmpp.org/extensions/xep-0402.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.

2 weeks

7
14
0 0

Bibliography and PubSub

by Schimon Jehudah

Greetings XSF! Thanks to Mr. Timothée Jaussoin (alias "edhelas") who is responsible for "XEP-0472: Pubsub Social Feed" I am interested and investigate about developing and utilizing XMPP PubSub. I am working on a couple of XMPP chat bots to which I will integrate support for PubSub. * Slixfeed (integrated) Slixfeed is a news bot of which PubSub support is almost done. It will use of affiliation='publisher' as defined in XEP-0060 to post news items to PubSub nodes https://git.xmpp-it.net/sch/Slixfeed * BukuBot (not yet integrated) BukuBot is a new chat bot which I contemplate on adding PubSub support in order to make link directories sharable, yet I do not think it would be wise to utilize node `urn:xmpp:links:0` for this purpose. Because of this, I would like to discuss of a new XEP which probably would be similar to XEP-0277 and XEP-0472, yet it would be specifically aimed at bibliography management. Such XEP would be utilized to share Book and Scholar citations, URLs (Gemini, Gopher, HTTP, XMPP), and other type of references over XMPP PubSub. I would be thankful for you to help and share your thoughts on this matter. Kind regards, Schimon

2 weeks, 3 days

3
12
0 0

XMPP Council Agenda 2024-08-27

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, August 27 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-0045 (Multi-User Chat) * UPDATED: XEP-0388 (Extensible SASL Profile) * Proposed XMPP Extension: OAuth Client Login (https://xmpp.org/extensions/inbox/xep-oauth-client-login.html) * Proposed XMPP Extension: Client Access Management (https://xmpp.org/extensions/inbox/xep-client-access-management.html) 4) Items for voting a) Proposed XMPP Extension: OAuth Client Login https://xmpp.org/extensions/inbox/xep-oauth-client-login.html b) Proposed XMPP Extension: Client Access Management https://xmpp.org/extensions/inbox/xep-client-access-management.html c) XEP-0045: Add explicit error definition when non-owners attempt to use owner-specific functionality https://github.com/xsf/xeps/pull/1370 5) Pending votes None See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

2 weeks, 3 days

1
0
0 0

XEP-0444: fallback mechanisms?

by Marcin Mielniczuk

Hi, I noticed that, in the current implementations of XEP-0444 are not really backwards-compatible. Non-compliant clients completely miss the emoji reactions and the users are completely unaware that the reaction has been sent. One idea would be to provide the following as a fallback: > Content of the original message 😀 in a similar way to how message replies are currently shown on non-compliant clients. Similarly, when an OMEMO-incompliant client receives an OMEMO- encrypted message, it still receives some placeholder message indicating that the message is OMEMO-encrypted but the client does not support it. Is there any reason why there is currently no fallback mechanism in XEP-0444? Regards, Marcin

2 weeks, 3 days

2
2
0 0

Proposed XMPP Extension: Jingle Audio/Video Conferences

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Jingle Audio/Video Conferences Abstract: This specification defines a way to hold multiparty conferences with an SFU via Jingle. URL: https://xmpp.org/extensions/inbox/av_conferences.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

2 weeks, 4 days

5
9
0 0

Proposed XMPP Extension: Client Access Management

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Client Access Management Abstract: This specification details how an XMPP account owner can view and control which applications and services have access to their account. URL: https://xmpp.org/extensions/inbox/xep-client-access- management.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

3 weeks

1
0
0 0

Proposed XMPP Extension: OAuth Client Login

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: OAuth Client Login Abstract: This specification details how a third-party can be securely granted access to an XMPP account without exposing the account credentials, using OAuth. URL: https://xmpp.org/extensions/inbox/xep-oauth-client-login.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

3 weeks

1
0
0 0

2024

2023

Standards ----- 2024 ----- September 2024 August 2024 July 2024 June 2024 May 2024 April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023

Standards