Eludris 0.4 roadmap

ROADMAP.md

Eludris v0.4 roadmap

Features

• Accounts (auth (:D))
• Permissions
• Communities
  • Message communities
    • Channels
  • Post communities
• Roles
• DMs & GDMs
• Embed service & media proxy
• Embeds and message attachments
• Emojis
• Bots
• Voice & Screenshare

Details

Accounts

# VARCHAR(40) is used to represent an ID in most cases.
CREATE TABLE IF NOT EXISTS users (
    id VARCHAR(40) NOT NULL,
    username VARCHAR(32) NOT NULL,
    display_name VARCHAR(32),
    social_credit INT NOT NULL DEFAULT 0, # All hail Xi Jinping
    email VARCHAR(256) NOT NULL,
    password VARCHAR(256) NOT NULL,
    salt VARCHAR(32) NOT NULL,
    status VARCHAR(256),
    avatar VARCHAR(40),
    banner VARCHAR(40),
    badges INTEGER NOT NULL DEFAULT 0, # bitfield
    verified BOOLEAN NOT NULL DEFAULT FALSE,
    permissions INTEGER NOT NULL DEFAULT 0, # bitfield
    pubkey VARCHAR(9999) NOT NULL,
    two_factor_auth VARCHAR(16),
    PRIMARY KEY (id)
);

Authentication

1. You make an account /signup You will supply details such as your username (which is different from your display name), email, password and public key.
2. You will log into a session using /login Here you'll provide info about your client and will gain a token in return - which is to be used by your client for this sesssion - in addition to a session ID.

Eludris tokens are JWTs, the payloads will include the client ID as well as the session ID.

The verify signature secret will be a cryptographically secure random string which is stored in a HashiCorp. Vault instance.

When a token is used we can easily get the user and instance IDs and verify the signature secret.

IDs

A Eludris ID is a 128 bit (16 byte) number, structured like so:

 12345678  12345678  12345678  12345678  12345678  12345678  12345678  12345678  12345678  12345678  12345678  12345678  12345678  12345678  12345678  12345678
 TTTTTTTT  TTTTTTTT  TTTTTTTT  TTTTTTTT  TTTTTTTT  TTTTTTTT  TTTTTTTT  TTTTTTTT  IIIIIIII  IIIIIIII  IIIIIIII  IIIIIIII  IIIIIIII  IIIIIIII  SSSSSSSS  SSSSSSSS
╰──────────────────────────────────────────────────────────────────────────────╯╰──────────────────────────────────────────────────────────╯╰──────────────────╯
                                       │                                                                     │                                       │
                                       │                                                                     │                          16 bit (2 byte) sequence.
                                       │                                                       48 bits (6 byte) Instance ID.
                        64 bit (8 byte) Unix timestamp.

• T: A Unix timestamp with the Eludris epoch (1,650,000,000)─.
• I: The id of the instance that generated this ID.
• S: The sequence number of this ID

An instance ID is a 48 bit (6 byte) number, structured like so:

 12345678  12345678  12345678  12345678  12345678  12345678  12345678 12345678
 TTTTTTTT  TTTTTTTT  TTTTTTTT  TTTTTTTT  TTTTTTTT  TTTTTTTT  TTTTTTTT TTTTTTTT
╰─────────────────────────────────────────────────────────────────────────────╯
                                       │
                                       │
                        48 bit (6 byte) Unix timestamp.

• T: 48 bits of the current Unix timestamp (also with the Eludris) epoch.

Since it is 128 bit, this is represented as a strings in both the database and API. This is due to there being no 128 bit type in MariaDB and languages such as JavaScript not being able to parse large numbers well.

Permissions

A standard permission object will be composed of two bitfields, one for allowed permissions and another for denied ones.

{
    "a": 1393, // 0b10111010101
    "d": 522,  // 0b01000001010
}

The order of permissions being applied is as follows:

• Owner status
• Channel overrides
• Role permissions (from highest order to lowest)

The procedure for applying allowed and denied permissions would be as follows:

1. Current permission is 0
2. Apply denied fields
3. Apply allowed fields
4. Repeat 2-3 for all objects

Here is a 'pseudocode' example

role_1_allow  = 0b00100110
role_1_deny   = 0b01000001
role_2_allow  = 0b00010000
role_2_deny   = 0b01100000
channel_allow = 0b01000011
channel_deny  = 0b00100100

permissions = 0

permissions &= ~role_1_deny
permissions |= role_1_allow  # 0b00100110

permissions &= ~role_2_deny
permissions |= role_2_allow  # 0b00010110

permissions &= ~channel_deny
permissions |= channel_allow # 0b01010011

Communities

A community can be either a messaging community or a post community.

This has already been explained in Eludris Detailed

Embed service and media proxy

Proxy

Effis will have a /proxy?<url> route which requests the page for you and returns the received data.

Embeds

Effis will also have an /embed?<url> route which fetches a page then constructs an embed.

There are quite a few types of embeds, some of them include:

• Media embeds such as videos, images and gifs
• Special embeds for stuff like YouTube, Spotify, Twitch.
• Website embeds which are obtained by scraping the page's meta tags.

IDs suck