Difference between Pubsub and PEP

I’ve had lots of opportunity over the past few weeks to work with both PEP and Pubsub. While both delivers data/item/payload, the way the 2 services are structured are quite different. The following table list their respective differences

Pubsub PEP
Service discovery
  • Typically discovered by sending a disco#item to the server
  • Discovered via entity caps in the presence
  • Can create/delete multiple nodes if authorized.
  • Node can be configured during creating
  • Only one node, your JID; and cannot be deleted.
  • Not configurable
  • Depending on configuration, anyone can publish/subscribe to nodes (list-single_access-model, list-single_publish_model)
  • Declare in your disco#info your intention to publish certain type of info or receive certain type of info
  • Only those in your roster and have declared their intention to receive the type of info will receive it
  • Configurable number of items that you can persist in the node (persist_items, max_items)
  • Can either deliver a notification of the payload or the payload itself (deliver_payloads)
  • Payload may be marked delayed and timestamped if they are delivered after the fact
  • Persist only the last payload published
  • No timestamped/delay delivery

Hopefully this will help you decide which model is suitable for your need. Let me know if you spot any mistakes or give me feedback.

5 Responses to Difference between Pubsub and PEP

  1. Stan says:

    Thank you so very much for this set of tutorials. As you stated in the first blog of the series, this information is not collected anywhere else, and I want to thank you. I have been ‘playing around’ with Smack for a month or so, and have been able to cobble together the basic chat functionality, but pubsub was the jewel I was intent on taking advantage of. The provider/extension/packet/payload/item morass just had me chasing my tail around and around. Though my interest is in pubsub rather than PEP, you have untangled the design template for Smack, which (I hope) has given me the direction to implement the function.

    I particularly appreciate your explanations in a context that includes both the creation and the reception of the message – similar but certainly different. Now I have hope again!!

    I look forward to continuing to read your blog. Thanks again.


  2. Jaya Krishna says:


    I am wondering about the way to send a caps presence using the Smack client implementaiton.

    As per the PEP support, we must send the presence stanza as below:


    To my understanding, this caps presence stanza will depict the list of features supported by alice (in this example).

    But, I am wondering about the programmatic way of encoding/hashing the list of features and retrieving them when another queries alice with the hash code.

    Is there any support for such implementation in SMACK API?

    Any help in this regard would be of great help.


    Jaya Krishna

  3. Jaya Krishna says:

    sorry to send multiple comments,

    I was unable to post a xmpp stanza, hence tried several times..

    stanza looks like below: (syntax is changed to be made displayed on page)

    <presence from=”alice@wonderland.lit/rabbithole”>

    <c xmlns=”http://jabber.org/protocol/caps”





Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: