Conversation
turt2live
added
proposal
| must be given in order to send messages, which avoid polluting power levels (promoting a user from -1 to 0 | ||
| would mean a potentially lengthy list of users in a power levels event). | ||
|
|
||
| A consideration for that future MSC is whether restricting users in this way is effective: unlike Discord, |
There was a problem hiding this comment.
I would like to point out that this section is not correct. If we assume that we are doing this for anti spam we have to throw out any idea of that the user is not willing to violate the ToS out of the window. A client mod can automatically accept this check and so can a spam bot. Screen scraping if you want to be extremely primitive in your attack can do this or plain old AHK macros.
Yes for matrix due to having a fully open API and a complete expectation of third party clients we are more vulnerable to this as an attack method but well Discord is very vulnerable too. Its actually more effective as an anti spam method to lock your guild behind a react check done correctly than using the built in check if your attackers are just going in blind. If your being targeted specifically then well the checks have to be more complicated.
Point with all this is that No. This feature does not provide a proper barier to serious spammers on discord other than maby slowing them down a bit but that would be it. The section about matrix is something i do agree about since it makes it clear we cant trust this to protect us.
There was a problem hiding this comment.
Discord is less vulnerable than Matrix in this respect, as Discord does consider this an anti-spam barrier. This section is not implying it solves spam, just that it might not be valued high enough to be worth considering an anti-spam measure in Matrix.
There was a problem hiding this comment.
My point is that Discord is simply wrong in considering this an anti spam barrier unless they are doing Server side magic to use this as a signal to determine if their anti spam system should kick in and sanction the user.
|
|
||
| There's a thousand different ways to represent a README/welcome/rules/topic message - Extensible Events | ||
| seems the most reasonable given it solves this sort of problem and re-uses the message rendering functions | ||
| clients would already have. |
There was a problem hiding this comment.
Another method that reuses normal message rendering is pinned messages, which many clients already use, but Element can't display (by default).
There was a problem hiding this comment.
Pinned messages have a different use-case than welcome messages.
3 participants
Rendered