1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
|
---
title: "Discord sucks! ...so I made my own"
description: How I built Eko - THE discord alternative for terminal nerds
date: 2025-08-08
---
## Discord sucks
I have been disatisfied with discord for a few years by now, the main reasons that most people will
agree with me, are it's slow, sluggish, bloated, and that it gets worse over time.
- Reduced upload size from 50mb to 10mb
- Ugly UI revamps
- Literally ships with an entire browser (chromium due to electron)
But there are a few more personal reasons for me.
Ignoring the fact that I am in 100 servers and literally can't join any more,
as someone who spends most of his day in the terminal, writing code with NVIM (btw),
I really missed vim motions in discord, they are great and I'd probably talk about them in the future.
## Searching for alternatives
Vim motions are so ubiquitous they are practically everywhere, not just coding editors like Zed and
vsc\*de but also note taking apps like Obsidian, and heck, even google docs have an extension for them.
Surely an app as popular as Discord will have them right? well after some searching I found
[Cordless](https://github.com/Bios-Marcel/cordless), a discord client in the terminal, great!
Reading the readme, I immediately got dissapointed, the project has been shutdown.
The reason was due to a high risk of Discord banning users for ToS violation, so I couldn't even make my own client!
## The idea
So I thought to myself, if Discord doesn't let me make a client, I'll write my own Discord, complete
with a backend, frontend and most importantly, vim motions!
Great, now that I have the idea, what languages do I use for the backend and the frontend?
I heard that golang is a really good language for the backend, due to it's concurrency model making
it easy to handle a ton of connections simultaneously.
And what about the frontend? I'd need to find some library to help me make a TUI (terminal UI),
After some searching, I found [bubbletea](https://github.com/charmbracelet/bubbletea) from [charm](https://github.com/charmbracelet),
a golang library for creating TUIs, perfect.
This has the added benefit of the backend and frontend being able to share types as they are
written in the same language.
## The implementation
### The frontend
Bubbletea uses the Elm architecture to create a UI, it is made out of 3 components:
- The model - the state of the UI, it can contain UI elements, buttons, styles, and even other models
- The view - a function that takes a model and returns the UI, in the case of a TUI, it just returns a string
- The update - a function that takes the model and a message, and computes a new model based on that message
The way it works, is a new message comes, for example a user resized the window, this message
gets propagated to the model via the update method, which produces a new model, then
the view method takes the new model and renders the new state to the UI.
The concept itself is really great, although Bubbletea, partly due to golang had to make a few
tradeoffs which made me like it less.
First, golang doesn't have the concept of "const", so the view must take a copy of the model,
FOR EVERY RE-RENDER, this is extremely inefficient, especially that most models can take thousands
of bytes if not more, and that the copy is being pased on the stack.
This doesn't only happen on view, this also happens in the update function, every update, the model
also gets copied and passed on the stack, then the function modifies the stack version and returns
a new version of it that is then also, gets copied on the stack.
This is due to the Elm architecture originating from Elm, a functional programming language, in
such languages mutating is discouraged, and everything gets copied.
### The backend
The server itself is fairly boring, it has a loop that accepts new TCP/TLS connections, and it
spawns a new goroutine ("Green thread") to handle the client requests.
So instead, let's talk about how IDs are handled!
My first idea was to use a UUID (universally unique identifier), but it takes 128 bits, that seems
way too much, 32 bits already allow for 4 billion permutations, but just in case (see IPv4 lol),
64 bits should be plenty, that's 18 quintillion!
For the format, is it fine to just randomly generate them? 18 quintillion is alot, but the chance
of collissions is not as low as I'd like it to be, I wonder what Discord uses for their IDs...
#### Snowflake IDs
Discord uses snowflake IDs, originally invented by Twitter, they are 64-bit with a special format
that guranteed uniqueness across multiple machines and data centers, here's how they work:
```
0 1 2 3 4 5 6
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|s| Milliseconds since Epoch | Node ID | Mac ID | Incremented |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
- s - The sign bit when storing the ID as an int64, unused (always 0)
- Milliseconds since Epoch - The number of milliseconds since some date, in Twitter's case this is 2010, for Discord it's 2015, and for Eko it's 2025
- Node ID - A unique identifier for the data center or cluster, in case of Eko this is always just 1 as I run eko on a single VPS server
- Mac ID - The specific machine ID within a cluster, in Eko this is combined with the NodeID into a single 10-bit field, with a value of 1
- Incremented - If 2 IDs are generated in the same millisecond, this is incremented, up to 4095 times,
allowing a single machine to generate 4 million IDs per second (1000 * 4096)
The snowflake ID also has the nice benefits of embedding a timestamp in it, this allows to save
even more space by not needing to store a separate unix timestamp for creation dates, the creation
date of a user is when their ID was first generated.
If you are interested in knowing when your discord account was created, there are [websites](https://snowsta.mp/)
that allow you to check this.
Because everything in Eko uses snowflake IDs (users, networks, frequencies, messages) this trivially
allows us to view the timestamp, the client just shifts 22 bits to get the milliseconds, adds the
hardcoded Epoch, formats the unix timestamp, and now you got timestamps of messages.
### The protocol
Ok, so we have the backend, we have the frontend, but how will they communicate over the network?
The first thought that came to mind, was to use whatever Discord uses, which is HTTPS and websockets,
but this felt wrong, using such a bloated protocol just for sending a few text messages.
I decided it'd be better to design my own protocol from scratch, that'd be efficient and small.
After a while of planning, I came up with this packet format:
```
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |En.| Type | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload... Payload Length bytes ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
- Version (8 bits) - the most important thing when designing a protocol is to have a version field,
so that when you inevitably introduce breaking changes, the server and client will notice a mismatch
and know how to deal with it
- Encoding (2 bits) - Indicates the format of the payload, more on that later
- Type (6 bits) - The type of the payload, what kind of message it is
- Payload Length (16 bits) - How long is the payload, 16 bits gives us a maximum payload size of 65,536 bytes
- Payload (0-65k bytes) - The actual body of the message, formatted per the encoding
I was thinking about how to encode the payload in an efficient format, JSON was just too verbose
for this, after taking a look at protobufs, cap'n proto and MsgPack, I chose MsgPack, mostly
because of it's ease of use while being almost as fast as the other 2.
But I still wanted to support JSON, so I introduced a 2-bit encoding into my packet,
the idea is the packet sender specifies 0 for JSON, 1 for MsgPack, and the other 2 are reserved.
That way the server and client can communicate with MsgPack, but if a developer writes their own
client that uses JSON, the server can handle that just as fine.
Another thing to mention is how the type thing is used as a "tagged union", it specifies the
structure of the payload, unlike a tagged union though, it doesn't need to store the size of the
largest packet, that's what the payload length field is for.
## The release
After months of work, I am happy to present...
[Eko](https://github.com/kyren223/eko) - a terminal-native discord alternative for terminal enthusiasts!
<img
src="/eko-screenshot.png"
alt="Description"
style={{ width: "1000px", paddingBottom: "20px" }}
/>
For more information head over to the [README](https://github.com/kyren223/eko), or install it now with
```
curl -sS https://eko.kyren.codes/install.sh | sh
```
Hope to see you there!
As always if you have questions or want to chat, feel free to contact me on discord at Kyren223 or email me at `contact at kyren.codes`.
You can also add me on Eko, here's my ID: `2102554263552`
|
