The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Pubsub Stories
Abstract:
This specification defines a way of publishing Stories over XMPP.
URL: https://xmpp.org/extensions/inbox/stories.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Good Morning Council Members,
the next XMPP Council Meeting will take place on, Tuesday, December 17
2024 at 16:30 UTC in xmpp:council@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
* Proposed XMPP Extension: Pubsub Stories
* UPDATED: XEP-0500 (MUC Slow Mode)
* LAST CALL: XEP-0421 (Anonymous unique occupant identifiers for MUCs)
4) Items for voting
a) Proposed XMPP Extension: Pubsub Stories
https://xmpp.org/extensions/inbox/stories.html
b) Issue Last Call on 'XEP-0424: Message Retraction'
https://xmpp.org/extensions/xep-0424.html
c) Issue Last Call on 'XEP-0425: Moderated Message Retraction'
https://xmpp.org/extensions/xep-0425.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
Version 0.1.1 of XEP-0500 (MUC Slow Mode) has been released.
Abstract:
This specification describes a way to rate limit messages a single
user can send to a MUC room. It includes room configuration option,
and how servers and clients can handle such a feature.
Changelog:
Include first feedbacks (jl)
URL: https://xmpp.org/extensions/xep-0500.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.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: MUC Slow Mode
Abstract:
This specification describes a way to rate limit messages a single
user can send to a MUC room. It includes room configuration option,
and how servers and clients can handle such a feature.
URL: https://xmpp.org/extensions/inbox/xep-slow-mode.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
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
Good Morning Council Members,
the next XMPP Council Meeting will take place on, Tuesday, December 3
2024 at 16:30 UTC in xmpp:council@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
* Proposed XMPP Extension: MUC Activity Indicator
* UPDATED: XEP-0480 (SASL Upgrade Tasks)
* NEW: XEP-0500 (MUC Slow Mode)
* UPDATED: XEP-0490 (Message Displayed Synchronization)
4) Items for voting
a) Proposed XMPP Extension: MUC Activity Indicator
https://xmpp.org/extensions/inbox/muc-activity.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
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: MUC Activity Indicator
Abstract:
This specification provides querying entities an approximate
indication of the level of activity in a given XEP-0045 Multi-User
Chat room.
URL: https://xmpp.org/extensions/inbox/muc-activity.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Version 0.2.0 of XEP-0480 (SASL Upgrade Tasks) has been released.
Abstract:
This specification provides a way to upgrade to newer SASL mechanisms
using SASL2 tasks.
Changelog:
Fix SCRAM upgrade description and XML schema. (tm)
URL: https://xmpp.org/extensions/xep-0480.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.