Set this to a true value if no roster should be requested on connection establishment. You can retrieve the roster later if you want to with the retrieve_roster method.

The internal roster will be set even if this option is active, and even presences will be stored in there, except that the get_contacts method on the roster object won't return anything as there are no roster items.

This method initiates a roster request. If you set dont_retrieve_roster when creating this connection no roster was retrieved. You can do that with this method. The coderef in $cb will be called after the roster was retrieved.

The first argument of the callback in $cb will be the roster and the second will be a AnyEvent::XMPP::Error::IQ object when an error occurred while retrieving the roster.

This event is emitted when a roster update has been received. $contacts is an array reference of AnyEvent::XMPP::IM::Contact objects which have changed. If a contact was removed it will return 'remove' when you call the subscription method on it.

The first time this event is sent is when the roster was received for the first time.

This event is emitted when the presence of a contact has changed. $contact is the AnyEvent::XMPP::IM::Contact object which presence status has changed. $old_presence is a AnyEvent::XMPP::IM::Presence object which represents the presence prior to the change. $new_presence is a AnyEvent::XMPP::IM::Presence object which represents the presence after to the change. The new presence might be undef if the new presence is 'unavailable'.

If you want to start a mutual subscription you have to call send_subscribeAFTER you accepted or declined with send_subscribed/send_unsubscribed. Calling it in the opposite order gets some servers confused!

If a status element was transmitted with the subscription it's contents will be in $message. Which is usually a text written from the one who requests subscription.