Client requesting the
message-tagscapability have (by the message tags specification) full support of message tags, and can parse unknown tags. soju can add a namespace tag on messages to clients that have requested this capability.
So a first step might just be: filter clients that support
message-tagsand send them the
But for the client to be sure that this tag this tag is present on messages, soju should advertise a vendored capability like
soju.sr.ht/namespaceto show that the client is in fact connecting to a server that sends
So the second step might be: advertise
soju.domain.tld/namespaceand also send the
namespacetag to clients that don't have
soju can add a namespace tag on messages to clients that have requested this capability.
-1, this could conflict with a future IRCv3 tag. I'd rather just require the clients to request the new capability.
Other than that, yeah that sounds like a good plan.
The tag must be vendored too indeed. Just to be clear, here's an example of a client requesting both capabilities (cap and tag domain TBD):
... C -> S : CAP REQ :message-tags sr.ht/namespace S -> C : CAP ACK :message-tags sr.ht/namespace C -> S : CAP END S -> C : @sr.ht/namespace=freenode :tolkien.freenode.net 001 me :Welcome ...
Here's a draft spec, taken from https://ircv3.net/specs/extensions/server-time-3.2.html
Clients indicate support for the extension by requesting a capability
sr.ht/namespaceas per the IRC Client Capabilities Extension.
CAP REQ :sr.ht/namespace
When enabled, the
sr.ht/namespaceextension enables the optional
sr.ht/namespacemessage tag which can be used in messages from server to client. Its value is REQUIRED and clients MUST treat it as an opaque identifier. It represents the name of the network the message originates from.
sr.ht/namespaceis presented in a message received from a server, a client SHOULD treat the message as if it came from the network from the tag value.
Servers MAY include
sr.ht/namespacein messages when they see fit but MUST NOT do so before acknowledging the client capability using CAP ACK. Clients MAY choose to simplify parsing by accepting namespaces at any point in the connection (e.g. even before CAP REQ).
Nice. Couple comments:
- The name should probably be something else, e.g.
soju.emersion.fr/namespace. The goal here is to prevent conflicts. Someone else using
sr.htfor hosting might design another IRCv3 extension.
- The namespace is an "opaque identifier" which is good, but the spec also says messages with the namespace are treated "as if it came from the network from the tag value". I think the wording here can be improved to allow a future version to add e.g. a friendly network name. Maybe something like: "a client SHOULD group messages per namespace"?
Side note, I think it's a good idea to keep the namespace tag optional ("Servers MAY include sr.ht/namespace in messages"): some messages apply to the whole bouncer and don't have a namespace (for instance, all BouncerServ messages).
Hi, I've been working on a few bnc related functions for my own project at https://github.com/kiwiirc/kiwibnc to make managing and connecting multiple networks easier. One of the bigger implementation has been an API to the bnc to manage networks+buffers in the client UI much cleaner, https://github.com/ircv3/ircv3-ideas/issues/39
One of the other ideas I've been thinking about is also multi-network support on a single connection as you brought up in this issue. I like your namespace tag idea, simple and doesn't require any extra message parsing. Would you be interested in working it as an optional extension to the BOUNCER spec I linked above? I could imagine it being a nice addition since it already includes things like listing available networks (namespaces), their identifiers and its available buffers.
Some high-level things that come to mind that may be useful:
- Some type of attach/detach sub command to attach a namespaced channel to the current client<>bnc connection
- A way to attach/detach an entire namespace so that the client can show both namespaces as if they were 2 separate connections (I think this was your general idea already?)
Implementation-wise, I think we'll want:
downstreamConn.sendMessageWithNetwork: would add the namespace tag to the message
- Make the downstream message handler extract the message namespace and retrieve the associated network. Fallback to
downstreamConn.networkif there's no tag.
22:36 <@emersion> yeah, i've thought about it a little bit more and for my use-case having a NAMESPACE +<name> server command to introduce a new namespace, a namespace tag, and a NAMESPACE -<name> command to remove it would be enough i think 22:37 <@emersion> basically, the exchange would look like this: 22:37 <@emersion> - client connects and enables the namespace cap 22:37 <@emersion> - at registration time, server sends NAMESPACE +<name> for each namespace (for soju, 1 per network) 22:38 <@emersion> each namespace is like a full-fleged irc connection, except it's already registered 22:39 <@emersion> - if a network is removed, the bouncer sends NAMESPACE -<name> to indicate the namespace is closed 22:39 <prawnsalad> without a full ircd registration in each namespace, how would the client know the connection info such as modes/caps/etc/etc 22:40 <@emersion> ah, i think "already registered" isn't the right term 22:40 <@emersion> i mean, client wouldn't send NICK/USER, it'd get RPL_WELCOME directly 22:41 <prawnsalad> ah gotcha, so the namespace name is an existing namespace in the bnc which has a upstream network associated 22:41 <prawnsalad> basically skipping the auth part 22:42 <@emersion> yeah