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
|
# Tasks
# Bugs
# Improvements
# Questions
# Decisions
## TODO Accepted dependencies {#td-faf15e3f-4a57-a99e-55c6-53ffd7448962}
- TODO in 2023-11-09
---
- Node.js: for running the application;
- SQLite: for storing data for history, queues and auth;
- maybe some library with Node.js binding to SQLite.
Since the fancy chat is going to be done first (see
[#td-ed5d15f4-ec30-7411-fa74-552a06569c91](#td-ed5d15f4-ec30-7411-fa74-552a06569c91)),
it may be possible to postpone the SASL authentication and rely only on the
`NickServ` authentication for now.
## TODO IRCv3+ first, RFC 1459 after {#td-ed5d15f4-ec30-7411-fa74-552a06569c91}
- TODO in 2023-11-09
---
Do the fancy chat first, and the basic one after.
## TODO Encubate dependencies than move them out {#td-1045dbb9-fd89-e254-3e9d-642cb112c6ad}
- DONE in 2023-11-09
---
In order to achieve the reliability and robustness targets I have, and to build
something that I'd want to personally use deploy, I'll need as few dependencies
as possible. So as papo gets built, I'll need miniscule libraries for web
routing, WebSockets, etc., and as I write those inside papo itself, I'll
eventually pull them out as standalone dependencies.
So the apparent number of dependencies may seem to grow, but only because
they're being separated from papo itself, so that this repository contains code
relating to chat things, and infrastructure things go to their own repository.
Also despite the apparent dependency count growth, these dependencies are being
bu8ild alongisde papo and with its robustness, reliability and correctness
standard from the beginning, so the mismatch in quality is not a concern.
## DONE Assume Node.js {#td-faae1d8e-4015-cb78-0fe9-d003428266c9}
- DONE in 2023-11-09
---
Despite existing multiple available JavaScript runtimes these days besides
Node.js, like Deno (also V8), QuickJS, Bun, Hermes, etc., I'll stick to Node.js,
for a few reasons:
- it allows me to focus on getting things out there by leveraging
Node.js-specific functionalities;
- it prevents me from wasting time writing compat layers for the multiple
implementations.
If a compatibility API across runtimes ever emerges I'll adopt that, but untill
then I'm better off getting things done rather than supporting as many platforms
as possible when I need not to. Its better for me to use this time and energy
improving papo itself.
# Resources
# Scratch
|
