Role and Everyone Mentions

[NinekoTheCat]

No description provided.

[AlbertMarashi]

Looks good to me in terms of usage

[Zomatree]

The reference level explanation should go into detail on the actual implementation of it, including changes to routes, any new routes and changes to how the events will be sent to users.

It should have enough detail to be able to implement the feature with only the RFC.

[NinekoTheCat]

The reference level explanation should go into detail on the actual implementation of it, including changes to routes, any new routes and changes to how the events will be sent to users.

It should have enough detail to be able to implement the feature with only the RFC.

@Zomatree not necessarily. The RFC is for a feature and the implementation is up to the developer. the reference level explanation goes over how it'd look on the bridge between backend and frontend but that's due to the fact they need to work together. any implementation on the backend or frontend side only needs to guarantee that a mention will be treated as a mention

[Zomatree]

The RFC must go into detail on how it will be implemented.

[NinekoTheCat]

The RFC must go into detail on how it will be implemented.

@Zomatree
I might as-well implement it if I go into that much detail.

[insertish]

It's much harder to discuss already written code, the RFC should present and discuss high level implementation and behaviour.
For example, in the case of mentions, how should events be fanned out? What are the advantages and disadvantages of different ways we could approach this, such as managing a queue in database, managing a queue in-memory, how the algorithm scale, etc.

[NinekoTheCat]

It's much harder to discuss already written code, the RFC should present and discuss high level implementation and behaviour. For example, in the case of mentions, how should events be fanned out? What are the advantages and disadvantages of different ways we could approach this, such as managing a queue in database, managing a queue in-memory, how the algorithm scale, etc.

@insertish I'm sorry but this is my first RFC however I do discuss somewhat different solutions in the RFC itself? I do not quite know what you mean, sorry.

[insertish]

I'm specifically talking about how the server needs to handle bulk mentions, part of adding them is figuring out how the server can send push notifications efficiently.

Permissions values should also be proposed since this is relevant to everyone that implements the RFC.

[NinekoTheCat]

I'll edit the RFC and mention that thank you
@insertish

[NinekoTheCat]

I edited the RFC to mention the potential implementation

[nulldg]

i don't like opt-out @everyone pings, but i do support role pings. i think role pings are sufficient to satisfy both functions, particularly if roles can be self-assigned.

[NinekoTheCat]

Added suggestion from @JackDotJS

[NinekoTheCat]

?

[NinekoTheCat]

well I said why the idea in my opinion isn't suited for development right now??

[NinekoTheCat]

I don't follow @nulldg

[NinekoTheCat]

@nulldg I'd like to talk in dms about this so if you are in the Revolt Lounge send @klepsi a friend request and we'll talk

[Rexogamer]

For the sake of other readers, can y'all refrain from randomly deleting your comments? It makes the conversation incredibly hard to follow.

[sharkaccino]

i wonder if it'd also make sense to have some kind of rate limit on mass pings. not only could this help reduce server load, but it could also reduce spam and annoyance in general. ideally, it'd be something server owners could control, similar to slowmode on discord.

[NinekoTheCat]

i wonder if it'd also make sense to have some kind of rate limit on mass pings. not only could this help reduce server load, but it could also reduce spam and annoyance in general. ideally, it'd be something server owners could control, similar to slowmode on discord.

so you're proposing like a configurable per role limit on mentions?

[sharkaccino]

i was thinking more of a server-wide rate limit, but per-role and maybe even per-channel would be nice for more precise control.

[sharkaccino]

in fact, a rate limit on pings in general might be quite nice as an anti-spam measure... making it exclusively for role/everyone pings might just encourage spammers to use individual pings (which is also a problem over on Discord)

[NinekoTheCat]

this RFC only covers role and everyone pings so please concider it within that boundry, while I do agree a limit should be applied to pings, should it be set by server admins or be enabled by default in the first place?

[sharkaccino]

yeah the rate limit idea could probably use its own RFC.

in this context though, i'd probably have it enabled by default, but with a high limit. it'd provide some kind of anti-spam, but a very mild one (which would likely be enough for most people)

[NinekoTheCat]

like 10 mentions per minute?

[sharkaccino]

maybe more like 5
realistically, who needs more than that?

[NinekoTheCat]

5 it is I'll edit the rfc

[sharkaccino]

the only other concern i can think of right now is how mass pings would be handled on larger servers.
like, surely at some point you'd be fetching so many people from the database, you might just end up running out of memory, right? or at the very least, slowing the entire service down to a crawl.

[NinekoTheCat]

we can have pings be acknowliged the same way messages are

[xXBuilderBXx]

the only other concern i can think of right now is how mass pings would be handled on larger servers. like, surely at some point you'd be fetching so many people from the database, you might just end up running out of memory, right? or at the very least, slowing the entire service down to a crawl.

Not really because you only need the ID of the user to actually ping (or selected role of user for role mentions) and not the entire data, also it could queue up the mentions.

[NinekoTheCat]

the only other concern i can think of right now is how mass pings would be handled on larger servers. like, surely at some point you'd be fetching so many people from the database, you might just end up running out of memory, right? or at the very least, slowing the entire service down to a crawl.

Not really because you only need the ID of the user to actually ping (or selected role of user for role mentions) and not the entire data, also it could queue up the mentions.

defer means queue, that's what I suggested I think

[rethyria]

Users should always have full control of how they are being contacted and notified. This is where I think Discord fails on this topic.

While default notification settings for a server can be set by a server admin, there is no default option for a user. This means the user needs to adjust settings for every server they join - which can be hundreds.

Default notification settings should be configurable by the user so that they can adjust notifications for every server by default. Settings could then be configured per server or channel on a case-by-case basis by the user.

A few other points:

• If role/everyone pings will be disabled automatically once certain conditions are met, the server admin should be notified when this happens
• Should there be any consideration for an '@'here ping?
• Should the role/everyone/here be case-sensitive or case-insensitive? Imo, the search should at least be case-insensitive
• Regarding this small server 50 people business, is it worth considering some sort of actual rules and terminology to classify server types (e.g. Personal and Community) and use this classification instead?
• There is currently no 'inbox' in Revolt so it is difficult to find mentions from some time ago, especially on active servers or if you were offline at the time of the ping
  • An inbox is a bit beyond the scope of this change but worth considering as a next step

[SpamixOfficial]

I think @EnigmaEmmy's points are good suggestions.

[Andre601]

Joining in late to give my two cents to this topic.
Generally, I'm fine with the idea of implemention everyone and role mentions, but I also would like to propose the following adjustments:

• Make role and everyone mentions off by default, no matter the server size. This is something I consider a generally bad habit of Discord, where the everyone mention is enabled by default... for the everyone role no less, meaning everyone can tag everyone, allowing chaos to be created from this.
  • In case of permissions, I would say that role mention and everyone mention perms would be made separately, as there can be cases where you want people to be able to tag roles, but not everyone. This is a major flaw in Discord's design of permissions imo that Revolt should avoid. Also, taggable roles should be tetermined by a role setting to enable or disable this. This would allow greater freedom of what roles one should be able to tag.
• The suggested syntax is confusing and overall just bad to have. It would be especially weird for people switching from Discord, who may be more familiar with their syntax, which is <@&<id>> for roles and @everyone for everyone mentions. A similar syntax should be used here. It wouldn't conflict with the ID system of Revolt as the ULID doesn't seem to use special characters such as ampersand, allowing easy detection of specific mention types. A <*:@> would just look weird in the client, especially given it doesn't render mentions at all.
• I suggest the addition of a @Active mention. This would be the same as @Here on discord, tagging people in a channel that are currently online. However, the name would it make it somewhat more clear of who it would tag: People that are "active".
  • Additionally can/should it be considered what users should be tagged, based on their status. A status like "focused" should perhaps be completely excluded from any mention to not disrupt their current work they may have.

As a final note would I also like to suggest considering the implementation of silent/supressed mentions similar to the @silent feature offered by Discord, to allow mentioning people but not giving them actual notifications.
Tho, I believe this should be its own RFC. If agreed, I can work out one to then discuss over.