[JDEV] Promiscuous presence for user communities (with patch)

[Ben Schumacher]

I'm inlining responses to two separate emails... one from Ryan and one
from stpeter... enjoy.

Ryan Hart said:
> For example, please explain in more detail how the presence bcc markup
> could
> be used to solve this problem. I understand that I could create a
> component
> to receive these messages, and I have played around with this some. Sure,
> this component could capture all the presence information and save it in a
> database. But, then what? I already have an xdb component, I would really
> like to just return these connected users as part of the roster query
> response. But that doesn't work... sure they'll show up in the clients
> roster, but the presence will never be known because the server won't
> receive a matching 'from' roster subscription for these jids. I would like
> presence to be handled automatically by jabber as if there was a 2-way
> 'both' subscription between these users. I should also mention that
> presence
> alone is not sufficient for our client. Our jids use numeric user_id
> values
> from our database to be unique... we always display the roster "name"
> attribute which is not part of the presence message.

The way to do this is fairly simple... when I use presence bcc, all
presence packets are sent to my component, so I can create a table (in
memory, or in a database -- doesn't matter) that has Jids and their
current presence. Assume here's what we got:

1) Users 1 at mydomain.com/blah and 2 at mydomain.com/blah are online, and
available.
2) User 3 at mydomain.com was online, but has since got "unavailable" -- no
reason to clog up my memory with an entry for him.
3) User 4 at mydomain.com/blah has just come online, and I've received
presence in my component.

So... my component just received a presence packet that looks like
<presence from="4 at mydomain.com/blah" to="bcc.mydomain.com" />. First
things first, I add an entry for 4 at mydomain.com/blah to my table. Next up,
I send out presence packets to the other users online... so my component
sends:

  <presence from="4 at mydomain.com/blah" to="1 at mydomain.com/blah" />
  <presence from="4 at mydomain.com/blah" to="2 at mydomain.com/blah" />
  <presence from="4 at mydoamin.com/blah" to="4 at mydomain.com/blah" />

The last one's probably not necessary, and I could have written my
component to not send it -- but it really doesn't have any negative
effects. Why this works...? In the open source jabberd (and in the
commercial implementation by Jabber, Inc.) external components are
"trusted" -- which means that the server doesn't force authenticity in
their "from" Jids -- this isn't true for client connections. So there you
are... you have now have a way to send out these presence updates, without
any protocol extension. Best of all... this stays solely within the realm
of your server, meaning that external type="pro..." or that <pro...>
element don't get populated out to contacts that aren't on my server. And
you have this information out in this external component, so if you choose
to write it to a database, you can do web-based availability ala ICQ. You
can even provide users with the ability to configure whether they want
their presence broadcast, by sending some other protocol to this
component.

Hope that helps...

Peter Saint-Andre said:
> Second, you can't just add new presence types to the protocol. :-) This
> protocol is now in IETF Last Call. Just as you can't add a new HTTP
> method because you think PUT and GET are not enough, you can't add new
> presence types willy-nilly.

As a protocol junky, I felt it was necessary to step up and correct this
wrong. From section 9 of RFC 2616:

   The set of common methods for HTTP/1.1 is defined below. Although
   this set can be expanded, additional methods cannot be assumed to
   share the same semantics for separately extended clients and servers.

So you *can* add new methods, but you can't assume that other clients,
server, etc. will listen to 'em. It should be noted, however, that since
XMPP is defined by a series of schema's, that a validating implementation
of the protocol would likely boot you for sending type="pro..." (as well
as type="invisible").

Cheers,

bs.