matrix-spec-proposals VS matrix-synapse-shared-secret-auth

Compare matrix-spec-proposals vs matrix-synapse-shared-secret-auth and see what are their differences.

matrix-spec-proposals

Proposals for changes to the matrix specification (by matrix-org)

matrix-synapse-shared-secret-auth

Shared Secret Authenticator password provider module for Matrix Synapse (by devture)
Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
matrix-spec-proposals matrix-synapse-shared-secret-auth
48 1
937 76
2.7% -
7.5 3.7
6 days ago 3 months ago
Python
Apache License 2.0 GNU Affero General Public License v3.0
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

matrix-spec-proposals

Posts with mentions or reviews of matrix-spec-proposals. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-02-14.
  • The Matrix Trashfire
    7 projects | news.ycombinator.com | 14 Feb 2024
    Not only are they actually very closely linked, in that Element operates matrix.org, but to a new user (told to try Matrix -- what is this Element thing?) there's no difference.

    I onboarded a family member onto my Matrix server with FluffyChat as the client. This person is a power user, fairly technical, yet still refers to the chat as "FluffyChat" and although I've explained several times that choosing FluffyChat was maybe a mistake and they should use Element, it never seems to really click that multiple clients are possible.

    And really, they aren't possible. They have different subsets of features.

    If you want to see a trash can fire, just try to follow the discussion for adding custom emoji to Matrix: https://github.com/matrix-org/matrix-spec-proposals/pull/195...

    it's been going on for years. It's a feature the competitors have had for half a decade, as long as this discussion has been ongoing. I've been watching this issue for half a decade thinking "surely they'll decide on something" but mostly all I've been convinced of is this: Matrix is design by committee in all of the worst aspects and at every level of design. If anything gets done at all, it's a convoluted mess, and it's a miracle that it even happens.

    I wish community software developers would focus their attention.. somewhere else.

  • Bluesky and the at Protocol
    3 projects | news.ycombinator.com | 6 Feb 2024
    So Matrix also has account portability (almost) - https://github.com/matrix-org/matrix-spec-proposals/blob/keg... and https://github.com/devonh/matrix-spec-proposals/blob/cryptoI..., implemented in Dendrite. Unfortunately dev is paused on it currently thanks to lack of $ though.

    The AP approach (prioritising portable identities over portable account data) is cute though, and perhaps we should have prioritised that as an alternative to fullblown cryptographic IDs & account portability.

  • Non-profit Matrix.org Foundation seems to be moving funds to for-profit Element
    7 projects | news.ycombinator.com | 19 Nov 2023
    Luckily, it doesn't matter what individuals expect. There is written documentation on what the foundation is supposed to do or not to do: https://github.com/matrix-org/matrix-spec-proposals/blob/mai...

    Notably, "Code Core Team members must arrange their own funding for their time", which I understand as such that the Foundation does not pay directly the developers (same as other standards organizations like IETF).

    Main tasks of Matrix.org Foundation is maintaining the spec, documentation, owning IP, promotion and the matrix.org home server. The home server is "generously hosted" by UpCloud (i.e. is not using New Vector EMS), at least according to the matrix.org website.

    Looking again at MSC1779, I noticed it says that one function of The Matrix.org Foundation is "Owns the copyright of the reference implementations of Matrix (i.e. everything in https://github.com/matrix-org). By assigning copyright to the Foundation, it’s protected against New Vector ever being tempted to relicense it." That protection apparently wasn't very effective, but also notably, New Vector and their leadership clearly have shown to not stand behind the goals of the Foundation. As the leadership of New Vector is also part of the leadership of the Foundation, I see some huge potential for COI here.

  • Matrix 2.0: The Future of Matrix
    13 projects | news.ycombinator.com | 21 Sep 2023
    The main remaining Nebuchadnezzar issue is mitigating server-controlled group membership. The first step has been to kill off the 1st gen E2EE implementations, which were responsible for the implementation vulns found by RHUL - and we should hopefully conclude that next week by moving everything into the matrix-rust-sdk crypto create implmentation: https://github.com/vector-im/element-web/issues/21972#issuec... is the tracker.

    Then, we can address the harder server-controlled group membership issue in one place. First step will be to improve device verification & trust so that trust is the default, not the exception, to make it easier to spot and warn about unexpected devices in the room. The full solution is then either MSC3917 (https://github.com/matrix-org/matrix-spec-proposals/blob/fay...) - or potentially to switch everything to MLS.

    We're working on MLS anyway in parallel to RHUL mitigation work; you can see the progress at https://arewemlsyet.com, and it's looking good.

    I'm guessing you're not interested in doing a podcast on "yay we converged our crypto implementations on a single robust Rust implementation so we can fix the remaining bugs in one place", but as soon as the server-controlled group membership thing is solved we'll be in touch. Work has also gone much slower than hoped on this, thanks to the joys of funding open source.

  • Conduit: Simple, fast and reliable chat server powered by matrix
    4 projects | news.ycombinator.com | 30 Jul 2023
    https://github.com/matrix-org/matrix-spec-proposals/blob/keg... is how we’re doing it, and it’s being implemented currently in Dendrite.
  • Databag – tiny self-hosted federated messenger for the decentralized web
    3 projects | news.ycombinator.com | 22 Jul 2023
    Matrix already has key-based identity in the works at https://github.com/matrix-org/matrix-spec-proposals/blob/keg... (and implemented in Dendrite at https://github.com/matrix-org/dendrite/pulls?q=is%3Apr+is%3A...). Matrix is set up to let folks go wild and change fundamentals like this; basically every Matrix Spec Change (MSC) is a small fork, which then gets merged into the main spec if it can be proven to work well in the wild.
  • Discord Is Not Documentation
    5 projects | news.ycombinator.com | 16 Jul 2023
    Gitter seems to have moved to being a Matrix instance (or maybe it always has? it didn't look like Matrix when I used it circa 2016), but matrix feels half-baked and is just a bunch of hacks put together. For example

    - Can't "mark all as read" on a space. probably because rooms within a space are only tangentially related,

    - No custom emojis or sticker packs (their proposal for this is to create rooms to house custom emojis/sticker packs[0])

    Not a great bet to go to keybase with the Zoom acquisition https://news.ycombinator.com/item?id=28814210

    0: https://github.com/matrix-org/matrix-spec-proposals/pull/195...

  • The problem with federated web apps
    5 projects | news.ycombinator.com | 1 Jul 2023
    We’re currently working on account portability (https://github.com/matrix-org/matrix-spec-proposals/pull/401...) and experimenting with glueing bluesky style DIDs onto it (so as to provide DMs for bluesky via Matrix, should they want them)
  • are calls encrypted
    2 projects | /r/matrixdotorg | 29 May 2023
    If you want to use the new Element Call you have to use the URL call.element.io, (as the proposal have not yet be included in the Matrix specification).
  • The AT protocol is the most obtuse crock of s*
    9 projects | news.ycombinator.com | 9 May 2023
    AT proto has some significant similarities to Matrix:

    * Both are work by self-authenticating git-style replication of Merkle trees/DAGs

    * Both define strict data schemas for extensible sets of events (Matrix uses JSON schema - https://github.com/matrix-org/matrix-spec/tree/main/data/eve... and OpenAPI; AT uses Lexicons)

    * Both use HTTPS for client-server and server-server traffic by default.

    * Both are focused on decentralised composable reputation - e.g. https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix... on the Matrix side, or https://paulfrazee.medium.com/the-anti-parler-principles-for... on the bluesky side, etc.

    * Both are designed as big-world communication networks. You don't have the server balkanisation that affects ActivityPub.

    * Both eschew cryptocurrency systems and incentives.

    There are some significant differences too:

    * Matrix aspires to be the secure communication layer for the open web.

    * AT aspires (i think) to be an open decentralised social networking protocol for the internet.

    * AT has portable identity by default. We've been working on this on Matrix (e.g. MSC1228 - https://github.com/matrix-org/matrix-spec-proposals/pull/122... and MSC2787 - https://github.com/matrix-org/matrix-spec-proposals/blob/nei...) and have a new MSC (and implementation on Dendrite) in progress right now which combines the best bits of MSC1228 & MSC2787 into something concrete, at last. In fact the proto-MSC is due to emerge today.

    * AT is proposing a asymmetrical federation architecture where user data is stored on Personal Data Servers (PDS), but indexing/fan-out/etc is done by Big Graph Servers (BGS). Matrix is symmetrical and by default federates full-mesh between all servers participating in a conversation, which on one hand is arguably better from a self-sovereignty and resilience perspective - but empirically has created headaches where an underpowered server joins some massive public chatroom and then melts. Matrix has improved this by steady optimisation of both protocol and implementation (i.e. adding lazy loading everywhere - e.g. https://matrix-org.github.io/synapse/latest/development/syna...), but formalising an asymmetrical architecture is an interesting different approach :)

    * AT is (today) focused on for public conversations (e.g. prioritising big-world search and indexing etc), whereas Matrix focuses both on private and public communication - whether that's public chatrooms with 100K users over 10K servers, or private encrypted group conversations. For instance, one of Matrix's big novelties is decentralised access control without finality (https://matrix.org/blog/2020/06/16/matrix-decomposition-an-i...) in order to enforce access control for private conversations.

    * Matrix also provides end-to-end encryption for private conversations by default, today via Double Ratchet (Olm/Megolm) and in the nearish future MLS (https://arewemlsyet.com). We're also starting to work on post quantum crypto.

    * Matrix is obviously ~7 years older, and has many more use cases fleshed out - whether that's native VoIP/Video a la Element Call (https://element.io/blog/introducing-native-matrix-voip-with-...) or virtual worlds like Third Room (https://thirdroom.io) or shared whiteboarding (https://github.com/toger5/TheBoard) etc.

    * AT's lexicon approach looks to be a more modular to extend the protocol than Matrix's extensible event schemas - in that AT lexicons include both RPC definitions as well as the schemas for the underlying datatypes, whereas in Matrix the OpenAPI evolves separately to the message schemas.

    * AT uses IPLD; Matrix uses Canonical JSON (for now)

    * Matrix is perhaps more sophisticated on auth, in that we're switching to OpenID Connect for all authentication (and so get things like passkeys and MFA for free): https://areweoidcyet.com

    * Matrix has an open governance model with >50% of spec proposals coming from the wider community these days: https://spec.matrix.org/proposals

    * AT has done a much better job of getting mainstream uptake so far, perhaps thanks to building a flagship app from day one (before even finishing or opening up the protocol) - whereas Element coming relatively late to the picture has meant that Element development has been constantly slowed by dealing with existing protocol considerations (and even then we've had constant complaints about Element being too influential in driving Matrix development).

    * AT backs up all your personal data on your client (space allowing), to aid portability, whereas Matrix is typically thin-client.

    * Architecturally, Matrix is increasingly experimenting with a hybrid P2P model (https://arewep2pyet.com) as our long-term solution - which effectively would end up with all your data being synced to your client. I'd assume bluesky is consciously avoiding P2P having been overextended on previous adventures with DAT/hypercore: https://github.com/beakerbrowser/beaker/blob/master/archive-.... Whereas we're playing the long game to slowly converge on P2P, even if that means building our own overlay networks etc: https://github.com/matrix-org/pinecone

    I'm sure there are a bunch of other differences, but these are the ones which pop to the top of my head, plus I'm far from an expert in AT protocol.

    It's worth noting that in the early days of bluesky, the Matrix team built out Cerulean (https://matrix.org/blog/2020/12/18/introducing-cerulean) as a demonstration to the bluesky team of how you could build big-world microblogging on top of Matrix, and that Matrix is not just for chat. We demoed it to Jack and Parag, but they opted to fund something entirely new in the form of AT proto. I'm guessing that the factors that went into this were: a) wanting to be able to optimise the architecture purely for social networking (although it's ironic that ATproto has ended up pretty generic too, similar to Matrix), b) wanting to be able to control the strategy and not have to follow Matrix's open governance model, c) wanting to create something new :)

    From the Matrix side; we keep in touch with the bluesky team and wish them the best, and it's super depressing to see folks from ActivityPub and Nostr throwing their toys in this manner. It reminds me of the unpleasant behaviour we see from certain XMPP folks who resent the existence of Matrix (e.g. https://news.ycombinator.com/item?id=35874291). The reality is that the 'enemy' here, if anyone, are the centralised communication/social platforms - not other decentralisation projects. And even the centralised platforms have the option of seeing the light and becoming decentralised one day if we play our parts well.

    What would be really cool, from my perspective, would be if Matrix ended up being able to help out with the private communication use cases for AT proto - as we obviously have a tonne of prior art now for efficient & audited E2EE private comms and decentralised access control. Moreover, I /think/ the lexicon approach in AT proto could let Matrix itself be expressed as an AT proto lexicon - providing interop with existing Matrix rooms (at least semantically), and supporting existing Matrix clients/SDKs, while using AT proto's ID model and storing data in PDSes etc. Coincidentally, this matches work we've been doing on the Matrix side as part of the MIMI IETF working group to figure out how to layer Matrix on top of other existing protocols: e.g. https://datatracker.ietf.org/doc/draft-ralston-mimi-matrix-t... and https://datatracker.ietf.org/doc/draft-ralston-mimi-matrix-m... - and if I had infinite time right now I'd certainly be trying to map Matrix's CS & SS APIs onto an AT proto lexicon to see what it looks like.

    TL;DR: I think AT proto is cool, and I wish that open projects saw each other as fellow travellers rather than competitors.

matrix-synapse-shared-secret-auth

Posts with mentions or reviews of matrix-synapse-shared-secret-auth. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-05-13.
  • Mautrix-whatsapp configuration
    3 projects | /r/matrixdotorg | 13 May 2022
    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 m.direct account data event when double puppeting is enabled.    # Note that updating the m.direct 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:        example.com: https://example.com    # Allow using double puppeting from any server with a valid client .well-known file.    double_puppet_allow_discovery: false    # Shared secrets for https://github.com/devture/matrix-synapse-shared-secret-auth    #    # 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:        example.com: 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

What are some alternatives?

When comparing matrix-spec-proposals and matrix-synapse-shared-secret-auth you can also consider the following projects:

whatsapp - A Matrix-WhatsApp puppeting bridge

matrix-room-element

signal - Online MIDI Editor: signal

Synapse - Synapse: Matrix homeserver written in Python/Twisted.

signal - A Matrix-Signal puppeting bridge

element-call - Group calls powered by Matrix

nnnoiseless - Recurrent neural network for audio noise reduction

Matrix-CRDT - Use Matrix as a backend for local-first applications with the Matrix-CRDT Yjs provider.

seshat - A Matrix message database/indexer

matrix-js-sdk - Matrix Client-Server SDK for JavaScript

matrix-doc - Proposals for changes to the matrix specification [Moved to: https://github.com/matrix-org/matrix-spec-proposals]