[jdev] The future of Jabber/XMPP?

[Dave Cridland]

On Fri Aug 27 10:00:07 2010, Evgeniy Khramtsov wrote:
> 27.08.2010 02:47, Dave Cridland wrote:
>> On Thu Aug 26 15:41:29 2010, Evgeniy Khramtsov wrote:
>>> Lots of bugs in PEP server implementations are because the XEP  
>>> itself
>>> is written poorly. It doesn't scale: the idea of keeping resources
>>> and features of every user from every server on the planet is
>>> completely insane. Don't be surprised if you see memory leaks -  
>>> they
>>> are by design :)
>> 
>> Well, I agree it's pretty easy to "leak" subscriptions (we[1] do,
>> sometimes, if we never see an unavailable from a resource). That's  
>> our
>> bug, and we'll be sorting that one out soon. Otherwise I don't  
>> think
>> there's anything that inherently has a leak associated with it -  
>> even
>> including the fact you gradually learn about every feature of every
>> client, it's simply not that big a deal.
> 
> There is also a possibility where a malicious user can generate  
> thousands of fake resources with different caps/features which you  
> should also track. A server should also have a protection against  
> this, especially if it is a small server.
> 
> 
There are always attacks like this. A malicious user can generate  
thousands of fake resources without PEP, and you still need to track  
them in order to do presence optimization.


>> Honestly, I don't find PEP too much of a pain - it does have a  
>> memory
>> cost, but it's really not astronomical, and the benefits are very  
>> nice
>> for clients and users.
> 
> We choosed another approach in ejabberd, where we don't store  
> anything except of caps_hash->features hash table. If you are  
> wondered:
> 
> 1) caps_hash->features table is only for *local* users. The  
> overhead is really small for obvious reason.
> 2) since we already store local user's presence in C2S state (this  
> is MUST in RFC), a server filters out *every* outgoing PEP message  
> (based on caps from user's presence and features from  
> caps_hash->features table) right before sending the message to the  
> local user. No memory, no cpu overhead here.

So you're snooping all messages even from remote sources to guess if  
they're PEP events intended to be filtered? How would you know? If I  
(or my client) explicitly subscribes to a particular node on  
PEP/PubSub-onna-jid service, you'd filter it out anyway.


> 3) for S2S users a server sends PEP message blindly to bare JID. In  
> fact this doesn't even violate the XEP :)

I'm struggling to understand how that does not violate the XEP?

auto-subscribe is defined as a depth=all items subscription to the  
root node from the bare_jid, and filtered-notifications then only  
sends the notifications to those full jids that have requested them.  
Both are required for PEP. I don't see how you can claim to be  
conformant to PEP without doing both.

So because you filter on the subscriber's end, you restrict  
PubSub-onna-jid to the PEP subset, and because you don't filter on  
the service end, you break even that if the subscriber isn't on  
ejabberd.

So you end up with a interop matrix like:

Subscriber ->
v Service		ejabberd	Standard
ejabberd		PEP		No
Standard		PEP		Full

I don't see why you think this is a good thing.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade