---
# System prepended metadata

title: Eludris v0.4 roadmap

---

# 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

```sql
# 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](https://jwt.io/), 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](https://www.hashicorp.com/products/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](https://en.wikipedia.org/wiki/Bit_field), one for allowed permissions and another for denied ones.

```json
{
    "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
```py
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](https://eludevs.pages.dev/extra/detailed/#its-all-about-communities)


### 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.
