[ibeckermayer]

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) 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), Unreal is another model (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]

> 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...)

[ibeckermayer]

> 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.