Python matrix-org

Open-source Python projects categorized as matrix-org

Top 9 Python matrix-org Projects

  • Synapse

    Synapse: Matrix homeserver written in Python/Twisted.

    Project mention: Matrix 2.0 — Matthew Hodgson talks about Rust in Element client, Rust SDK, IETF MLS, MIMI and more | | 2023-02-07

    Now, the Matrix Foundation has decided to use Rust to improve bits and pieces of their Gen 1 Home Server - Synapse. The server itself is still largely in Python though. That being said, some of the improvements to the performance of Synapse based home servers can partly be attributed to the usage of Rust.

  • telegram

    A Matrix-Telegram hybrid puppeting/relaybot bridge (by mautrix)

    Project mention: Selfhosted application for joining chat services? | | 2022-07-31
  • Sonar

    Write Clean Python Code. Always.. Sonar helps you commit clean code every time. With over 225 unique rules to find Python bugs, code smells & vulnerabilities, Sonar finds the issues while you focus on the work.

  • maubot

    A plugin-based Matrix bot system.

    Project mention: RSS is on fire again, and it's all down to SlackOps | | 2022-07-18
  • signal

    A Matrix-Signal puppeting bridge (by mautrix)

    Project mention: Hosting Signal frontend on a local server (Like Signal desktop but through website) | | 2022-11-30

    OWS has historically been hostile to third party implementations outside of their clients. There are multiple unofficial options but the only one I've been looking at is the bridge with matrix, though setting up a matrix server just for this is likely overkill.

  • facebook

    A Matrix-Facebook Messenger puppeting bridge (by mautrix)

    Project mention: Most used selfhosted services in 2022? | | 2022-12-27

    Sure, I use this bridge ( to bridge synapse server to my facebook account, so I can use facebook messenger through my synapse server. I like it mainly so I don't have to install facebook messenger on my phone.

  • matrix-registration

    a token based matrix registration api

  • instagram

    A Matrix-Instagram DM puppeting bridge (by mautrix)

  • InfluxDB

    Build time-series-based applications quickly and at scale.. InfluxDB is the Time Series Platform where developers build real-time applications for analytics, IoT and cloud-native services. Easy to start, it is available in the cloud or on-premises.

  • googlechat

    A Matrix-Google Chat puppeting bridge

    Project mention: Google Chat through Matrix questions | | 2022-04-30
  • matrix-synapse-shared-secret-auth

    Shared Secret Authenticator password provider module for Matrix Synapse

    Project mention: Mautrix-whatsapp configuration | | 2022-05-13

    bridge:    # Localpart template of MXIDs for WhatsApp users.    # {{.}} is replaced with the phone number of the WhatsApp user.    usernametemplate: whatsapp{{.}}    # Displayname template for WhatsApp users.    # {{.PushName}}     - nickname set by the WhatsApp user    # {{.BusinessName}} - validated WhatsApp business name    # {{.Phone}}        - phone number (international format)    # The following variables are also available, but will cause problems on multi-user instances:    # {{.FullName}}  - full name from contact list    # {{.FirstName}} - first name from contact list    displayname_template: "{{if .PushName}}{{.PushName}}{{else if .BusinessName}}{{.BusinessName}}{{else}}{{.JID}}{{end}} (WA)"    # Should the bridge create a space for each logged-in user and add bridged rooms to it?    # Users who logged in before turning this on should run !wa sync space to create and fill the space for the first time.    personal_filtering_spaces: false    # Should the bridge send a read receipt from the bridge bot when a message has been sent to WhatsApp?    delivery_receipts: false    # Should incoming calls send a message to the Matrix room?    call_start_notices: true    # Should another user's cryptographic identity changing send a message to Matrix?    identity_change_notices: false    portal_message_buffer: 128    # Settings for handling history sync payloads.    history_sync:        # Should the bridge create portals for chats in the history sync payload?        create_portals: true        # Enable backfilling history sync payloads from WhatsApp using batch sending?        # This requires a server with MSC2716 support, which is currently an experimental feature in synapse.        # It can be enabled by setting experimental_features -> msc2716_enabled to true in homeserver.yaml.        # Note that prior to Synapse 1.49, there were some bugs with the implementation, especially if using event persistence workers.        # There are also still some issues in Synapse's federation implementation.        backfill: false        # Use double puppets for backfilling?        # In order to use this, the double puppets must be in the appservice's user ID namespace        # (because the bridge can't use the double puppet access token with batch sending).        # This only affects double puppets on the local server, double puppets on other servers will never be used.        double_puppet_backfill: false        # Should the bridge request a full sync from the phone when logging in?        # This bumps the size of history syncs from 3 months to 1 year.        request_full_sync: false        # Settings for media requests. If the media expired, then it will not        # be on the WA servers.        # Media can always be requested by reacting with the ♻️ (recycle) emoji.        # These settings determine if the media requests should be done        # automatically during or after backfill.        media_requests:            # Should expired media be automatically requested from the server as            # part of the backfill process?            auto_request_media: true            # Whether to request the media immediately after the media message            # is backfilled ("immediate") or at a specific time of the day            # ("local_time").            request_method: immediate            # If request_method is "local_time", what time should the requests            # be sent (in minutes after midnight)?            request_local_time: 120        # The maximum number of initial conversations that should be synced.        # Other conversations will be backfilled on demand when the start PM        # provisioning endpoint is used or when a message comes in from that        # chat.        max_initial_conversations: -1        # Settings for immediate backfills. These backfills should generally be        # small and their main purpose is to populate each of the initial chats        # (as configured by max_initial_conversations) with a few messages so        # that you can continue conversations without loosing context.        immediate:            # The number of concurrent backfill workers to create for immediate            # backfills. Note that using more than one worker could cause the            # room list to jump around since there are no guarantees about the            # order in which the backfills will complete.            worker_count: 1            # The maximum number of events to backfill initially.            max_events: 10        # Settings for deferred backfills. The purpose of these backfills are        # to fill in the rest of the chat history that was not covered by the        # immediate backfills. These backfills generally should happen at a        # slower pace so as not to overload the homeserver.        # Each deferred backfill config should define a "stage" of backfill        # (i.e. the last week of messages). The fields are as follows:        # - start_days_ago: the number of days ago to start backfilling from.        #     To indicate the start of time, use -1. For example, for a week ago, use 7.        # - max_batch_events: the number of events to send per batch.        # - batch_delay: the number of seconds to wait before backfilling each batch.        deferred:            # Last Week            - start_days_ago: 7              max_batch_events: 20              batch_delay: 5            # Last Month            - start_days_ago: 30              max_batch_events: 50              batch_delay: 10            # Last 3 months            - start_days_ago: 90              max_batch_events: 100              batch_delay: 10            # The start of time            - start_days_ago: -1              max_batch_events: 500              batch_delay: 10    # Should puppet avatars be fetched from the server even if an avatar is already set?    user_avatar_sync: true    # Should Matrix users leaving groups be bridged to WhatsApp?    bridge_matrix_leave: true    # Should the bridge sync with double puppeting to receive EDUs that aren't normally sent to appservices.    sync_with_custom_puppets: true    # Should the bridge update the account data event when double puppeting is enabled.    # Note that updating the event is not atomic (except with mautrix-asmux)    # and is therefore prone to race conditions.    sync_direct_chat_list: false    # When double puppeting is enabled, users can use !wa toggle to change whether    # presence and read receipts are bridged. These settings set the default values.    # Existing users won't be affected when these are changed.    default_bridge_receipts: true    default_bridge_presence: true    # Send the presence as "available" to whatsapp when users start typing on a portal.    # This works as a workaround for homeservers that do not support presence, and allows    # users to see when the whatsapp user on the other side is typing during a conversation.    send_presence_on_typing: false    # Should the bridge always send "active" delivery receipts (two gray ticks on WhatsApp)    # even if the user isn't marked as online (e.g. when presence bridging isn't enabled)?    #    # By default, the bridge acts like WhatsApp web, which only sends active delivery    # receipts when it's in the foreground.    force_active_delivery_receipts: false    # Servers to always allow double puppeting from    double_puppet_server_map:    # Allow using double puppeting from any server with a valid client .well-known file.    double_puppet_allow_discovery: false    # Shared secrets for    #    # If set, double puppeting will be enabled automatically for local users    # instead of users having to find an access token and run login-matrix    # manually.    login_shared_secret_map: foobar    # Should the bridge explicitly set the avatar and room name for private chat portal rooms?    private_chat_portal_meta: false    # Should Matrix m.notice-type messages be bridged?    bridge_notices: true    # Set this to true to tell the bridge to re-send m.bridge events to all rooms on the next run.    # This field will automatically be changed back to false after it, except if the config file is not writable.    resend_bridge_info: false    # When using double puppeting, should muted chats be muted in Matrix?    mute_bridging: false    # When using double puppeting, should archived chats be moved to a specific tag in Matrix?    # Note that WhatsApp unarchives chats when a message is received, which will also be mirrored to Matrix.    # This can be set to a tag (e.g. m.lowpriority), or null to disable.    archive_tag: null    # Same as above, but for pinned chats. The favorite tag is called m.favourite    pinned_tag: null    # Should mute status and tags only be bridged when the portal room is created?    tag_only_on_create: true    # Should WhatsApp status messages be bridged into a Matrix room?    # Disabling this won't affect already created status broadcast rooms.    enable_status_broadcast: true    # Should the status broadcast room be muted and moved into low priority by default?    # This is only applied when creating the room, the user can unmute it later.    mute_status_broadcast: true    # Tag to apply to the status broadcast room.    status_broadcast_tag: m.lowpriority    # Should the bridge use thumbnails from WhatsApp?    # They're disabled by default due to very low resolution.    whatsapp_thumbnail: false    # Allow invite permission for user. User can invite any bots to room with whatsapp    # users (private chat and groups)    allow_user_invite: false    # Whether or not created rooms should have federation enabled.    # If false, created portal rooms will never be federated.    federate_rooms: true    # Whether to enable disappearing messages in groups. If enabled, then the expiration time of    # the messages will be determined by the first user to read the message, rather than individually.    # If the bridge only has a single user, this can be turned on safely.    disappearing_messages_in_groups: false    # Should the bridge never send alerts to the bridge management room?    # These are mostly things like the user being logged out.    disable_bridge_alerts: false    # Should the bridge detect URLs in outgoing messages, ask the homeserver to generate a preview,    # and send it to WhatsApp? URL previews can always be sent using the com.beeper.linkpreviews    # key in the event content even if this is disabled.    url_previews: false

NOTE: The open source projects on this list are ordered by number of github stars. The number of mentions indicates repo mentiontions in the last 12 Months or since we started tracking (Dec 2020). The latest post mention was on 2023-02-07.

Python matrix-org related posts


What are some of the best open-source matrix-org projects in Python? This list will help you:

Project Stars
1 Synapse 10,483
2 telegram 940
3 maubot 479
4 signal 333
5 facebook 309
6 matrix-registration 200
7 instagram 93
8 googlechat 79
9 matrix-synapse-shared-secret-auth 61
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives