Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
> 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.
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...
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/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 :)
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...
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/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 :)
Nheko has been around for a number of years. Never used it myself though.
https://github.com/Nheko-Reborn/nheko