ircv3-specifications icon indicating copy to clipboard operation
ircv3-specifications copied to clipboard

Add user query extension

Open emersion opened this issue 5 months ago • 4 comments

cc @slingamn

emersion avatar Jun 30 '25 07:06 emersion

How about one QUERYUSER command with subcommands + (add), - (remove), and L (list), similar to MONITOR?

I'm not in love with the single-character subcommands, I would prefer explicit words as done in e.g. metadata-2, but that's purely cosmetic.

I think the list subcommand could be a better idea instead of implicitly sending a (potentially) big list upon conn registration: the list can be quite large and implicitly sending replies has been problematic in the past (e.g. no-implicit-names, or the messy JOIN burst management).

I wonder if we need to introduce some kind of paging…? I would like the spec to stay as simple as possible, and in practice the list should be limited in size or else it would be annoying to display in a sidebar UI.

Any thoughts on batching QUERYUSER from the server (particularly if there were an L command for listing?)

Sounds like a good idea either way!

I still think this needs an implementation considerations section on limiting data growth.

Yup, was definitely something I wanted to add. Done!

emersion avatar Jul 17 '25 09:07 emersion

For classic IRC client UIs like gamja, the list is displayed in the sidebar alongside channels, so the user is likely to clean up old and unused user queries to avoid cluttering the screen too much. For clients like Goguma, the user typically never closes older user queries, since these get naturally pushed back to the back of the list. I've wondered whether we needed to accommodate for this in the spec, but I haven't found anything we could do differently.

emersion avatar Jul 17 '25 09:07 emersion

I'm not in love with the single-character subcommands, I would prefer explicit words as done in e.g. metadata-2, but that's purely cosmetic.

Fine by me :-) I just prefer subcommands over multiple commands, for cleanliness / extensibility.

slingamn avatar Jul 17 '25 18:07 slingamn

I think under a normal workload, data size shouldn't really be a concern and it should be fine to send all open queries as part of (technically after) the registration burst, without pagination.

slingamn avatar Jul 17 '25 18:07 slingamn