Hi all,
I'm currently implementing SASL2 (et al) into Openfire, which is amusing
since I had the first implementation there years ago.
In doing so, I've a few comments, most of which are directed at past-me of
course. Past-me is an idiot, and I have ample evidence of this.
1) One of the changes from the original SASL profile is that there's no
need for (and mention of) the "equals hack" to indicate no data. Should
this be explicitly called out?
2) The user-agent - this is a SHOULD (well, RECOMMENDED, which means the
same thing). The consequences of not including it are that other
specifications might rely on it - the same as the id, which is also SHOULD.
I dislike the amount of SHOULD here, it feels like the "outer" SHOULD is
sufficient, and a user-agent with no id attribute is a bit useless.
3) The id string given MUST be a UUIDv4. What should the server do if it
receives a non-UUID, or a UUID of a different type to v4? A purist might
reject it, but this seems wrong - what guidance can we put here? If we
accept any old string, and it's not a UUIDv4, what happens?
4) Second para of Initiation talks about an authorization string, but
there's no such string defined. Was this intended to mean the requested
authorization identity in the SASL mechanism? That's an interesting
challenge, especially from just the initial-response which might not be
present. I think I follow the intent here, but the detail seems off.
Dave.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Data Forms File Input Element
Abstract:
This specification defines an element which can be used with data
forms to let users upload one or more files.
URL: https://xmpp.org/extensions/inbox/data-form-file-element.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
A few weeks ago I made an important pull request to complete, fix and
update the XEP-0317: Hats.
https://github.com/xsf/xeps/pull/1437
This PR included the following changes:
* Specify a urn:xmpp:hats:commands:dcreate command to add a hat to the
available list
* Specify a urn:xmpp:hats:commands:ddestroy command to destroy a hat
from the list
* Clarify how the service should broadcast the hat changes when it is
edited, assigned, removed or destroyed
* Specify a way for an entity to get the complete list of hats using a
hash in disco#info
* Add a hue optional parameter allowing entities to assign a color to
the hat that can be displayed properly in any conditions on the
client (as explained in XEP-0392: Consistent Color Generation)
* Standardize all the form fields using XEP-0068
* Fix some typos
I tried to reach the authors without success so I'm trying again using
the mailing list.
I'd really like to move it forward then we can start implementing them
in our clients and servers.
Regards,
edhelas
I've seen some IM platforms (namely Revolt and Guilded) have the ability to let the user reference multiple messages in a single reply, which might be a useful feature. I think with the XEP as it currently is, it could be fairly simple to add support for this feature.
I think an addition like this would be good.
"""
Section 3.2 - Multi-Message Replies
A user may want to reply to multiple messages with a single message. This can be done by including many reply elements. Ordering is important, so the reply element MUST include an "arrangement" attribute that counts up from 0, with 0 being displayed at the top in the client UI.
EXAMPLE 5. Yuri replies to both Max's and Anna's messages in a MUC.
```
<message to='knightsguild(a)muc.example.org' from='knightsguild(a)muc.example.org/anna' id='groupchat-id1' type='groupchat'>
<stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id1' />
<body>A fort will keep us safe!</body>
</message>
<message to='knightsguild(a)muc.example.org' from='knightsguild(a)muc.example.org/max' id='groupchat-id2' type='groupchat'>
<stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id2' />
<body>Adoring blue flags for style!</body>
</message>
<message to='knightsguild(a)muc.example.org' from='knightsguild(a)muc.example.org/yuri' id='groupchat-id3' type='groupchat'>
<stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id3' />
<body>Excellent ideas! Let's get right to it!</body>
<reply to='knightsguild(a)muc.example.org/anna' id='groupchat-id1' arrangement='0' xmlns='urn:xmpp:reply:0' /><reply to='knightsguild(a)muc.example.org/max' id='groupchat-id2' arrangement='1' xmlns='urn:xmpp:reply:0' />
</message>
```
A fallback for this would work in the same way as the previous section, the main difference is that the fallback would include all referenced messages.
"""
I think it also might be worth considering having some kind of limiter in how many messages can be referenced by one reply - perhaps MUCs that advertise support for replies could indicate in a data form how many references may be one message, and if clients don't self-enforce this, then the MUC could throw a policy violation error and drop the message.
Good day.
I would want to discuss the possibility and best practice of creating
server-side modules that would copy BoB data (XEP-0231: Bits of Binary)
to own server in order to avoid exposure of IP address of the receiver.
Kind regards,
Schimon
Good Morning Council Members,
the next XMPP Council Meeting will take place on, Tuesday, June 24
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-0284 (Shared XML Editing)
https://xmpp.org/extensions/xep-0284.html
4) Items for voting
a) XEP-0363: specify purpose/buckets when requesting slots
https://github.com/xsf/xeps/pull/1445
5) Pending votes
- Dan on everything from last week
- Daniel on 'Proposed XMPP Extension: Data Forms File Input Element'
- Goffi, technically on 'XEP-0388: Fix failure example sequence' but
has been vetoed already in favor of "Should Daniel just fix the
schema"
See the spreadsheet of doom:
https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEU…
6) Date of Next
7) AOB
8) Close
Version 0.1.4 of XEP-0284 (Shared XML Editing) has been released.
Abstract:
This specification defines a protocol that enables two or more
endpoints to collaboratively edit an XML object. The protocol is
intended for use mainly over the Extensible Messaging and Presence
Protocol (XMPP), either by existing instant messaging clients or by
specialized editing clients. However, the protocol could also be used
over a direct TCP connection rather than over XMPP.
Changelog:
* Fix the registrar section.
* Format the glossary better.
* Add missing <state/> wrappers in examples.
* Write an XML Schema. (egp)
URL: https://xmpp.org/extensions/xep-0284.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.
Preface
-------
I would want to advise to extend XEP-0107 (User Mood) and XEP-0108
(User Activity), so that it would be possible to selectively advertize
of activities and moods.
This is beneficial for both humans and machines.
Because the examples for humans may be vague, I will write an obvious
case for machines.
Service
-------
KaikOut is a moderation service (i.e. "bot", so called) for group chats.
As with traffic signs, and unlike status messages, activity and mood
are fixated, even though both have an option for custom text, and
because of it, they can be used as constant and accurate indicators for
activity and state of machines.
That is, activities and moods can be used as signs, and also to signal
of events. See further examples.
Additionally, status messages, activities and moods serve different
purposes, which is another reason to have an option of selective
advertizing for activity and mood.
Example
-------
This is a realization of using activities and moods in a selective
fashion over different group chats simultaneously.
Ideas with XEP-0107: User Mood
------------------------------
amorous:
When KaikOut writes good scores.
annoyed:
When KaikOut writes bad scores.
ashamed:
When KaikOut demotes a moderator.
calm or bored:
When group activity is under a certain level.
happy or relaxed:
When moderation activity is under a certain level.
restless:
When moderation activity is above a certain level.
cautious or serious:
Routine mood.
remorseful or frustrated or sleepy:
When KaikOut is disabled.
proud:
When KaikOut bans or kicks an occupant.
ashamed or shocked:
When a group chat owner pormotes a moderator which was demoted by
KaikOut.
surprised:
When KaikOut is demoted.
thankful:
When KaikOut is set to be a moderator.
Ideas with XEP-0108: User Activity
----------------------------------
working:
When KaikOut writes scores.
sleeping:
When KaikOut is inactive.
Reference:
https://git.xmpp-it.net/sch/KaikOut/issues/36
Kind regards,
Schimon
I have setup the membership application Wiki page for the application
period Q3 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_Q3_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
