Remko, > subscriptions dialog). The same goes for MUCs and bookmarks, which > some clients decide to put in the roster, and others think this > belongs in a separate dialog to avoid confusion.
That's a great point, I didn't think of the MUC analogy, nor did I even know about bookmarks. You learn something new every day. As far as I understand though, if you treat it just as a UI issue, you only get a local solution. What I mean by this is (stretching the previous example): If I have a local RSS-XMPP client via Pubsub, and a web RSS-XMPP client via Pubsub, I want them both to have the same Pubsub list, such that I can have my feed list wherever I am. If I just decide locally whether to put it in the UI or not, they won't be transferred with the rest of my roster. One solution perhaps would be to add a new type to bookmarks, ones which are better suited for pubsub nodes. This way, every client could poll for its pubsub subscription bookmarks, and then decide what to do with them on the contact list. That seems reasonable to me. Another option with this solution would be to define a way for bookmarks to live in the roster as "pseudo-contacts", which would require a modification to how rosters are defined, though I like this idea too. Note that these solutions solve the problem of finding out which nodes a JID is subscribed to, as otherwise there is no way to find out unless you get a message from some node (I think). Does this make sense? Itay
