Matrix-spec-proposals Alternatives

matrix-spec-proposals reviews and mentions

• Losing Signal
  3 projects | news.ycombinator.com | 13 Mar 2023

  I assume you’re talking about https://github.com/matrix-org/matrix-spec-proposals/pull/254.... There is nobody from the spec core team or for that matter the matrix core team on that thread; Sorunome, deepbluev7 and Cadair are community contributors. You can spot the folks who actually are project members (ie core team) by the “member” label next to their names in Github. It is unlikely that the MSC will pass review (when we finally get to it) unless it’s e2ee… unless MSC3414 automatically handles it.

  3 projects | news.ycombinator.com | 13 Mar 2023

  I'll give you a pass for state events but sticker packs are still going through MSC and it seems that people on the team are happy to add E2EE later?

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

  Or is that out of date and there is a new proposal with encryption?

• Purple-Teams: MS Teams Plugin for Pidgin
  5 projects | news.ycombinator.com | 5 Mar 2023

  There is a spec change proposal for fixing this: https://github.com/matrix-org/matrix-spec-proposals/pull/253...

• Matrix 2.0: How we’re making Matrix go voom
  28 projects | news.ycombinator.com | 13 Feb 2023

  The Matrix team spent 15 years building SIP stacks before we gave up and created Matrix, so I can answer this with some confidence:

  Superficially, Matrix looks a bit like SIP: for 1:1 calls, you send an m.call.invite (like a SIP INVITE) to someone; they answer with an m.call.answer (like a SIP 200 OK); eventually someone hangs up with an m.call.hangup (like a SIP BYE). However, the differences are:

  * As a transport, everything goes over normal Matrix signalling (by default HTTPS+JSON) rather than SIP's mix of UDP and TLS sockets. As a result, no need for SIP's three-way handshakes inherited from its UDP transport

  * As a result, you inherit Matrix's end-to-end-encryption and decentralisation for free (so no special Routes, Vias, Record-Routes, branch parameters etc from SIP - it uses the Matrix client-server and server-server APIs over HTTPS instead)

  * Everything is trickle ICE by default for rapid call setup, no need to gather candidates

  * Matrix piggybacks on WebRTC for its media protocol, so you don't have the fragmentation of different media transports that SIP has inherited

  * Matrix (as of https://github.com/matrix-org/matrix-spec-proposals/blob/mat...) now supports multiparty native VoIP calls in the same conversation: effectively letting you signal full-mesh, SFU and MCU style multiway video/voip using the same mechanism as you'd use for a 1:1 call. This is probably the biggest difference in the end: with Matrix's VoIP you can jump straight in and have interoperable Zoom/Teams/Jitsi style conferences (as shown in the OP at https://youtu.be/eUPJ9zFV5IE?t=1513) - Matrix isn't just for boring old PSTN/PBX-style 1:1 calls, but for the conferences folks actually expect to use today.

  You can play with it at https://call.element.io, and if you really want to compare with SIP, go to the developer tools in options and turn on callflow mode, which will draw little mermaid sequence diagrams of the call signalling for the calls, so you can see precisely what's going on :)

• The Matrix Holiday Update 2022: "We are witnessing a classic tragedy of the commons."
  3 projects | reddit.com/r/programming | 28 Dec 2022
• This Year in Matrix
  6 projects | news.ycombinator.com | 25 Dec 2022

  Disappearing messages are due to land this coming year - https://github.com/matrix-org/matrix-spec-proposals/blob/mat... is the spec for it.

  For metadata protection, we're relying on P2P Matrix (https://arewep2pyet.com) - as if there are no servers (or if the servers are dumb store & forward servers like Signal's) then there's very little metadata. And yes, S&F servers could replicate sealed sender - or even rattle through a mixnet to provide proper traffic analysis resistance (so better than Signal :)

  6 projects | news.ycombinator.com | 25 Dec 2022

  > Have you guys considered changing the licensing to require larger organizations to contribute financially to the protocol?

  Yes, but the concern is that this would chill Matrix network growth - e.g. larger orgs currently building on Matrix would feel victim of a rug-pull or a bait & switch. Whereas Matrix's success depends on it spreading as far and wide as possible... while somehow preventing a tragedy of the commons. We haven't ruled this out, though, if other attempts at funding fail.

  > There's an idea out in the ether of solving spam by allowing users to set a bounty to send them a message, which is returned to the sender if the user accepts the message as non-spam.

  This is an interesting one. We've always aimed to avoid Matrix being pay-to-play (e.g. eschewing tokenisation schemes). Instead, the angle we've taken has been to let users publish and subscribe to reputation feeds (a bit like email DNSBLs, but more transparent and less of a shakedown) in order to empower users to block stuff they don't want to see. But perhaps one could combine the two ideas: you could have a personal rep list which users pay to be on, and you get the payment if they turn out to be spammers - similar to systems like https://www.bbc.com/worklife/article/20181023-people-pay-20-.... Much like email, i'm not sure these semantics should be baked into the protocol itself. (But the infrastructure to support it could be - thus MSC2313: https://github.com/matrix-org/matrix-spec-proposals/blob/msc...)

  6 projects | news.ycombinator.com | 25 Dec 2022

  > larger orgs currently building on Matrix would feel victim of a rug-pull or a bait & switch

  Fair. The bait and switch could be avoided by grandfathering in current orgs. A more hands-off, related idea is that you could come up with an unenforced, suggested payment. Essentially consider what an ideal economically sustainable licensing system would look like, and publish that as a suggested donation.

  > We've always aimed to avoid Matrix being pay-to-play (e.g. eschewing tokenisation schemes).

  I agree with eschewing pay-to-play or plopping some half-assed crypto grift on top (or what some would call a "tokenization scheme"). I would dispute characterizing my suggestion as pay-to-play, as payment wouldn't be required to use the system. It should be totally up to the user how much to set their bounty at, including zero if they're willing to accept the greater amount of spam (or wish to use some other spam filtering method). The idea here isn't for anybody to make any money off of getting messages (the money would just be returned if the receiver accepted the message as non-spam), it's just to make large scale spammers lose money.

  > Instead, the angle we've taken has been to let users publish and subscribe to reputation feeds (a bit like email DNSBLs, but more transparent and less of a shakedown) in order to empower users to block stuff they don't want to see.

  That makes sense as a feature generally, although I think its solving for a different sort of problem. The blocklist seems like it would work best for allowing users to cultivate a particular culture (i.e. subscribe to a blocklist for those who use excessive profanity, or talk about certain undesired topics, etc.). But a "Nigerian prince" style spammer can make new accounts and blast out messages faster than you can identify and add them to a blocklist. However if it on-average costs that spammer $2 per message that they're unlikely to get back, it suddenly becomes prohibitively expensive to engage in that type of behavior.

  > But perhaps one could combine the two ideas: you could have a personal rep list which users pay to be on, and you get the payment if they turn out to be spammers - similar to systems like https://www.bbc.com/worklife/article/20181023-people-pay-20-....

  Hmm, that's an interesting modification. I'll need to chew more on the incentives. I would say the approach in that article is closer to my original suggestion, except instead of the money actually going to charity it would just go back to the sender once the author replied to their message.

  > Much like email, i'm not sure these semantics should be baked into the protocol itself. (But the infrastructure to support it could be - thus MSC2313: https://github.com/matrix-org/matrix-spec-proposals/blob/msc...)

  When I look at that proposal, it seems to me like it's "baked into the protocol itself" insofar as its proposing how to use existing room primitives (namely state events) to implement the concept.

• BundesMessenger is a milestone in Germany’s ground-breaking vision
  3 projects | news.ycombinator.com | 16 Dec 2022

  Gematik co-funded the most recent Matrix audit of vodozemac[1], and is poised to fund 3 more (of matrix-rust-sdk-crypto, matrix-rust-sdk and the whole stack end-to-end) to ensure the E2EE is where it needs to be. So I'd say that the German government definitely cares about E2EE for its civil servants, and we're very grateful for them funding security research.

  Meanwhile, BWI is helping fund the work needed to address clientside controlled room membership (https://github.com/matrix-org/matrix-spec-proposals/pull/391...) as highlighted in your paper, as well as TOFU... and they're also funding work to provide MLS as an option for E2EE in Matrix too[2].

  Unsure why you're talking about the unexploitable IND-CCA break :)

  [1] https://matrix.org/blog/2022/05/16/independent-public-audit-...

  [2] https://www.golem.de/news/bwmessenger-vom-messenger-der-bund...

• Practically-Exploitable Cryptographic Vulnerabilities in Matrix
  2 projects | news.ycombinator.com | 10 Dec 2022

  We (the matrix team) addressed the implementation vulnerabilities discussed here back in September: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-en....

  The only pending work is switching to TOFU (trust on first use) and client-controlled room membership. Currently users get warned if a malicious device or user gets added to a room by a malicious server (assuming users in the room are verified). However, rather than warning, we could block it outright - but this is nontrivial as it means clients have to independently replicate the group membership semantics the server currently handles, which are complicated in a decentralised environment.

  https://github.com/matrix-org/matrix-spec-proposals/blob/fay... is the work ongoing to shift membership to be controlled clientside, and https://github.com/matrix-org/matrix-spec-proposals/blob/fay... is the work ongoing to shift to TOFU.

  Meanwhile, this work is blocked behind switching to matrix-rust-sdk-crypto across Element on Web, iOS and Android, so we only fix this in one (audited) place - and can also build on the newly audited vodozemac implementation of Matrix’s encryption: https://matrix.org/blog/2022/05/16/independent-public-audit-...

• A note from our sponsor - #<SponsorshipServiceOld:0x00007f160cb7de90>
  www.saashub.com | 26 Mar 2023

  SaaSHub helps you find the best software and product alternatives Learn more →