XMPP: adding bidirectionality to pubsub?

Question

I am not sure if pubsub or multiuserchat is the way to go?

What I think I need is pubsub, but with the added ability for subscribers to broadcast messages to the feed as well. Bidirectional information flow, if you will.

The use case is such that subscribers will be subscribed to on average 1000 different feeds, but each individual feed only broadcasts information on average once per week. So, lots of feeds, but low activity in each one. However, b/c there are 1000 different active subscriptions, a subscriber might still be notified of 100 messages per day, and they should be able to "reply" aka post content to any one of those feeds.

It seems like what I need is a pubsub/multiuserchat hybrid. But that doesn't exist, or does it? Any ideas or pointers?

Thanks a bunch!

Answer 1

If a subscriber is publishing data then they are not just a subscriber, they are a publisher. And there is no reason the same entity can't be a publisher and a subscriber at the same time.

As for your more general question about pubsub vs. MUC, that's a question that I find comes up a lot nowadays.

Obviously at first glance MUC and pubsub are very similar, they are both about broadcasting to a group. Many applications could easily use one or the other with no trouble.

To help decide which fits best with your applications, let's go through some of the differences between the two protocols.

MUC:

1. Is absolutely good for standard chatrooms of online users communicating with each other. If this is what you're doing, use it.
2. Includes presence, i.e. notifying other occupants about joining, leaving and changing status.
3. Allows for anonymous private communication between occupants.
4. Works out of the box with practically any standard XMPP client (for standard chat messages).
5. Automatic leaving of the room when the user goes offline or disconnects.
6. Messages with custom payloads are supported, meaning you are limited to routing standard chat messages.

Pubsub:

1. One or a few publishers transmitting to many read-only subscribers is core pubsub territory. In contrast to MUC the subscribers are not publishing, and are not receiving information about other subscribers.
2. Server implementations tend to have much more flexible access control for pubsub.
3. Custom payloads only, no standard chat messages.
4. Optionally has full item persistence.
5. A node can be managed as a list of items (ie. add/remove with notification) rather than just simple broadcast.
6. Subscriptions can persist through being offline.

The points above are just a guide. A lot can typically be achieved through server configuration. As an example, the MUC specification allows for rooms withholding presence broadcasts for certain classes of occupants based on configuration. The catch here is in the implementations... since this is an uncommon usage of MUC, you will find it may not be supported in many MUC implementations. The point being that as MUC was designed for chatting and not generic pubsub, you will largely find all the implementations and tooling around MUC to focus on that kind usage.

Answer 2

Not sure what the problem is. The subscriber simply needs to be a publisher as well. There is nothing stopping them from publishing as well as subscribing (unless the nodes are configured to disallow it).

This appears to be a very typical pubsub case.