slidge.plugins.signal.gateway#

Module Contents#

Classes#

Gateway

Must be subclassed by a plugin to set up various aspects of the XMPP

Signal

Extends SignaldAPI with handlers for events we are interested in.

Attributes#

log

class slidge.plugins.signal.gateway.Gateway[source]#

Bases: slidge.BaseGateway

Must be subclassed by a plugin to set up various aspects of the XMPP component behaviour, such as its display name or its registration process.

On slidge launch, a singleton is instantiated, and it will be made available to public classes such LegacyContact or BaseSession as the .xmpp attribute. Since it inherits from slixmpp.componentxmpp.ComponentXMPP, this gives you a hand on low-level XMPP interactions via slixmpp plugins, e.g.:

self.send_presence(
    pfrom="somebody@component.example.com",
    pto="someonwelse@anotherexample.com",
)

However, you should not need to do so often since the classes of the plugin API provides higher level abstractions around most commonly needed use-cases, such as sending messages, or displaying a custom status.

COMPONENT_NAME = Signal (slidge)[source]#
COMPONENT_TYPE = signal[source]#
COMPONENT_AVATAR = https://upload.wikimedia.org/wikipedia/commons/5/56/Logo_Signal..png[source]#
REGISTRATION_INSTRUCTIONS[source]#
REGISTRATION_FIELDS[source]#
REGISTRATION_MULTISTEP = True[source]#
ROSTER_GROUP = Signal[source]#
SEARCH_FIELDS[source]#
signal :asyncio.Future[Signal][source]#
sessions_by_phone :dict[str, slidge.plugins.signal.session.Session][source]#
CHAT_COMMANDS[source]#
async connect_signal(socket)[source]#

Establish connection to the signald socker

Parameters

socket (pathlib.Path) –

add_adhoc_commands()[source]#

Override this if you want to provide custom adhoc commands (XEP-0050) for your plugin, using slixmpp.plugins.xep_0050.XEP_0050

Basic example:

async _handle_linked_devices(iq, adhoc_session)[source]#
Parameters
  • iq (slixmpp.Iq) –

  • adhoc_session (dict[str, Any]) –

async _handle_add_device1(iq, adhoc_session)[source]#
Parameters
  • iq (slixmpp.Iq) –

  • adhoc_session (dict[str, Any]) –

async _handle_add_device2(stanza, adhoc_session)[source]#
Parameters
  • stanza (slixmpp.plugins.xep_0004.Form) –

  • adhoc_session (dict[str, Any]) –

async static _chat_command_add_device(*args, msg, session=None)[source]#
Parameters
async static _chat_command_get_identities(*args, msg, session=None)[source]#
Parameters
async validate(user_jid, registration_form)[source]#

Validate a registration form from a user.

Since XEP-0077 is pretty limited in terms of validation, it is OK to validate anything that looks good here and continue the legacy auth process via direct messages to the user (using BaseGateway.input() for instance)

Parameters
async unregister(user)[source]#

Optionally override this if you need to clean additional stuff after a user has been removed from the permanent user_store.

Parameters

user (slidge.GatewayUser) –

Returns

class slidge.plugins.signal.gateway.Signal(xmpp)[source]#

Bases: aiosignald.SignaldAPI

Extends SignaldAPI with handlers for events we are interested in.

Parameters

xmpp (Gateway) –

async handle_WebSocketConnectionState(state, payload)[source]#

We should not care much about this since

Parameters
async handle_ListenerState(state, payload)[source]#

Deprecated in signald and replaced by WebSocketConnectionState Just here to avoid cluttering logs with unhandled events warnings

Parameters
async handle_IncomingMessage(msg, _payload)[source]#

Dispatch a signald message to the proper session.

Can be a lot of other things than an actual message, still need to figure things out to cover all cases.

Parameters
slidge.plugins.signal.gateway.log[source]#