~taiite 4 years ago

Client requesting the message-tags capability 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-tags and send them the namespace tag.

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/namespace to show that the client is in fact connecting to a server that sends namespace tags.

So the second step might be: advertise soju.domain.tld/namespace and also send the namespace tag to clients that don't have message-tags but have soju.domain.tld/namespace.

~emersion 4 years ago

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.

~taiite 4 years ago

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
...

~emersion referenced this from #6 4 years ago

~taiite 4 years ago

Here's a draft spec, taken from https://ircv3.net/specs/extensions/server-time-3.2.html

Thoughts?

---

#sr.ht/namespace extension specification

Clients indicate support for the extension by requesting a capability sr.ht/namespace as per the IRC Client Capabilities Extension.

CAP REQ :sr.ht/namespace

When enabled, the sr.ht/namespace extension enables the optional sr.ht/namespace message 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.

If the sr.ht/namespace is 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/namespace in 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).

~emersion 4 years ago

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.ht for 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"?

~emersion 4 years ago

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).

~prawnsalad 4 years ago

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:

1. Some type of attach/detach sub command to attach a namespaced channel to the current client<>bnc connection
2. 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?)

~emersion 4 years ago

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.network if there's no tag.

~emersion added enhancement 4 years ago

~emersion added downstream 4 years ago

~taiite referenced this from ~taiite/senpai#13 4 years ago

~emersion 4 years ago

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

~emersion REPORTED FIXED 3 years ago

Support for soju.im/bouncer-networks has been merged.