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

What do you want to see?

There are multiple places in the API spec where an object representing a role's permissions (allowed and denied) is expressed, but I've noticed an inconsistency: Sometimes the fields are allow and deny (example: Set Role Permission), and sometimes they are a and d (example: Create Role). Could this be fixed up and unified in one way or another? It would make some API wrappers' lives easier not needing to include special JSON deserialization logic to handle the same model with differing field names, or having to include redundant model code. 😄

What happened?

There seem to be some typing issues - these are causing issues when trying to compile other projects:
https://autumn.revolt.chat/attachments/oKmI5u9BuEb7RbVOm03cVTMgdOHLhHCNcfpuUxrKlA/image.png

What do you want to see?

At the moment, Search for Messages (POST channels/{target}/search) utilizes nearly identical parameters to Fetch Messages (GET channels/{target}/messages), but the former uses a JSON request body whereas the latter uses query parameters, which in my personal opinion is a worse way to build requests especially with as many parameters as the methods allow.

Would it be possible to make both endpoints use the same request body type (specifically a JSON request body instead of query parameters) for consistency? This would obviously be a breaking change for clients and API wrappers which depend on this functionality, but I think it would be better to get that over with sooner rather than later.

It would be a great idea to create one more property in the User interface, where it returns a Boolean value to check if the user is a bot.

export interface User {
    isBot: Boolean;
}

So it would be simpler to identify the user type directly by the revolt.js bookstore.

My Revolt Profile: TiaGoiNsaNy

Limit KaTeX, tables, headings behind feature flag for channels.

The other status codes aren't documented, which can be there in case a request fails, like if we try to send a message to a channel where we don't have permissions.

revoltchat/backend#102

For example, to prevent moderators from being blocked by users who are trying to ignore them / being disruptive.

Alternatively, this could be applied to only people with platform moderation powers.

When the package is installed there is only one index.js file left in the dist folder with no type files and no other files in the dist folder.

As currently seen:

As it should look:

What happened?

https://api.revolt.chat/users/{target} doesnt return the users background banner, only your own (the token used to make the api request).

Solution (but still bad):

make ANOTHER request to https://api.revolt.chat/users/{target}/profile and get the background there.

**pls use the method used in the https://api.revolt.chat/users/{target}/profile route and integrate it into https://api.revolt.chat/users/{target} if possible. **

What happened?

So apparently the focus presence isn't defined in the api.patch function, returning a typeerror since it doesn't match "Online" | "Idle" | "Busy" | "Invisible" | undefined | null.

But when testing, It does indeed change the status to Focus.

What happened?

On this page:
https://developers.revolt.chat/api/#tag/Session/operation/login_login

On the first request sample, where it shows what to do to fufil mfa as copied here:

{
  "mfa_ticket": "string",
  "mfa_response": {
    "password": "string"
  },
  "friendly_name": "string"
}

It'd throw error code 400 (Bad Request)

Turns out when inspecting network traffic from Revite, where it'd say password, it actually uses a field named "totp_code", which did work as intended and generated a new login session.