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 <[email protected]> wrote: > > > On 5 October 2025 14:43:01 CEST, Guus der Kinderen < > [email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
