Initial bouncer implementation draft spec #449

prawnsalad · 2021-03-07T22:38:24Z

A progression from ircv3/ircv3-ideas#39 to have this in spec form and clearer WIP history.

Added since the gist:

Clearer on what a "buffer" is. An implementation defined channel/query/active buffer/etc.
A note on how this spec optionally keeps multiple connected clients in sync
Clearer explanation on what the CAP can be used for.

Next thoughts:

As per Standardise client-bouncer interactions ircv3-ideas#39 (comment), some sort of idle/active/inactive client state to aid the server in its notification logic. This spec does mention an optional notification level setting for buffers so including this makes sense.
Could the name "BOUNCER" for this spec be loading too much towards a traditional IRC bouncer? As with Oragano the lines get muddled between ircd/bouncer so perhaps a better term could be used.

slingamn · 2021-03-08T02:46:15Z

Could the name "BOUNCER" for this spec be loading too much towards a traditional IRC bouncer? As with Oragano the lines get muddled between ircd/bouncer so perhaps a better term could be used.

As I understand this spec, it is in fact for conventional bouncers, and therefore Oragono won't implement it. Specifically, in Oragono there's no concept of active buffers that can be added or removed, or of multiple networks. (See #444 for a case where the "buffer" concept has to be adjusted to fit the Oragono setting.)

So, if my understanding is accurate, I have no objection to this spec using the term "BOUNCER". My concern is more that we carefully factor out whatever is shared between the two models. (It sounds like this spec defers all history retrieval to draft/chathistory, which seems good. There may be some overlap between BOUNCER listbuffers and #444?)

emersion · 2021-03-08T10:20:29Z

pounce said they won't be implementing this spec, because pounce doesn't expose multiple networks this way and manages buffers differently.

This PR is missing a lot of improvements from https://git.sr.ht/~emersion/soju/tree/master/item/doc/ext/bouncer-networks.md (standard replies, batches, more idiomatic names/style, etc).

emersion · 2021-03-08T10:22:20Z

extensions/bouncer.md

+
+
+### Connecting a network
+Syntax: `[c] BOUNCER connect <netid>`


This should just be a enabled network attribute.

emersion · 2021-03-08T10:22:55Z

extensions/bouncer.md

+
+This feature is intended to provide an API for clients to build a UI around bouncer IRC servers, to manage the users IRC networks and buffers in a user friendly way and to keep multiple clients and devices synced together.
+
+It is based around network and buffer entities which both have key/value tags, such as `joined=true` for a buffer, with commands to manage these. A list of common tags can be found under the tags section of this document.


s/tags/attributes/

As discussed previously, "tags" is confusing.

emersion · 2021-03-08T10:23:42Z

extensions/bouncer.md

+
+## Capabilities
+
+This adds a capability called `BOUNCER`. Once negotiated the server may change it's behaviour to better suit bouncer clients, such as not automatically sending `JOIN` commands for already joined channels.


Caps are lowercase. Additionally, this is missing the "work in progress" section about using the draft/-prefixed cap.

emersion · 2021-03-08T10:25:21Z

extensions/bouncer.md

+
+#### Network tags
+Implementations MUST recognise the following:
+- `network` - The human readable name for the network. It may be changed.


This reads as "the network attribute of the network". Something like "name" would be better.

emersion · 2021-03-08T10:26:51Z

extensions/bouncer.md

+As a network state changes on the server such as connecting or disconnection, it MUST send the changes as they happen to any users connected clients.
+
+* Connection state changes:
+  - `[s] BOUNCER state netid netname connecting`


This isn't great IMHO, as it's only useful for network state. Would be better to allow the bouncer to notify updates of arbitrary network/buffer attribute changes.

emersion · 2021-03-08T10:28:16Z

extensions/bouncer.md

+Implementations MUST recognise the following:
+- `network` - The name of the network this buffer belongs to.
+- `buffer` - The name of this buffer.
+- `seen` - The ISO 8601 timestamp of when the user last saw this buffer. Used to determine the point at which the user as read up to.


This should be out-of-scope for the bouncer extension. Servers not implementing this spec (soju, pounce, oragono) may be interested in this functionality.

emersion · 2021-03-08T10:29:40Z

extensions/bouncer.md

+~~~
+[s] BOUNCER listnetworks netid network=freenode;host=irc.freenode.net;port=6667;state=disconnected;nick=bob;
+[s] BOUNCER listnetworks netid network=IRC.com;host=irc.irc.com;port=6697;state=connected;tls=1;nick=bob;
+[s] BOUNCER listnetworks RPL_OK


This seems alien for a modern IRCv3 spec. A batch would be better.

emersion · 2021-03-08T10:30:55Z

extensions/bouncer.md

+### Listing networks
+Syntax: `[c] BOUNCER listnetworks [*]`
+
+This command MUST return all networks under the users bouncer account. The optional second parameter of `*` is a wildcard search string that filters the returned networks. It is matched against the `network` tag of each network.


I don't think the wildcard search string adds a lot of value here. What's the use-case? Do you expect the user to have a huge number of networks so that filtering can't be done client-side?

emersion · 2021-03-08T10:31:31Z

extensions/bouncer.md

+#### Buffer tags
+
+Implementations MUST recognise the following:
+- `network` - The name of the network this buffer belongs to.


This should be a stable netid, not a network name.

awfulcooking · 2021-10-26T20:05:52Z

Hi pals. I am excited about the potential this opens up. I see inter-network bouncers as a potential future for federation on IRC, where you might dial out from say Libera, and appear on other networks as *![email protected].

(Or *![email protected] if the network is feeling creative enough.)

I've been working on a proof-of-concept network, combining soju and InspIRCd in a way that obviates traditional services, and is designed for ad-hoc federation.

I don't have strong opinions about the specs, but I respect your efforts and thank you for them.

I hope that the differences can be resolved and agreed, so we all can benefit from a single target.

Ideally, I would be able to offer Kiwi and Gamja both as a frontend to my network.

And to that end I wish you both the best of luck and encouragement in finding something to both your satisfaction :-)

jwheare · 2021-11-02T21:46:12Z

I don't think this will be progressed, given the OP has quit IRC dev and other interested parties want to take this in a different direction. So I'll close it, @emersion if you want to open a PR for your version, please do.

Initial bouncer implementation draft spec

49ce13f

emersion reviewed Mar 8, 2021

View reviewed changes

jwheare closed this Nov 2, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Initial bouncer implementation draft spec #449

Initial bouncer implementation draft spec #449

prawnsalad commented Mar 7, 2021

slingamn commented Mar 8, 2021

emersion commented Mar 8, 2021 •

edited

Loading

emersion Mar 8, 2021

emersion Mar 8, 2021

emersion Mar 8, 2021

emersion Mar 8, 2021

emersion Mar 8, 2021

emersion Mar 8, 2021

emersion Mar 8, 2021

emersion Mar 8, 2021

emersion Mar 8, 2021

awfulcooking commented Oct 26, 2021

jwheare commented Nov 2, 2021 •

edited

Loading



		### Connecting a network
		Syntax: `[c] BOUNCER connect <netid>`


		This feature is intended to provide an API for clients to build a UI around bouncer IRC servers, to manage the users IRC networks and buffers in a user friendly way and to keep multiple clients and devices synced together.

		It is based around network and buffer entities which both have key/value tags, such as `joined=true` for a buffer, with commands to manage these. A list of common tags can be found under the tags section of this document.


		## Capabilities

		This adds a capability called `BOUNCER`. Once negotiated the server may change it's behaviour to better suit bouncer clients, such as not automatically sending `JOIN` commands for already joined channels.

Initial bouncer implementation draft spec #449

Initial bouncer implementation draft spec #449

Conversation

prawnsalad commented Mar 7, 2021

slingamn commented Mar 8, 2021

emersion commented Mar 8, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

awfulcooking commented Oct 26, 2021

jwheare commented Nov 2, 2021 • edited Loading

emersion commented Mar 8, 2021 •

edited

Loading

jwheare commented Nov 2, 2021 •

edited

Loading