Custom message routing #23
Description
What do you want to see?
This could be useful for cross-posting and IoT-related use cases. Custom route management should be permissions-gated to prevent spamming by randomly creating message routes.
The semantics should be as follows: server-wide permissions allow you to create, alter and drop a message route targeting any channel, while per-guild permission only allows you to do so while requiring you to have either:
- Posting, storage, view all within that guild
- Posting channel is null (meaning that route is read-only) and view channel is within that guild, no constraints on storage channel
Routing rule
A routing rule shall consist of eight elements:
- Timestamp of the registration (stored as snowflake)
- Source channel
- Storage channel
- Sink channel
- Source users (user, group or role ID)
- Target users (user, group or role ID)
- Valid since timestamp
- Valid until timestamp
Invariants
- Valid since cannot be earlier than time of registration
- Valid until cannot be earlier than valid since
- Source user set has to have message posting permission in the source channel at the time of use
- Event type validity checks are done based on the storage channel
- Target user set has to have read messages permission in the source channel at the time of use
- Each routing rule is considered immutable once created, except for valid until timestamp, which can be set to any future time while the routing rule is still in effect
A routing rule can only be deleted in either of the following cases:
- none of the source channels are present
- none of the storage channels are present
- none of the sink channels are present
- the routing rule is not in effect AND no messages are affected by deletion of the routing rule