3 ms·

Author here in case anyone has any questions :)

bilal4hmed 4y ago
I havent been keeping tabs on the project in some time but are yall working on implementing disappearing messages, sealed sender or even some of the meta data issue such as admins being able to see group membership ?
- Arathorn 4y ago
  Disappearing messages are due to land this coming year - https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/msc2228/proposals/2228-self-destructing-events.md 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 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 :)
  - bilal4hmed 4y ago
    Oh this is fantastic news:) Thank you so much for the excellent work yall do
ibeckermayer 4y ago
Thanks Matthew, great write up. I have a couple of questions/comments 1) Have you guys considered changing the licensing to require larger organizations to contribute financially to the protocol? Permissive open source licensing is great for allowing small upstarts (i.e. individuals like me) to build off of and contribute to development without institutional scale funding. However the virtues of the system become hazy when organizations with gigantic budgets come into the fold and begin essentially parasitizing off your work, despite clearly having the resources to contribute. I'd like to live in a culture where sound moral and economic judgement ruled the day, however based on my experience with the current open source company that I work for (https://goteleport.com https://goteleport.com) and the similar experience detailed in your funding post, it seems that we simply don't live in such a world. IMO the Open Source world should be considering moving to a Source Available model which looks to maintain the innovation/security benefits of Open Source, while experimenting with a greater variety of license enforced models such that larger players are required to contribute financially. Juce is one example of a project that works something like what I'm imagining (https://juce.com/get-juce https://juce.com/get-juce), Unreal is another model (https://www.unrealengine.com/en-US/faq https://www.unrealengine.com/en-US/faq). 2) As Matrix grows, it seems inevitable that it will fall victim to the spam problems well known with email. My current understanding is that this spam problem is essentially what's pushed email into becoming a de facto centralized protocol wherein its extremely difficult/impractical for independent operators to enter the ecosystem (without large scale financial backing) -- Big co's have developed a notoriously finicky and unaccountable IP-based reputation system which often causes opaque deliverability issues for individuals who try to run their own servers, resulting in many just throwing in the towel and going with a big email provider that can guarantee high-reputation IPs. Based on the Matrix Foundation's stated values, I wouldn't imagine you guys intentionally using the popularity of the matrix.org homeserver to build a similar sort of system, however since Matrix represents a relative clean slate to address this problem in a way that needn't rely so centrally on trust in a single organization, I'm curious on your thoughts on the following: 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. So for example, I could set my personal bounty at $2, and if anybody not in my contact list wants to send me a message, they need to include $2. When I accept the message, that $2 goes back to them, but if I don't then I keep it. That way it becomes prohibitively expensive for spammers and scammers to engage in non-targeted spam/scam campaigns, while still keeping it relatively cheap for individuals to i.e. send a message to a public figure they don't know, and free to message a new friend who they're sure will return the bounty.
- Arathorn 4y ago
  > 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-to-email-me 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/msc2313/proposals/2313-moderation-policy-rooms.md https://github.com/matrix-org/matrix-spec-proposals/blob/msc...)
  - ibeckermayer 4y ago
    > 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- 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 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.
gaganyaan 4y ago
Is there going to be more muscle put into polishing up the various bridges? Matrix has an amazing opportunity to be the glue protocol between various communication silos, but there's a few things I've encountered that have been preventing me from using it further. One issue I hit is this: https://github.com/matrix-org/matrix-appservice-slack/issues/627 https://github.com/matrix-org/matrix-appservice-slack/issues... I tried pinging the people that were committing to the repo on the matrix channel for that bridge, but never got a response and now I'm just stuck with a room with a dead bridge. It's not a huge deal since the Matrix side of things still works, but having some way to reach out for stuff like that would be really helpful. The other thing is this issue: https://github.com/matrix-org/matrix-appservice-discord/issues/738 https://github.com/matrix-org/matrix-appservice-discord/issu... It's not a showstopper since the bridge still works, but it's a lot of management to sync all of the rooms initially, and keep them in sync with any changes. I'm going to wait before that's implemented before suggesting that we try bridging Discord and Matrix for my friend group that's stuck on Discord. Hopefully this doesn't come across as negative, I still use and love Matrix myself. All I want for Christmas though is to have one communication app in my life that talks to everyone everywhere effortlessly :)
- distantsounds 4y ago
  there's no money to be made in interoperability. did you RTFM? they clearly state they are not getting support on the core services while third parties just build out bridges where they see it beneficial to them.
- Arathorn 4y ago
  The problem with maintaining bridges is that there are loads of them, and by definition they are a moving target to track the destination systems. So while there's a three person full-time bridge team, they don't have bandwidth to jump on each and every bug as it comes in - and supplying more muscle there is not going to happen unless the funding issues mentioned in the blog post get resolved. So either the wider open source community will need to step up to contribute fixes, or the bugs will get resolved when they get to the top of the todo list. All I want for Christmas is to figure out a way to locate more $ to more people to work fulltime on stuff like the bridge backlog! P.S. I think the sibling reply has this wrong: there absolutely is money to be made in interoperability, including bridging. However, there's no incentive for that money to flow back to the upstream project, other than long-term thinking or good will.

I havent been keeping tabs on the project in some time but are yall working on implementing disappearing messages, sealed sender or even some of the meta data issue such as admins being able to see group membership ?

Arathorn 4y ago
Disappearing messages are due to land this coming year - https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/msc2228/proposals/2228-self-destructing-events.md 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 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 :)
- bilal4hmed 4y ago
  Oh this is fantastic news:) Thank you so much for the excellent work yall do

ibeckermayer 4y ago

Thanks Matthew, great write up. I have a couple of questions/comments 1) Have you guys considered changing the licensing to require larger organizations to contribute financially to the protocol? Permissive open source licensing is great for allowing small upstarts (i.e. individuals like me) to build off of and contribute to development without institutional scale funding. However the virtues of the system become hazy when organizations with gigantic budgets come into the fold and begin essentially parasitizing off your work, despite clearly having the resources to contribute. I'd like to live in a culture where sound moral and economic judgement ruled the day, however based on my experience with the current open source company that I work for (https://goteleport.com https://goteleport.com) and the similar experience detailed in your funding post, it seems that we simply don't live in such a world. IMO the Open Source world should be considering moving to a Source Available model which looks to maintain the innovation/security benefits of Open Source, while experimenting with a greater variety of license enforced models such that larger players are required to contribute financially. Juce is one example of a project that works something like what I'm imagining (https://juce.com/get-juce https://juce.com/get-juce), Unreal is another model (https://www.unrealengine.com/en-US/faq https://www.unrealengine.com/en-US/faq). 2) As Matrix grows, it seems inevitable that it will fall victim to the spam problems well known with email. My current understanding is that this spam problem is essentially what's pushed email into becoming a de facto centralized protocol wherein its extremely difficult/impractical for independent operators to enter the ecosystem (without large scale financial backing) -- Big co's have developed a notoriously finicky and unaccountable IP-based reputation system which often causes opaque deliverability issues for individuals who try to run their own servers, resulting in many just throwing in the towel and going with a big email provider that can guarantee high-reputation IPs. Based on the Matrix Foundation's stated values, I wouldn't imagine you guys intentionally using the popularity of the matrix.org homeserver to build a similar sort of system, however since Matrix represents a relative clean slate to address this problem in a way that needn't rely so centrally on trust in a single organization, I'm curious on your thoughts on the following: 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. So for example, I could set my personal bounty at $2, and if anybody not in my contact list wants to send me a message, they need to include $2. When I accept the message, that $2 goes back to them, but if I don't then I keep it. That way it becomes prohibitively expensive for spammers and scammers to engage in non-targeted spam/scam campaigns, while still keeping it relatively cheap for individuals to i.e. send a message to a public figure they don't know, and free to message a new friend who they're sure will return the bounty.

Arathorn 4y ago
> 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-to-email-me 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/msc2313/proposals/2313-moderation-policy-rooms.md https://github.com/matrix-org/matrix-spec-proposals/blob/msc...)
- ibeckermayer 4y ago
  > 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- 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 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.

gaganyaan 4y ago

Is there going to be more muscle put into polishing up the various bridges? Matrix has an amazing opportunity to be the glue protocol between various communication silos, but there's a few things I've encountered that have been preventing me from using it further. One issue I hit is this: https://github.com/matrix-org/matrix-appservice-slack/issues/627 https://github.com/matrix-org/matrix-appservice-slack/issues... I tried pinging the people that were committing to the repo on the matrix channel for that bridge, but never got a response and now I'm just stuck with a room with a dead bridge. It's not a huge deal since the Matrix side of things still works, but having some way to reach out for stuff like that would be really helpful. The other thing is this issue: https://github.com/matrix-org/matrix-appservice-discord/issues/738 https://github.com/matrix-org/matrix-appservice-discord/issu... It's not a showstopper since the bridge still works, but it's a lot of management to sync all of the rooms initially, and keep them in sync with any changes. I'm going to wait before that's implemented before suggesting that we try bridging Discord and Matrix for my friend group that's stuck on Discord. Hopefully this doesn't come across as negative, I still use and love Matrix myself. All I want for Christmas though is to have one communication app in my life that talks to everyone everywhere effortlessly :)

distantsounds 4y ago
there's no money to be made in interoperability. did you RTFM? they clearly state they are not getting support on the core services while third parties just build out bridges where they see it beneficial to them.
Arathorn 4y ago
The problem with maintaining bridges is that there are loads of them, and by definition they are a moving target to track the destination systems. So while there's a three person full-time bridge team, they don't have bandwidth to jump on each and every bug as it comes in - and supplying more muscle there is not going to happen unless the funding issues mentioned in the blog post get resolved. So either the wider open source community will need to step up to contribute fixes, or the bugs will get resolved when they get to the top of the todo list. All I want for Christmas is to figure out a way to locate more $ to more people to work fulltime on stuff like the bridge backlog! P.S. I think the sibling reply has this wrong: there absolutely is money to be made in interoperability, including bridging. However, there's no incentive for that money to flow back to the upstream project, other than long-term thinking or good will.