Python Synapse

Open-source Python projects categorized as Synapse Edit details

Top 6 Python Synapse Projects

  • Zulip

    Zulip server and web app—powerful open source team chat

    Project mention: Will Bun JavaScript Take Node's Crown | | 2022-08-14

    Did you look at zulip?

    I'm not convinced it's better than irc+proper mailing lists - but given that real users are stuck in awful mail clients (like web/Gmail or outlook) - mailing lists isn't a great option any more.

    Main thing I miss from zulip is a proper weechat plug-in (like wee-slack) - although the official cli client isn't terrible - it's just not irc-like.

  • bindsnet

    Simulation of spiking neural networks (SNNs) using PyTorch.

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • Spiking-Neural-Network

    Pure python implementation of SNN

  • synadm

    Command line admin tool for Synapse (Matrix reference homeserver)

    Project mention: How are people dealing with server storage filling up? | | 2022-05-15

    im trying to get synadm working but have been recommended this now:

  • 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

  • matrix-encrypted-webhooks

    Send any JSON and form data through webhooks to Matrix end-to-end encrypted (E2EE) rooms with HTTP POST requests

    Project mention: Sending an attachment through a webhook | | 2021-08-21
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 2022-08-14.

Python Synapse related posts


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

Project Stars
1 Zulip 16,203
2 bindsnet 1,122
3 Spiking-Neural-Network 761
4 synadm 102
5 matrix-synapse-shared-secret-auth 52
6 matrix-encrypted-webhooks 11
Find remote jobs at our new job board There are 3 new remote jobs listed recently.
Are you hiring? Post a new remote job listing for free.
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives