source: code/trunk/doc/ext/bouncer-networks.md@ 809

Last change on this file since 809 was 548, checked in by contact, 4 years ago

doc/ext/bouncer-networks: fix typo

File size: 8.9 KB
RevLine 
[532]1---
2title: Bouncer networks extension
3layout: spec
4work-in-progress: true
5copyrights:
6 -
7 name: "Darren Whitlen"
8 period: "2020"
9 email: "darren@kiwiirc.com"
10 -
11 name: "Simon Ser"
12 period: "2021"
13 email: "contact@emersion.fr"
14---
15
16## Notes for implementing experimental vendor extension
17
18This is an experimental specification for a vendored extension.
19
20No guarantees are made regarding the stability of this extension.
21Backwards-incompatible changes can be made at any time without prior notice.
22
23Software implementing this work-in-progress specification MUST NOT use the
24unprefixed `bouncer-networks` CAP names. Instead, implementations SHOULD use
25the `soju.im/bouncer-networks` CAP names to be interoperable with other software
26implementing a compatible work-in-progress version.
27
28## Description
29
[537]30This document describes the `soju.im/bouncer-networks` extension. This enables
31clients to discover servers that are bouncers, list and edit upstream networks
32the bouncer is connected to.
[532]33
34Each network has a unique per-user ID called "netid". It MUST NOT change during
35the lifetime of the network. TODO: character restrictions for network IDs.
36
37Networks also have attributes. Attributes are encoded in the message-tag
38format. Clients MUST ignore unknown attributes.
39
40## Implementation
41
[537]42The `soju.im/bouncer-networks` extension defines a new `RPL_ISUPPORT` token and
43a new `BOUNCER` command.
[532]44
[548]45The `soju.im/bouncer-networks` capability MUST be negotiated. This allows the
[537]46server and client to behave differently when the client is aware of the bouncer
47networks.
[535]48
[548]49The `soju.im/bouncer-networks-notify` capability MAY be negotiated. This allows
[537]50the client to signal that it is capable of receiving and correctly processing
[535]51bouncer network notifications.
52
[532]53### `RPL_ISUPPORT` token
54
55The server can advertise a `BOUNCER_NETID` token in its `RPL_ISUPPORT` message.
56Its optional value is the network ID bound for the current connection.
57
[537]58### `soju.im/bouncer-networks` batch
[532]59
[537]60The `soju.im/bouncer-networks` batch does not take any parameter and can only
61contain `BOUNCER NETWORK` messages.
[532]62
63### `BOUNCER` command
64
65A new `BOUNCER` command is introduced. It has a case-insensitive subcommand:
66
67 BOUNCER <subcommand> <params...>
68
69#### `BIND` subcommand
70
71The `BIND` subcommand selects an upstream network to bind to for the lifetime
72of the current connection. Clients can only send it after authentication but
73before the registration completes.
74
75 BOUNCER BIND <netid>
76
77#### `LISTNETWORKS` subcommand
78
79The `LISTNETWORKS` subcommand queries the list of upstream networks.
80
81 BOUNCER LISTNETWORKS
82
[537]83The server replies with a `soju.im/bouncer-networks` batch, containing any
84number of `BOUNCER NETWORK` messages:
[532]85
86 BOUNCER NETWORK <netid> <attributes>
87
88#### `ADDNETWORK` subcommand
89
90The `ADDNETWORK` subcommand registers a new upstream network in the bouncer.
91
92 BOUNCER ADDNETWORK <attributes>
93
94The bouncer MAY reject this new network for any reason, in this case it MUST
95reply with an error. If the request is accepted, the bouncer MUST generate a
96new unique network ID. The bouncer MAY populate unspecified attributes with
97implementation-defined defaults.
98
99Clients MUST specify at least the `host` attribute.
100
101If the client doesn't specify the `tls` attribute, the server SHOULD use the
102default `1`. If the client doesn't specify the `port` attribute, the server
103SHOULD use the default `6697` if `tls=1` or `6667` if `tls=0`.
104
105On success, the server replies with:
106
107 BOUNCER ADDNETWORK <netid>
108
109#### `CHANGENETWORK` subcommand
110
111The `CHANGENETWORK` subcommand changes attributes of an existing upstream
112network.
113
114 BOUNCER CHANGENETWORK <netid> <attributes>
115
116The bouncer MAY reject the change for any reason, in this case it MUST reply
117with an error. At least one attribute MUST be specified by the client.
118
119On success, the server replies with:
120
121 BOUNCER CHANGENETWORK <netid>
122
123#### `DELNETWORK` subcommand
124
125The `DELNETWORK` subcommand removes an existing upstream network.
126
127 BOUNCER DELNETWORK <netid>
128
129The bouncer MAY reject the change for any reason, in this case it MUST reply
130with an error.
131
132On success, the server replies with:
133
134 BOUNCER DELNETWORK <netid>
135
136### Network notifications
137
[548]138If the client has negotiated the `soju.im/bouncer-networks-notify` capability,
[537]139the server MUST send an initial batch of `BOUNCER NETWORK` messages with the
140current list of network, and MUST send notification messages whenever a network
141is added, updated or removed.
[532]142
[548]143If the client has not negotiated the `soju.im/bouncer-networks-notify`
[537]144capability, the server MUST NOT send implicit `BOUNCER NETWORK` messages.
[535]145
146When network attributes are updated, the bouncer MUST broadcast a
147`BOUNCER NETWORK` message with the updated attributes to all connected clients
[537]148with the `soju.im/bouncer-networks-notify` capability enabled:
[535]149
[532]150 BOUNCER NETWORK <netid> <attributes>
151
[535]152The notification SHOULD NOT contain attributes that haven't been updated.
153
[532]154When a network is removed, the bouncer MUST broadcast a `BOUNCER NETWORK`
[535]155message with the special argument `*` to all connected clients with the
[537]156`soju.im/bouncer-networks-notify` capability enabled:
[532]157
158 BOUNCER NETWORK <netid> *
159
160### Errors
161
162Errors are returned using the standard replies syntax. The general syntax is:
163
164 FAIL BOUNCER <code> <subcommand> [context...] <description>
165
166If a client sends an unknown subcommand, the server MUST reply with:
167
168 FAIL BOUNCER UNKNOWN_COMMAND <subcommand> :Unknown subcommand
169
170#### `ACCOUNT_REQUIRED` error
171
172If a client sends a `BIND` subcommand before authentication, the server MAY
173reply with:
174
175 FAIL BOUNCER ACCOUNT_REQUIRED BIND :Authentication required
176
177#### `REGISTRATION_IS_COMPLETED` error
178
179If a client sends a `BIND` subcommand after registration, the server MAY reply
180with:
181
182 FAIL BOUNCER REGISTRATION_IS_COMPLETED BIND :Cannot bind to a network after registration
183
184#### `INVALID_NETID` error
185
186If a client sends a subcommand with an invalid network ID, the server MUST
187reply with:
188
189 FAIL BOUNCER INVALID_NETID <subcommand> <netid> :Network not found
190
191#### `INVALID_ATTRIBUTE` error
192
193If a client sends an `ADDNETWORK` or a `CHANGENETWORK` subcommand with an
194invalid attribute, the server MUST reply with:
195
196 FAIL BOUNCER INVALID_ATTRIBUTE <subcommand> <netid> <attribute> :Invalid attribute value
197
198If the `subcommand` is `ADDNETWORK`, `netid` MUST be set to the special `*`
199value.
200
201#### `READ_ONLY_ATTRIBUTE` error
202
203If a client attempts to change a read-only network attribute using the
204`ADDNETWORK` or `CHANGENETWORK` subcommand, the server MUST reply with:
205
206 FAIL BOUNCER READ_ONLY_ATTRIBUTE <subcommand> <netid> <attribute> :Read-only attribute
207
208If the `subcommand` is `ADDNETWORK`, `netid` MUST be set to the special `*`
209value.
210
211#### `UNKNOWN_ATTRIBUTE` error
212
213If a client sends an `ADDNETWORK` or a `CHANGENETWORK` subcommand with an
214unknown attribute, the server MUST reply with:
215
216 FAIL BOUNCER UNKNOWN_ATTRIBUTE <subcommand> <netid> <attribute> :Unknown attribute
217
218If the `subcommand` is `ADDNETWORK`, `netid` MUST be set to the special `*`
219value.
220
221#### `NEED_ATTRIBUTE` error
222
223If a client sends an `ADDNETWORK` subcommand without a mandatory attribute, the
224server MUST reply with:
225
226 FAIL BOUNCER NEED_ATTRIBUTE ADDNETWORK <attribute> :Missing required attribute
227
228TODO: more errors
229
230### Standard network attributes
231
232Bouncers MUST recognise the following network attributes:
233
234* `name`: the human-readable name for the network.
235* `state` (read-only): one of `connected`, `connecting` or `disconnected`.
236 Indicates the current state of the connection to the upstream network.
237* `host`: the hostname or literal IP address to connect to.
238* `port`: the TCP port to connect to.
239* `tls`: `1` to use a TLS connection, `0` to use a cleartext connection.
240* `nickname`: the nickname to use during registration.
241* `username`: the username to use during registration.
242* `realname`: the realname to use during registration.
[533]243* `pass`: the server password (PASS) to use during registration.
[532]244
245TODO: more attributes
246
247### Examples
248
249Binding to a network:
250
251 C: CAP LS 302
252 C: NICK emersion
253 C: USER emersion 0 0 :Simon
[537]254 S: CAP * LS :sasl=PLAIN soju.im/bouncer-networks soju.im/bouncer-networks-notify
255 C: CAP REQ :sasl soju.im/bouncer-networks
[532]256 [SASL authentication]
257 C: BOUNCER BIND 42
258 C: CAP END
259
260Listing networks:
261
262 C: BOUNCER LISTNETWORKS
[537]263 S: BATCH +asdf soju.im/bouncer-networks
[532]264 S: @batch=asdf BOUNCER NETWORK 42 name=Freenode;state=connected
265 S: @batch=asdf BOUNCER NETWORK 43 name=My\sAwesome\sNetwork;state=disconnected
266 S: BATCH -asdf
267
268Adding a new network:
269
270 C: BOUNCER ADDNETWORK name=OFTC;host=irc.oftc.net
[535]271 S: BOUNCER NETWORK 44 name=OFTC;host=irc.oftc.net;status=connecting
[532]272 S: BOUNCER ADDNETWORK 44
273 S: BOUNCER NETWORK 44 status=connected
274
275Changing an existing network:
276
277 C: BOUNCER CHANGENETWORK 44 realname=Simon
278 S: BOUNCER NETWORK 44 realname=Simon
279 S: BOUNCER CHANGENETWORK 44
280
281Removing an existing network:
282
283 C: BOUNCER DELNETWORK 44
284 S: BOUNCER NETWORK 44 *
285 S: BOUNCER DELNETWORK 44
Note: See TracBrowser for help on using the repository browser.