- class slidge.plugins.signal.contact.Contact(*a, **k)#
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. The
LegacyRosterinstance of a session is accessible through the
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:
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
- CORRECTION = False#
- async get_identities()#
- async carbon_send_attachments(attachments)#
- async send_attachments(attachments, /, legacy_msg_id=None, reply_to_msg_id=None, when=None)#
- async update_and_add()#
attachment (aiosignald.generated.JsonAttachmentv1) –
- class slidge.plugins.signal.contact.Roster(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).
Typically, you will mostly use the
LegacyRoster.by_legacy_id()function to retrieve a contact instance.
You might need to override
LegacyRoster.jid_username_to_legacy_id()to incorporate some custom logic if you need some characters when translation JID user parts and legacy IDs.
session (slidge.core.session.SessionType) –