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
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Happy Eyeballs
Abstract:
When a server's IPv4 path and protocol are working, but the server's
IPv6 path and protocol are not working, a dual-stack application that
initiates a connect experiences significant connection delay compared
to an IPv4-only application. This is undesirable because it causes the
dual-stack initiating entity to have a worse user experience. This XEP
defines how IETF's 'Happy Eyeballs' algorithm requirements that reduce
this user-visible delay are applied to XMPP.
URL: https://xmpp.org/extensions/inbox/xep-happy-eyeballs.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Hi,
"XEP-0484: Fast Authentication Streamlining Tokens" is written without any
considerations for multiple devices.
With stuff like that "*For every client using FAST, have two token slots -
'current' and 'new'." *in it.
I am kinda confused how the XEP could be considered in 2024. The moment we
have two devices for the same user, the devices would start conflicting
with each other, by revoking tokens of each other.
The XEP should use namespaces (or be resource aware) for it to properly
work.
--
Best regards,
Uvarov Michael
Good morning Council Members,
the next XMPP Council Meeting will take place on, Tuesday, September
24 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-0004 (Data Forms)
* UPDATED: XEP-0264 (Jingle Content Thumbnails)
* UPDATED: XEP-0313 (Message Archive Management)
* Proposed XMPP Extension: Happy Eyeballs
4) Items for voting
a) Proposed XMPP Extension: Happy Eyeballs
https://xmpp.org/extensions/inbox/xep-happy-eyeballs.html
b) XEP-0198: Clarify server enabling SM without requested resumption
https://github.com/xsf/xeps/pull/1376 (modified)
5) Pending votes
None
See the spreadsheet of Doom:
https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa…
6) Date of Next
7) AOB
8) Close
Version 1.1.2 of XEP-0313 (Message Archive Management) has been
released.
Abstract:
This document defines a protocol to query and control an archive of
messages stored on a server.
Changelog:
* Fix JID and affiliation of the first two witches in the MUC example.
* Fix duplicated 'id' in MUC example.
* Fix indentation in examples. (egp)
URL: https://xmpp.org/extensions/xep-0313.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.4.2 of XEP-0264 (Jingle Content Thumbnails) has been
released.
Abstract:
This specification defines a way for a client to supply a preview
image for Jingle content.
Changelog:
Restrict 'width' and 'height' to the 0..65535 range, instead of being
unbounded integers. This is in accordance to XEP-0084 and XEP-0221
for instance. (egp)
URL: https://xmpp.org/extensions/xep-0264.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 2.13.2 of XEP-0004 (Data Forms) has been released.
Abstract:
This specification defines an XMPP protocol extension for data forms
that can be used in workflows such as service configuration as well as
for application-specific data description and reporting. The protocol
includes lightweight semantics for forms processing (such as request,
response, submit, and cancel), defines several common field types
(boolean, list options with single or multiple choice, text with
single line or multiple lines, single or multiple JabberIDs, hidden
fields, etc.), provides extensibility for future data types, and can
be embedded in a wide range of applications. The protocol is not
intended to provide complete forms-processing functionality as is
provided in the W3C XForms technology, but instead provides a basic
subset of such functionality for use by XMPP entities.
Changelog:
Add section on empty and absent values. (gk)
URL: https://xmpp.org/extensions/xep-0004.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.
Good morning Council Members,
the next XMPP Council Meeting will take place on, Tuesday, September
17 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-0133 (Service Administration)
* UPDATED: XEP-0474 (SASL SCRAM Downgrade Protection)
* UPDATED: XEP-0045 (Multi-User Chat)
* UPDATED: XEP-0272 (Multiparty Jingle (Muji))
* NEW: XEP-0493 (OAuth Client Login)
* NEW: XEP-0494 (Client Access Management)
4) Items for voting
a) XEP-0004: Empty and absent values
https://github.com/xsf/xeps/pull/1387
b) XEP-0264: Restrict 'width' and 'height' to the 0..65535 range
https://github.com/xsf/xeps/pull/1366
c) XEP-0198: Clarify server enabling SM without requested resumption
https://github.com/xsf/xeps/pull/1376
d) XEP-0313: Fix MUC archive example
https://github.com/xsf/xeps/pull/1321
5) Pending votes
None
See the spreadsheet of Doom:
https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa…
6) Date of Next
7) AOB
8) Close
Version 0.2.0 of XEP-0272 (Multiparty Jingle (Muji)) has been
released.
Abstract:
This specification defines an XMPP protocol extension for initiating
and managing multiparty voice and video conferences within an XMPP MUC
Changelog:
* Send Jingle IQs to real JID
* Define how to use with XEP-0482
* Adjust namespace (lmw)
URL: https://xmpp.org/extensions/xep-0272.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.35.1 of XEP-0045 (Multi-User Chat) has been released.
Abstract:
This specification defines an XMPP protocol extension for multi-user
text chat, whereby multiple XMPP users can exchange messages in the
context of a room or channel, similar to Internet Relay Chat (IRC). In
addition to standard chatroom features such as room topics and
invitations, the protocol defines a strong room control model,
including the ability to kick and ban users, to name room moderators
and administrators, to require membership or passwords in order to
join the room, etc.
Changelog:
Add explicit error definition when non-owners attempt to use owner-
specific functionality. (gk)
URL: https://xmpp.org/extensions/xep-0045.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.