slidge.plugins.signal.gateway#

Module Contents#

Classes#

Link

Abstract base class to implement gateway commands (chatbot and ad-hoc)

LinkedDevices

Abstract base class to implement gateway commands (chatbot and ad-hoc)

LinkDevice

Abstract base class to implement gateway commands (chatbot and ad-hoc)

ChangeContactName

Abstract base class to implement gateway commands (chatbot and ad-hoc)

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.

Functions#

Attributes#

log

Bases: slidge.core.command.Command

Abstract base class to implement gateway commands (chatbot and ad-hoc)

Parameters:

xmpp (slidge.core.gateway.BaseGateway) –

NAME = 'Link your signal account to slidge'[source]#
HELP = "Use an existing signal account with slidge as a 'secondary device'. You will need to keep your..."[source]#
ACCESS[source]#
PROPER_RECEIPTS = True[source]#
xmpp: Gateway[source]#
async run(_session, ifrom, *args)[source]#

Entry point of the command

Parameters:
  • session – If triggered by a registered user, its slidge Session

  • ifrom (slixmpp.JID) – JID of the command-triggering entity

  • args – When triggered via chatbot type message, additional words after the CHAT_COMMAND string was passed

Returns:

Either a TableResult, a Form, a Confirmation, a text, or None

async show_code(form_values, _session, ifrom)[source]#
Parameters:

form_values (dict) –

async finish(_form_values, _session, ifrom, session_id, phone, device)[source]#
class slidge.plugins.signal.gateway.LinkedDevices(xmpp)[source]#

Bases: slidge.core.command.Command

Abstract base class to implement gateway commands (chatbot and ad-hoc)

Parameters:

xmpp (slidge.core.gateway.BaseGateway) –

NAME = 'List the devices linked to your signal account'[source]#
HELP = 'List all the devices that have access to your signal account'[source]#
ACCESS[source]#
xmpp: Gateway[source]#
async run(session, ifrom, *args)[source]#

Entry point of the command

Parameters:
  • session – If triggered by a registered user, its slidge Session

  • ifrom (slixmpp.JID) – JID of the command-triggering entity

  • args – When triggered via chatbot type message, additional words after the CHAT_COMMAND string was passed

Returns:

Either a TableResult, a Form, a Confirmation, a text, or None

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

Bases: slidge.core.command.Command

Abstract base class to implement gateway commands (chatbot and ad-hoc)

Parameters:

xmpp (slidge.core.gateway.BaseGateway) –

NAME = 'Link a new device to your signal account'[source]#
HELP = 'Use slidge to add a device to your signal account'[source]#
ACCESS[source]#
xmpp: Gateway[source]#
async run(session, ifrom, *args)[source]#

Entry point of the command

Parameters:
  • session – If triggered by a registered user, its slidge Session

  • ifrom (slixmpp.JID) – JID of the command-triggering entity

  • args – When triggered via chatbot type message, additional words after the CHAT_COMMAND string was passed

Returns:

Either a TableResult, a Form, a Confirmation, a text, or None

async finish(form_values, session, _ifrom)[source]#
Parameters:

session (slidge.plugins.signal.session.Session) –

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

Bases: slidge.core.command.Command

Abstract base class to implement gateway commands (chatbot and ad-hoc)

Parameters:

xmpp (slidge.core.gateway.BaseGateway) –

NAME = 'Rename a signal contact'[source]#
HELP = 'Change the contact_name of a signal contact. This is stored on your signal account only.'[source]#
ACCESS[source]#
xmpp: Gateway[source]#
async run(session, ifrom, *args)[source]#

Entry point of the command

Parameters:
  • session – If triggered by a registered user, its slidge Session

  • ifrom (slixmpp.JID) – JID of the command-triggering entity

  • args – When triggered via chatbot type message, additional words after the CHAT_COMMAND string was passed

Returns:

Either a TableResult, a Form, a Confirmation, a text, or None

async finish(form_values, session, _ifrom)[source]#
Parameters:

session (slidge.plugins.signal.session.Session) –

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_TYPE[source]#
ROSTER_GROUP = 'Signal'[source]#
SEARCH_FIELDS[source]#
signal: asyncio.Future[Signal][source]#
sessions_by_phone: dict[str, slidge.plugins.signal.session.Session][source]#
GROUPS = True[source]#
async connect_signal(socket)[source]#

Establish connection to the signald socker

Parameters:

socket (pathlib.Path) –

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 validate_two_factor_code(user, code)[source]#

Called when the user enters their 2FA code.

Should raise the appropriate XMPPError if the login fails

Parameters:
  • user (slidge.GatewayUser) – The gateway user whose registration is pending Use their .bare_jid and/or``.registration_form`` attributes to get what you need

  • code (str) – The code they entered, either via “chatbot” message or adhoc command

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.

You may need to manually logout the legacy session in here, Session.logout() will not be called automatically.

Parameters:

user (slidge.GatewayUser) –

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

Bases: aiosignald.SignaldAPI

Extends SignaldAPI with handlers for events we are interested in.

Parameters:
  • on_con_lost – its result will be set to True once the connection is lost If not given, will be automatically generated.

  • 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.fmt_time(t)[source]#
Parameters:

t (float) –

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