6 Oct
2025
6 Oct
'25
2:18 a.m.
Thanks! I have taken this feedback to propose changes to the XEP. I've
split them in two parts:
- https://github.com/xsf/xeps/pull/1467 - no longer define the 'subscribe'
and 'publish' features as REQUIRED in the Feature Summary
- https://github.com/xsf/xeps/pull/1468 - formally introduce the '
https://jabber.org/protocol/pubsub' feature, and provide guidelines for
maximum compatibility
Kind regards,
Guus
On Sun, Oct 5, 2025 at 7:34 PM Ralph Meijer <ralphm(a)ik.nu> wrote:
On 5 October 2025 14:43:01 CEST, Guus der Kinderen <
guus.der.kinderen(a)gmail.com> wrote:
(Having a
XEP that is titled "publish-subscribe" for which both the "publish"as
well
as the "subscribe" part are optional seems... weird to me)
The idea behind it is that different types of services may only implement
one of these:
- A service that exposes its nodes as node-as-code won't use any of the
node management and publishing protocol. Nodes just magically exist, users
can subscribe to them, and notifications are sent out to subscribers.
- A service that (only) supports PEP will not use explicit subscription
protocols, and may use explicit publish actions.
- One could even have a service that doesn't use either. E.g. a news
ticker as part of a MIX service (I worked on this), where the node just
exists as part of a room, items magically exist through some out-of-band
integration, and occupants are subscribed implicitly using a PEP-like
auto-subscription mechanism. This would just send out notifications.
Another (early) example was the XMPP support in Twitter, a few moons ago.
--
ralphm
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org