[standards-jig] Discussion on JEP-0016: Server-Based Privacy Rules
mass at akuma.org
Sat Jan 19 05:46:04 UTC 2002
From: mlin at mlin.net
To: standards-jig at jabber.org
Sent: Friday, January 18, 2002 9:20 PM
Subject: Re: [standards-jig] Discussion on JEP-0016: Server-Based Privacy Rules
So the real question I have is that if, as you say, we accept that the blocking mechanism is just a virtualization that is trivial to circumvent, is it necessary to have a transport-layer facility for it? What real advantage, weighed against the additional computational cost to the server, does doing this on the server side provide vs. simply ignoring the packets in the UI and denying presence subscription? I guess you can make bandwidth and thin client arguments...but these are always weak arguments IMHO.
The primary argument for this is to reduce bandwidth. Without this, you would need to fetch and synchronize the block list, then ignore messages from a particular person which will still come right down the line. This enables the client to just implement the UI for the list, and only grab it when updating the list.
As far as server load - the blocklist lookup can be done with either a set or a hashtable. This would seem to make it more memory-intensive than CPU-intensive.
But for random comments.... :-)
Doing a 'whitelist' would seem just as efficient as doing a blacklist. However, the most common whitelist would be 'block messages for all people not in my roster'. Blocking presence for people not in the roster also means that they cannot do subscription requests.
Should messages of type='error' packets be absorbed by the server if they come from a blocked host, or should they be delivered? You do not want to bounce these, as it could become a endless loop. By absorbing the messages, you would lose the ability to know if a blocked person received your message; however, you would not have to deal with the blocked person sending messages of type error to you manually.
Can you block just user at host JIDs, or can you block a host completely?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards