Project

General

Profile

Different types of buddy subscriptions

Justin Posey
Added about 5 years ago

I'm looking into having different types of optional buddy subscriptions. The normal buddy subscription would allow for chatting, and additional optional subscription types beyond being just a buddy would allow for extended capabilities between buddies. The optional subscription types would need to go through the same approval process as would a normal buddy subscription.

At first I thought that the "group" child element of the roster may be a good fit to indicate all the different confirmed subscription types. The server could add an additional "group" element for each confirmed subscription type. However, after reading the relevant RFC (http://tools.ietf.org/html/rfc6121#section-2.1.2.6), I think this would actually be a spec violation because it wouldn't be opaque to the server. This also doesn't solve the problem of clients approving and managing different types of subscriptions.

Is this something that XMPP and Tigase can support? Thank you in advance for your input.


Replies (2)

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam about 5 years ago

As far as I know there is no spec or extension for something like this. So whatever approach you chose you end up doing some custom stuff. The best approach really depends on the requirements and functions you need for this feature.

Do you want it to be something like circles in Google+ or different groups in FB? Could you provide some more details on this?

XMPP groups could be a solution in some cases. Why do you need to be opaque to the server? Do you want the server to control state transition and force it to be correct? If, then indeed, you need something different from groups.

I would suggest not to mess with current presence subscription system because it is already very complex and states transition are difficult to maintain.

You probably need a custom protocol with custom plugins to maintain your custom subscriptions. It would be the best way from the design, development and maintenance point of view.

Added by Justin Posey about 5 years ago

Thanks, Artur. I ended up going with a custom implementation, based on your feedback. Works great!

    (1-2/2)