Capability to create channels with custom message routing rules

[erkinalp]

We could create channels in that that different people have different views of channels, i.e. not everyone receives all messages.

[erkinalp]

Fun things that could be done with custom message routing:

• channels that are write only to a particular user and that particular user not seeing any other user's messages, while all other users seeing that user's messages
• cross-channel whispers
• cross-guild whispers
• one-to-many channels
• many-to-one channels
• merged channel views

There would be a few parameters in custom message route:
posting channel, storage channel, view channels, posting user, viewing user
Sending-wise, it'd look up at posting channel's permission, but retrievals would work with the view channel's permission from the storage channel of the route.
A normal guild channel would just be a @self @self @self @everyone @everyone route (pseudocode, actual representation not yet decided), and a normal voice channel would be a @self @self @self $connected $connected route.

[SamuelScheit]

Bots could use this, optionally combined with ephemeral messages, to send "direct messages" to users inside a guild channel

[erkinalp]

@SamuelScheit mentioned that we should gate this behind a permission flag, and he is right. Messing up with routes would mean drastic failures.

We should create an instance-wide permission, MANAGE_ROUTING, and a guild permission with the same name.
The semantics are 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 (stored as snowflake)
• Valid until timestamp (stored as snowflake)

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