[jdev] The future of Jabber/XMPP?
dave at cridland.net
Fri Aug 27 10:21:34 CDT 2010
On Fri Aug 27 13:18:15 2010, Evgeniy Khramtsov wrote:
> 27.08.2010 21:02, Dave Cridland wrote:
>> On Fri Aug 27 11:23:09 2010, Evgeniy Khramtsov wrote:
>>> If you have caps and valid disco#info then there will not be such
>>> problem. So it works in practice.
>> You're misunderstanding me.
>> If a client sends an explicit subscription to a node on a pubsub
>> service held on a foreign domain whose jid happens to be a bare
>> jid, then notifications will be filtered by the client's local
>> server, effectively breaking the subscription.
> Indeed, and I still don't understand what you are talking about.
Okay, bear with me, and I'll try to explain.
The automatic subscription on a PEP service is the only one that
should be filtered.
"A PEP service MUST support the "filtered-notifications" feature
defined in Section 9.2 of XEP-0060. This implies that when an
automatic subscriber can specify which event payloads it wants to
receive by including appropriate feature bundles in the XEP-0115
information it broadcasts."
I'd note that this does not mention any distinction between local and
Nothing prevents a more complex client and PEP service using
*explicit* subscriptions, which would not be filtered - basically a
PubSub service which is not only the PEP subset will be severely
broken by your protocol.
In your implementation, because you filter on delivery at the
receiver, you cannot make this distinction, because you lack the
knowledge of the source.
Which means not only is ejabberd's PEP implementation broken WRT
anyone else's, it is *also* self-restricting, such there's no path
forwards to anything more than the PEP subset.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the JDev