Skip to content

Commit 7dfc427

Browse files
author
user0-07161
committed
[WIP!] feat: ts6 server support
this is really unfinished and *WILL* be rebased! pushing just to let the test run on github's servers (my laptop is too sh*tty)
1 parent 86b9c8d commit 7dfc427

32 files changed

+4114
-382
lines changed

‎Cargo.lock‎

Lines changed: 81 additions & 263 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

‎Cargo.toml‎

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -5,16 +5,16 @@ edition = "2024"
55

66
[dependencies]
77
async-trait = "0.1.89"
8-
clap = { version = "4.5.48", features = ["derive"] }
9-
once_cell = "1.21.3"
10-
tokio = { version = "1.47.1", features = ["full"] }
11-
console-subscriber = { version = "0.4.1", optional = true }
12-
tracing = "0.1.41"
13-
tracing-subscriber = "0.3.20"
8+
clap = { version = "4.5.53", features = ["derive"] }
9+
tokio = { version = "1.48.0", features = ["full"] }
10+
console-subscriber = { version = "0.5.0", optional = true }
11+
tracing = "0.1.44"
12+
tracing-subscriber = "0.3.22"
1413
thiserror = "2.0.17"
1514
anyhow = "1.0.100"
16-
toml = "0.9.7"
15+
toml = "0.9.10"
1716
serde = { version = "1.0.228", features = ["derive"] }
17+
once_cell = "1.21.3"
1818

1919
[features]
2020
tokio-console = ["tokio/tracing", "console-subscriber"]

‎docs/technical/client_cap.txt‎

Lines changed: 172 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,172 @@
1+
Client Capab Proposal (v5)
2+
Authors: fl and Beeth
3+
--------------------------
4+
5+
6+
This document aims to define a protocol for capabilities between a server
7+
and a client. These capabs help servers introduce changes to the protocol
8+
that could cause problems with clients that do not support the changes.
9+
10+
This specification defines the "CAP" command, and the available subcommands.
11+
This is sent in the form:
12+
CAP [subcommand [parameters]]
13+
14+
CAP
15+
---
16+
17+
A client that supports this specification must send one of three things at
18+
the earliest stage of registration. To enter capab negotiation it can either
19+
send the command "CAP" without parameters to request a list of capabs, or it
20+
can send the subcommand "REQ" to request capabs without first seeing the
21+
list of available capabs. A client which does not wish to enter capab
22+
negotiation but supports this spec must send the subcommand "END" to notify
23+
support of the specification.
24+
25+
The "CAP" command may be used at any time during the connection to request a
26+
list of capabs. If the user enters capab negotiation the server must
27+
postpone registration until the client issues the subcommand "END".
28+
29+
A server receiving the parameterless "CAP" command from a client must reply
30+
to this command with a list of capabs supported by the server using the "LS"
31+
and "LSL" subcommands. The "LS" subcommand is used when the capab list must
32+
be spread across multiple lines and is used for all except the last line.
33+
The subcommand "LSL" is used to finish the list of capabs.
34+
35+
The subcommands "LS" and "LSL" are sent in the form:
36+
CAP <subcommand> :<capab> [capab]*
37+
38+
CAP: REQ
39+
--------
40+
41+
The "REQ" subcommand is used by a client to give a list of capabs it
42+
wishes to use.
43+
44+
The subcommand "REQ" is sent in the form:
45+
CAP REQ :<capab> [capab]*
46+
47+
If any of the requested capabs are prefixed with '-' then the client is
48+
notifying the server that it wishes the specified capab to be disabled for
49+
the client.
50+
51+
The responsibility is placed on the client to request a valid list of capabs.
52+
The server must either accept the request as issued or reject it. A server
53+
must not partially accept parameters of the subcommand "REQ".
54+
55+
CAP: ACK
56+
--------
57+
58+
The "ACK" subcommand is used by a server to acknowledge that the
59+
given capabilities are now being used. The "ACK" subcommand is used by a
60+
client to acknowledge the given capabilities are now being used.
61+
62+
The server places the capabilities it is acknowledging as parameters. The
63+
parameters of the subcommand "ACK" will be identical to the parameters issued
64+
in the subcommand "REQ" from the client if the request is valid. If any of
65+
the requested capabs modify the protocol stream, after sending the subcommand
66+
"ACK" the server must then transmit any following messages in the modified
67+
protocol stream form.
68+
69+
The client must issue the subcommand "ACK" for any capabilities that modify
70+
the protocol stream, using the capabs that modify the protocol stream as the
71+
subcommand "ACK" parameters. A client must know which capabs modify the
72+
protocol stream and send the subcommand "ACK" before transmitting any
73+
messages in the modified protocol stream. A client must not issue the
74+
subcommand "ACK" for a capab without first receiving the subcommand "ACK"
75+
containing that capab from the server.
76+
77+
A client must not issue the subcommand "ACK" for capabs that do not modify
78+
the protocol stream.
79+
80+
The subcommand "ACK" is sent in the following form:
81+
CAP ACK :<capab> [capab]*
82+
83+
CAP: NAK
84+
--------
85+
86+
The "NAK" subcommand is used by a server to notify a client that the
87+
requested list of capabs are invalid.
88+
89+
A client receiving the subcommand "NAK" must request again the capabs it
90+
wishes to use. The parameters of the subcommand "NAK" will be identical
91+
to the parameters issued in the subcommand "REQ" from the client if the
92+
request is invalid.
93+
94+
The subcommand "NAK" is sent in the following form:
95+
CAP NAK :<capab> [capab]*
96+
97+
CAP: CLEAR
98+
----------
99+
100+
The "CLEAR" subcommand is used by a server to notify a client that all
101+
capabs have been cleared. The "CLEAR" subcommand is used by a client to
102+
request that a server clears its current capab list.
103+
104+
A server receiving the subcommand "CLEAR" must issue back the subcommand
105+
"CLEAR" using the current protocol stream. It must then clear the stored
106+
list of capabs and revert to receiving/sending a 'normal' protocol stream
107+
from/to the client.
108+
109+
A client receiving the subcommand "CLEAR" must then revert to expecting to
110+
receive a 'normal' protocol stream.
111+
112+
The subcommand "CLEAR" is sent in the form:
113+
CAP CLEAR
114+
115+
CAP: END
116+
--------
117+
118+
The "END" subcommand is used by a client to notify the server it has
119+
finished capab negotiation and the server can proceed with registration.
120+
121+
The subcommand "END" is sent in the form:
122+
CAP END
123+
124+
125+
Examples
126+
--------
127+
128+
CLIENT: indicates what client sends
129+
SERVER: indicates what server sends
130+
131+
This example shows a client which doesnt support this specification:
132+
133+
CLIENT: NICK FOO
134+
CLIENT: USER FOO FOO FOO FOO
135+
SERVER: :SERVERNAME 001 ...
136+
137+
This example shows a client supporting this specification but not
138+
wishing to use capabs for the connection:
139+
140+
CLIENT: CAP END
141+
CLIENT: PASS FOO
142+
CLIENT: NICK FOO
143+
CLIENT: USER FOO FOO FOO FOO
144+
SERVER: :SERVERNAME 001 ....
145+
146+
This example shows a client requesting a list of capabs then successfully
147+
requesting the capabs.
148+
149+
CLIENT: CAP
150+
CLIENT: NICK FOO
151+
CLIENT: USER FOO FOO FOO FOO
152+
SERVER: CAP LS :A B C D E F G H
153+
SERVER: CAP LSL :I J
154+
CLIENT: CAP REQ :A B C D E F
155+
SERVER: CAP ACK :A B C D E F
156+
CLIENT: CAP END
157+
SERVER: :SERVERNAME 001 ...
158+
159+
This example shows a client requesting an invalid list of capabs.
160+
161+
CLIENT: CAP
162+
CLIENT: NICK FOO
163+
CLIENT: USER FOO FOO FOO FOO
164+
SERVER: CAP LSL :A B C D E F G H
165+
CLIENT: CAP REQ :A B
166+
SERVER: CAP NAK :A B
167+
CLIENT: CAP REQ :A
168+
SERVER: CAP ACK :A
169+
CLIENT: CAP REQ :C
170+
SERVER: CAP ACK :C
171+
CLIENT: CAP END
172+
SERVER: :SERVERNAME 001 ...

‎docs/technical/encap.txt‎

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
ENCAP DEFINITION
2+
----------------
3+
4+
Preamble
5+
--------
6+
7+
This document defines the specification for the ENCAP command.
8+
9+
ENCAP is designed to help fix the situation where new commands do
10+
not propagate over hub servers running older code.
11+
12+
Definition
13+
----------
14+
15+
Support for the ENCAP command is given by the CAPAB token "ENCAP".
16+
17+
The format of ENCAP is:
18+
:<source> ENCAP <destination> <subcommand> <parameters>
19+
20+
<source> - The entity generating the command.
21+
22+
<destination> - The entity the command is destined for. This may
23+
include wildcards for servers, but not clients.
24+
25+
If the wildcard does not match the current server, the
26+
command should be propagated and ignored.
27+
28+
<subcommand> - The subcommand we're propagating over ENCAP. If the
29+
subcommand is not recognised by the current server, the
30+
command should be propagated and ignored.
31+
32+
<parameters> - The parameters that the subcommand have.

0 commit comments

Comments
 (0)