XMPP PubSub Workbench

XMPP PubSub Workbench

Step through XEP-0060 nodes, subscriptions, item publishing, access models, persistence, and notification fan-out

Learner-ready XMPP PubSub animation with scenario controls, step/play interaction, node access diagnosis, subscriber fan-out, XML stanza inspector, and mobile-ready reference support.

Animation XMPP XEP-0060 PubSub

XMPP PubSub Workbench

Follow one published item as an XMPP PubSub service checks the node, applies its access model, optionally stores the item, and sends event notifications only to matching subscribers.

Selected node /building/1/temperature

Access model open

Subscribers reached 3 of 5

Item storage persistent

TryLoad Persistent replay, select /building/1/temperature, keep Persist latest item enabled, and publish item 42.

ObserveLive subscribers receive the event; a later subscriber gets stored data only when persistence and access policy allow. Step confirms this readout.

ExplainA PubSub service validates node access, stores configured items, and fans notifications to eligible subscriptions rather than every JID. Step exposes this mechanism.

Technical boundariesThe model omits full XEP-0060 configuration, affiliations, item expiry, federation errors, ordering, storage quotas, and transport security.

Colour keyapp protocols identitycurrent / primaryreference / datasuccesscautionerror / failure

Core object

The node is the server-managed channel. It is more than a topic string because it can have access control, affiliations, and storage policy.

Watch first

The item starts at a publisher, reaches the pubsub service by IQ stanza, and fans out as message event notifications.

Common mistake

XMPP PubSub is not MQTT transport. It is an XMPP extension that uses XML stanzas and XMPP identity, routing, and policy.

1. Select nodeService locates the target PubSub node.

2. Check accessSubscription and publish policy are evaluated.

3. Publish itemPublisher sends an IQ set with a node item.

4. Store if enabledPersistent nodes retain the latest item.

5. Notify subscribersOnly eligible subscribers receive events.

Scenario Lab

Change the node policy and watch the same published item take a different path through the service.

Scenario

Playback

Node policy

Node /building/1/temperature /building/1/door /building/1/energy /site/alerts/alarm

Access model open authorize whitelist roster presence

Persist latest itemWhen enabled, the service can return the last stored item to a later subscriber if its implementation and node configuration allow it.

Selected subscriber dashboard@ops.iot hvac-controller@building.iot security-console@building.iot analytics@cloud.example guest-panel@visitor.iot

Node inventory

Temperature fan-out

A room sensor publishes one reading to the temperature node. The pubsub service notifies dashboard, HVAC, and analytics subscribers.

Stage 1 of 5: select node

Delivery diagnosis

The node is open and persistent. Dashboard, HVAC, and Analytics are subscribed, so each receives an event message for the new temperature item.

Concept in focus

Publishers do not send directly to every consumer. The PubSub service owns node policy and notification fan-out.

Stanza Inspector

Read the XML associated with the current stage and scenario. The examples are shortened for learning, but keep the important XEP-0060 structure.

Publish IQ

A publisher sends an IQ set to the pubsub service. The publish element names the target node and wraps the item payload.

Technical Quick Reference

PubSub service

An XMPP entity such as pubsub.example.org that manages nodes, validates requests, stores items when configured, and sends notifications.

Node

A named collection point for items. It can have configuration such as access model, notification behavior, max items, and persistence.

Item

The published payload, usually wrapped in <item id="...">. Notifications deliver the item to subscribers as an event message.

Subscription

The relationship saying a JID wants notifications from a node. Subscriptions answer "who receives events?"

Affiliation

The longer-lived permission role on a node, such as owner, publisher, member, or outcast. Affiliations answer "who may manage or publish?"

Access model

Common models include open, authorize, whitelist, roster, and presence. Exact support and defaults depend on the XMPP server.

Use The Workbench To Check Understanding

Who receives the event?

Change the selected node and subscriber. If a JID is not subscribed or is blocked by policy, the publish still reaches the service but no event is delivered to that JID.

What changes with persistence?

Turn persistence off and replay a stored item. Without storage, late subscribers cannot learn the last value from the PubSub node itself.

What is not MQTT?

MQTT brokers route PUBLISH packets by topic filters. XMPP PubSub routes XML stanzas by service, node, JID, subscription, and server policy.

Model Boundaries And Sources

Simplified here

• TLS, SASL, stream negotiation, service discovery, and error codes are not animated.
• Only one publisher item is shown at a time.
• Server-specific policy and persistence details are summarized.

Technical basis

• XEP-0060 defines the XMPP publish-subscribe extension.
• RFC 6120 defines XMPP core streams, stanzas, and routing foundations.
• RFC 6121 defines instant messaging and presence behavior around rosters and presence.

Accuracy notes

Event notifications are shown as <message type="headline"> examples. Real deployments may use different message types, payload namespaces, node options, and authorization workflows.

XEP-0060 Publish-Subscribe extension specification. RFC 6120 XMPP core protocol foundation. IoTClass XMPP chapter Local chapter context for XMPP in IoT systems.