XMPP Presence and Subscription Workbench

Step through XMPP presence stanzas, roster subscription states, and server fan-out decisions

animation
xmpp
protocols
presence
application-protocols
Learner-ready XMPP presence animation with scenario controls, step/play interaction, roster-state diagnosis, XML stanza inspector, subscription-request flow, and mobile-ready learning support.
XMPP Presence Roster Subscriptions

Watch XMPP route device status.

XMPP presence is not just "online" text. A device sends XML presence stanzas to its server, and the server fans them out only to contacts with the right roster subscription relationship. Step through the route, inspect the stanza, then change the status or subscription scenario.

Active stanza Available presence
Roster gate from / both allowed
Receivers 2 authorized
Current point Compose stanza

Mutual roster: room controller online

A device advertises its status. The server checks the roster before notifying contacts.

available
XMPP presence routing animation A device sends a presence stanza to an XMPP server. The server routes it to authorized roster contacts and blocks unauthorized contacts. Thermostat thermostat@home.iot /hallway XMPP server home.iot Remote server cloud.iot Facilities app subscription both operator@cloud.iot Wall panel subscription from panel@home.iot Guest viewer subscription none guest@partner.iot Availability presence is being composed presence
Publishing JID thermostat@home.iot/hallway
Presence detail available with status text
Delivery rule subscription from or both receives this sender's presence

Server fan-out is gated by the roster

The server does not broadcast this device's status to everybody. It sends presence only to contacts that have an approved subscription to the sender's presence.

XML stanza inspector

A plain available presence stanza has no <show>available</show>; availability is the default when no unavailable type is present.


      

    

  


  

    

      How to read this workbench
      

        

          

            Follow the token
            
The moving token is one presence stanza. It starts at the device, reaches the local server, then is delivered or blocked.

          

          

            Read the roster cards
            
Cards marked from or both can receive the sender's presence. to means the sender sees them, not the other way around.

          

          

            Use Step slowly
            
Step pauses the flow at compose, send, roster check, fan-out, and result so the routing decision is visible.

          

          

            Inspect the XML
            
Change the presence state and watch how show, status, priority, and type fields change.

          

        

      

    


    

      Technical quick reference
      

        

          

            JID
            
localpart@domain/resource. The domain routes to an XMPP server; the resource identifies a specific client session or device instance.

          

          

            Presence type
            
No type means available presence. type="unavailable" means the entity or resource is offline.

          

          

            Show values
            
chat, away, dnd, and xa are refinements of available presence. Plain available has no show value.

          

          

            Subscription stanzas
            
subscribe asks for visibility. subscribed grants it. These are control stanzas, not normal online status updates.

          

        

      

    


    

      Try these checks
      

        
    
          
  1. Choose Device offline. Confirm the stanza changes to type="unavailable" and subscribers still receive the offline signal.
    2. 
          
  2. Choose New subscription, then click Approve request. Watch the new contact move from pending to an approved receiver.
    3. 
          
  3. Set the state to dnd. Confirm it stays available presence with a <show>dnd</show> child, not an unavailable stanza.
    4. 
          
  4. Compare Mutual roster and Federated domains. Federation changes the server path, not the roster permission rule.
    5. 
        

      

    


    

      Model boundaries and sources
      

        
This workbench focuses on presence routing after an XMPP session exists. It does not simulate TCP connection setup, TLS, SASL authentication, resource binding, stream management, privacy lists, blocking commands, MUC presence, or mobile push behavior. Real servers may add policy, privacy, and federation controls around the simplified rule shown here.

        

          
            RFC 6121
            Instant messaging and presence semantics, including roster and subscriptions.
          
          
            RFC 6120
            Core XML streams, stanza model, addressing, and session foundations.
          
          
            XMPP PubSub
            Next animation: XEP-0060 publish-subscribe nodes and item notifications.