Version 0.1.0 of XEP-0494 (Client Access Management) has been
released.
Abstract:
This specification details how an XMPP account owner can view and
control which applications and services have access to their account.
Changelog:
* Promoted to Experimental (XEP Editor: dg)
URL: https://xmpp.org/extensions/xep-0494.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.1.0 of XEP-0493 (OAuth Client Login) has been released.
Abstract:
This specification details how a third-party can be securely granted
access to an XMPP account without exposing the account credentials,
using OAuth.
Changelog:
* Promoted to Experimental (XEP Editor: dg)
URL: https://xmpp.org/extensions/xep-0493.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.3.1 of XEP-0474 (SASL SCRAM Downgrade Protection) has been
released.
Abstract:
This specification provides a way to secure the SASL and SASL2
handshakes against method and channel-binding downgrades.
Changelog:
* Fix typos
* Adapt attack-model section to new simplified protocol (tm)
URL: https://xmpp.org/extensions/xep-0474.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 1.3.1 of XEP-0133 (Service Administration) has been released.
Abstract:
This document defines recommended best practices for service-level
administration of servers and components using Ad-Hoc Commands.
Changelog:
Fixed typo in example for Get User Last Login Time (dc)
URL: https://xmpp.org/extensions/xep-0133.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 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
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:
<!-- Custom Reactions Extension -->
<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:
<!-- Custom Reactions Extension -->
<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
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 :)
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.
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