The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Pubsub Extended Discovery
Abstract:
This specification extends the discovery requests used with the XMPP
PubSub protocol by introducing mechanisms to discover linked nodes,
descendants, or metadata.
URL: https://xmpp.org/extensions/inbox/pubsub-extended-discovery.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Pubsub File Sharing
Abstract:
This specification explains how to share files and optionally include
directory structures similar to filesystems over XMPP Pubsub. It
leverages XMPP Pubsub to enable notifications about file changes and
manage permissions, providing users with real-time updates and control
mechanisms. An optional mechanism is also specified for managing
uploaded files.
URL: https://xmpp.org/extensions/inbox/pubsub-file-sharing.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Pubsub Extended Subscriptions
Abstract:
This specification extends the XMPP PubSub protocol by introducing
mechanisms for users to subscribe to an entire node hierarchy or to
receive notifications on node metadata updates.
URL: https://xmpp.org/extensions/inbox/pubsub-extended-
subscription.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, October 29
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-0394 (Message Markup)
* UPDATED: XEP-0491 (WebXDC)
* Proposed XMPP Extension: Pubsub File Sharing
* Proposed XMPP Extension: Pubsub Extended Discovery
4) Items for voting
a) Proposed XMPP Extension: Pubsub File Sharing
https://xmpp.org/extensions/inbox/pubsub-file-sharing.html
b) Proposed XMPP Extension: Pubsub Extended Discovery
https://xmpp.org/extensions/inbox/pubsub-extended-discovery.html
5) Pending votes
* Dan and Daniel on 'Proposed XMPP Extension: Pubsub Node Relationships'
See the spreadsheet of Doom:
https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa…
6) Date of Next
7) AOB
8) Close
Good day, one and all!
I want to work on an XEP which would define "link collections", which I
think would also be useful for FASI (HTML invite page for XMPP), which
already indicates of articles, when articles are present (see attached
image).
See example profiles under "New Members" at https://libertylinks.io
Would Data Forms be the appropriate mean to achieve it?
Kind regards,
Schimon
Version 0.1.3 of XEP-0491 (WebXDC) has been released.
Abstract:
This document defines an XMPP protocol extension to communicate WebXDC
widgets and their state updates.
Changelog:
* Clarifications and wording
* Better references for WebXDC spec (spw)
URL: https://xmpp.org/extensions/xep-0491.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.0 of XEP-0394 (Message Markup) has been released.
Abstract:
This specification provides an alternative to XHTML-IM with rigid
separation of content and markup information, improving the resilience
against spoofing and injection attacks.
Changelog:
Add support for strong emphasis, declaring langauge on code blocks and
making lists ordered. (lmw)
URL: https://xmpp.org/extensions/xep-0394.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.
Hello XMPP aficionados!
For a client joining a MUC, XEP-0045 defines a very strict order of events
(section 7.1). Is it allowable that a server sends _more_ events (that are
not in the list specified in XEP-0045)?
I've observed that in the wild, at least one implementation sends a
presence stanza 'from the room itself' (with CAPS), preceding the events
defined in section 7.1.
There is an argument to be made that the XEP defines the order of the
events, but leaves room for there to be 'more' events. One could argue that
this is in line with the extensible nature of XMPP.
On the other hand, I think that it's fair to say that this is stretching
things to an extent where it is not unreasonable for implementations to not
account for this (thus introducing potential interop issues).
I would like for the XEP to be more explicit, and either explicitly allow
or disallow this behavior. I have not quite made my mind up which way I
lean, to be honest. I'm interested in learning about the views on this from
the community.
For context, this has been previously discussed in the XSF Discussion MUC.
This is a link to the public message archive of that discussion.
https://logs.xmpp.org/xsf/2024-09-07#2024-09-07-78b71f7983a88d14
Kind regards,
Guus
I'd like to propose that we close the Internet of Things Special
Interest Group, which as far as I can see has been inactive. This would
involve moving XEP-0381 to Deprecated or Obsolete (the interim step of
Deprecated in accordance with XEP-0001 seems unnecessary, but I'll leave
that to the Council should it decide to act on this proposal).
Peter
Hi all,
I was skimming XEP-0490, and the optimisation of injecting multiple
displayed elements into a message referencing different ids in different
namespaces made me spit my tea dramatically over my keyboard. Not really,
of course - tea is far too precious to waste on such things, but you get
the idea.
There's clearly no better alternative, because we have clients in the wild
which are quite painful about message ids, and will therefore break things
if we were to rely on their ids being unique.
This got me thinking: What could we do to - if not remove this wart
entirely, at least file it down so it was less of a nuisance. (I'm not sure
if warts do get filed down; I am not a doctor, do not try this at home)
In a perfect world, we might remove XEP-0359 entirely - not because it is,
in and of itself, a bad spec, but because it is essentially patching
problems elsewhere.
So, what can we do to ensure that some tuple of the stanza attributes
perhaps (from,id), or possibly (from,to,id), is unique "enough", and stable
"enough", for both receivers and senders to rely on without having to
inject multiple ids?
Is this worth doing - it feels like it would clean up a lot of other
constructs, but some cases (MAM, perhaps?) might always need to inject
other identifiers. If we were to rely on clients using unique identifers,
could this be subverted in some way beneficial to an attacker?
My gut feeling is that even if we find that we're stuck with XEP-0359 in
all the same cases, we might produce an interesting document about the
security implications of the id attribute of stanzas, which feels like a
gap worth filling.
What do you all think?
Dave.
