slidgram.contact

Attributes

log

Classes

Roster

Virtual roster of a gateway user, that allows to represent all

Contact

Mixin for XMPP entities that have avatars that represent them.

Module Contents

class slidgram.contact.Roster(session)[source]

Bases: slidge.contact.LegacyRoster[int, Contact]

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 own LegacyRoster instance accessible via the BaseSession.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/or LegacyRoster.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)

session: slidgram.session.Session[source]
async jid_username_to_legacy_id(jid_username)[source]

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:

int

async fill()[source]

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 in LegacyContact.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.

class slidgram.contact.Contact(*a, **kw)[source]

Bases: slidgram.reactions.ReactionsMixin, slidgram.tg_msg.TelegramMessageSenderMixin, slidgram.avatar.SetAvatarMixin, slidge.contact.LegacyContact[int]

Mixin for XMPP entities that have avatars that represent them.

Both slidge.LegacyContact and slidge.LegacyMUC use AvatarMixin.

Parameters:
  • session – The session this contact is part of

  • legacy_id – The contact’s legacy ID

  • jid_username – User part of this contact’s ‘puppet’ JID. NB: case-insensitive, and some special characters are not allowed

xmpp: slidgram.gateway.Gateway[source]
session: slidgram.session.Session[source]
legacy_id: int[source]

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, in legacy_id_to_jid_username() the inverse transformation is defined.

async get_tg_user()[source]
Return type:

pyrogram.types.User

async update_info()[source]

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.

update_tg_status(user)[source]
Parameters:

user (pyrogram.types.User)

async send_tg_msg(message, carbon=False, correction=False, archive_only=False)[source]
Parameters:

message (pyrogram.types.Message)

Return type:

None

slidgram.contact.log[source]