slidge.contact¶
Everything related to 1 on 1 chats, and other legacy users’ details.
Classes¶
This class centralizes actions in relation to a specific legacy contact. |
|
Virtual roster of a gateway user, that allows to represent all |
Package Contents¶
- class slidge.contact.LegacyContact(session, legacy_id, jid_username)¶
This class centralizes actions in relation to a specific legacy contact.
You shouldn’t create instances of contacts manually, but rather rely on
LegacyRoster.by_legacy_id()
to ensure that contact instances are singletons. TheLegacyRoster
instance of a session is accessible through theBaseSession.contacts
attribute.Typically, your plugin should have methods hook to the legacy events and call appropriate methods here to transmit the “legacy action” to the xmpp user. This should look like this:
Use
carbon=True
as a keyword arg for methods to represent an action FROM the user TO the contact, typically when the user uses an official client to do an action such as sending a message or marking as message as read. This will use XEP-0363 to impersonate the XMPP user in order.- Parameters:
session (slidge.core.session.BaseSession)
legacy_id (slidge.util.types.LegacyUserIdType)
jid_username (str)
- RESOURCE: str = 'slidge'¶
A full JID, including a resource part is required for chat states (and maybe other stuff) to work properly. This is the name of the resource the contacts will use.
- legacy_id: slidge.util.types.LegacyUserIdType¶
The legacy identifier of the Legacy Contact. By default, this is the JID Local Part of this XMPP Entity.
Controlling what values are valid and how they are translated from a JID Local Part is done in
jid_username_to_legacy_id()
. Reciprocally, inlegacy_id_to_jid_username()
the inverse transformation is defined.
- property client_type: slidge.util.types.ClientType¶
The client type of this contact, cf https://xmpp.org/registrar/disco-categories.html#client
Default is “pc”.
- Return type:
slidge.util.types.ClientType
- get_msg_xmpp_id_up_to(horizon_xmpp_id)¶
Return XMPP msg ids sent by this contact up to a given XMPP msg id.
Plugins have no reason to use this, but it is used by slidge core for legacy networks that need to mark all messages as read (most XMPP clients only send a read marker for the latest message).
This has side effects, if the horizon XMPP id is found, messages up to this horizon are not cleared, to avoid sending the same read mark twice.
- property name¶
Friendly name of the contact, as it should appear in the user’s roster
- async add_to_roster(force=False)¶
Add this contact to the user roster using XEP-0356
- Parameters:
force – add even if the contact was already added successfully
- async accept_friend_request(text=None)¶
Call this to signify that this Contact has accepted to be a friend of the user.
- Parameters:
text (Optional[str]) – Optional message from the friend to the user
- reject_friend_request(text=None)¶
Call this to signify that this Contact has refused to be a contact of the user (or that they don’t want to be friends anymore)
- Parameters:
text (Optional[str]) – Optional message from the non-friend to the user
- async on_friend_request(text='')¶
Called when receiving a “subscribe” presence, ie, “I would like to add you to my contacts/friends”, from the user to this contact.
In XMPP terms: “I would like to receive your presence updates”
This is only called if self.is_friend = False. If self.is_friend = True, slidge will automatically “accept the friend request”, ie, reply with a “subscribed” presence.
When called, a ‘friend request event’ should be sent to the legacy service, and when the contact responds, you should either call self.accept_subscription() or self.reject_subscription()
- async on_friend_delete(text='')¶
Called when receiving an “unsubscribed” presence, ie, “I would like to remove you to my contacts/friends” or “I refuse your friend request” from the user to this contact.
In XMPP terms: “You won’t receive my presence updates anymore (or you never have)”.
- async on_friend_accept()¶
Called when receiving a “subscribed” presence, ie, “I accept to be your/confirm that you are my friend” from the user to this contact.
In XMPP terms: “You will receive my presence updates”.
- unsubscribe()¶
(internal use by slidge)
Send an “unsubscribe”, “unsubscribed”, “unavailable” presence sequence from this contact to the user, ie, “this contact has removed you from their ‘friends’”.
- async update_info()¶
Fetch information about this contact from the legacy network
This is awaited on Contact instantiation, and should be overridden to update the nickname, avatar, vcard […] of this contact, by making “legacy API calls”.
To take advantage of the slidge avatar cache, you can check the .avatar property to retrieve the “legacy file ID” of the cached avatar. If there is no change, you should not call
slidge.core.mixins.avatar.AvatarMixin.set_avatar()
or attempt to modify the.avatar
property.
- async fetch_vcard()¶
It the legacy network doesn’t like that you fetch too many profiles on startup, it’s also possible to fetch it here, which will be called when XMPP clients of the user request the vcard, if it hasn’t been fetched before :return:
- class slidge.contact.LegacyRoster(session)¶
Virtual roster of a gateway user, that allows to represent all of their contacts as singleton instances (if used properly and not too bugged).
Every
BaseSession
instance will have its ownLegacyRoster
instance accessible via theBaseSession.contacts
attribute.Typically, you will mostly use the
LegacyRoster.by_legacy_id()
function to retrieve a contact instance.You might need to override
LegacyRoster.legacy_id_to_jid_username()
and/orLegacyRoster.jid_username_to_legacy_id()
to incorporate some custom logic if you need some characters when translation JID user parts and legacy IDs.- Parameters:
session (slidge.core.session.BaseSession)
- async by_legacy_id(legacy_id, *args, **kwargs)¶
Retrieve a contact by their legacy_id
If the contact was not instantiated before, it will be created using
slidge.LegacyRoster.legacy_id_to_jid_username()
to infer their legacy user ID.- Parameters:
legacy_id (slidge.util.types.LegacyUserIdType)
args – arbitrary additional positional arguments passed to the contact constructor. Requires subclassing LegacyContact.__init__ to accept those. This is useful for networks where you fetch the contact list and information about these contacts in a single request
kwargs – arbitrary keyword arguments passed to the contact constructor
- Returns:
- Return type:
slidge.util.types.LegacyContactType
- async legacy_id_to_jid_username(legacy_id)¶
Convert a legacy ID to a valid ‘user’ part of a JID
Should be overridden for cases where the str conversion of the legacy_id is not enough, e.g., if it is case-sensitive or contains forbidden characters not covered by XEP-0106.
- Parameters:
legacy_id (slidge.util.types.LegacyUserIdType)
- Return type:
- async jid_username_to_legacy_id(jid_username)¶
Convert a JID user part to a legacy ID.
Should be overridden in case legacy IDs are not strings, or more generally for any case where the username part of a JID (unescaped with to the mapping defined by XEP-0106) is not enough to identify a contact on the legacy network.
Default implementation is an identity operation
- Parameters:
jid_username (str) – User part of a JID, ie “user” in “user@example.com”
- Returns:
An identifier for the user on the legacy network.
- Return type:
slidge.util.types.LegacyUserIdType
- async fill()¶
Populate slidge’s “virtual roster”.
This should yield contacts that are meant to be added to the user’s roster, typically by using
await self.by_legacy_id(contact_id)
. Setting the contact nicknames, avatar, etc. should be inLegacyContact.update_info()
It’s not mandatory to override this method, but it is recommended way to populate “friends” of the user. Calling
await (await self.by_legacy_id(contact_id)).add_to_roster()
accomplishes the same thing, but doing it in here allows to batch DB queries and is better performance-wise.- Return type:
AsyncIterator[slidge.contact.contact.LegacyContact]