Summary

IRCv3: Negotiate the message-tags capability and make sure our regex matches the BNF

Review Request #2217 — Created Jan. 28, 2023 and submitted Feb. 16, 2023, 2:15 p.m.

Information

Owner

grim

Repository

pidgin/pidgin

Branch

default

Bugs

PIDGIN-17738

Depends On

Blocks

2218

Reviewers

Groups

pidgin

People

Description

Previously we were missing the client only prefix and we were allowing .'s and -'s
in the vendor field. I've updated the regex to support this and split the key
into all of it's parts; the key, client only prefix, vendor, and key_name. Right
now we only use the full key, but we may need to change the way we represent
tags in memory to accomidate all of these fields.

This also means we are telling the server we support the TAGMSG command which
we do not yet implement, but that should be fine for now.

Testing Done

Ran the unit tests
Connected to a local ergo instance and verified the capability was ack'd.
Connected to libera and discovered they don't currently support message tags.

Commits

Summary	ID
IRCv3: Negotiate the message-tags capability and make sure our regex matches the BNF Previously we were missing the client only prefix and we're allowing .'s and -'s in the vendor field. I've updated the regex to support this and split the key into all of it's parts; the key, client only prefix, vendor, and key_name. Right now we only use the full key, but we may need to change the way we represent tags in memory to accomidate all of these fields. This also means we are telling the server we support the TAGMSG command which we do not yet implemnt, but that should be fine for now.	ccc967f91c1897e1698523872aa28f398c12123d

Summary

IRCv3: Negotiate the message-tags capability and make sure our regex matches the BNF

Previously we were missing the client only prefix and we're allowing .'s and -'s in the vendor field. I've updated the regex to support this and split the key into all of it's parts; the key, client only prefix, vendor, and key_name. Right now we only use the full key, but we may need to change the way we represent tags in memory to accomidate all of these fields. This also means we are telling the server we support the TAGMSG command which we do not yet implemnt, but that should be fine for now.

ccc967f91c1897e1698523872aa28f398c12123d

Change Summary:

add the issue for this.

Bugs:

+	PIDGIN-17738

Change Summary:

added message-tags to the list of support capabilities

Commits:

	Summary	ID
	IRCv3: Negotiate the message-tags capability and make sure our regex matches the BNF Previously we were missing the client only prefix and we're allowing .'s and -'s in the vendor field. I've updated the regex to support this and split the key into all of it's parts; the key, client only prefix, vendor, and key_name. Right now we only use the full key, but we may need to change the way we represent tags in memory to accomidate all of these fields. This also means we are telling the server we support the TAGMSG command which we do not yet implemnt, but that should be fine for now.	a7ce45070926ed64a56cbabeb2c38279b2978d50
	IRCv3: Negotiate the message-tags capability and make sure our regex matches the BNF Previously we were missing the client only prefix and we're allowing .'s and -'s in the vendor field. I've updated the regex to support this and split the key into all of it's parts; the key, client only prefix, vendor, and key_name. Right now we only use the full key, but we may need to change the way we represent tags in memory to accomidate all of these fields. This also means we are telling the server we support the TAGMSG command which we do not yet implemnt, but that should be fine for now.	ccc967f91c1897e1698523872aa28f398c12123d

Diff:

Revision 2 (+288 -16)

Show changes

	libpurple/protocols/ircv3/README.md
	libpurple/protocols/ircv3/purpleircv3capabilities.h
	libpurple/protocols/ircv3/purpleircv3capabilities.c
	libpurple/protocols/ircv3/purpleircv3parser.c
	libpurple/protocols/ircv3/tests/test_ircv3_parser.c

Ship it!

```
Ship It!
```

Description:

		Previously we were missing the client only prefix and we're allowing .'s and -'s
		in the vendor field. I've updated the regex to support this and split the key
		into all of it's parts; the key, client only prefix, vendor, and key_name. Right
		now we only use the full key, but we may need to change the way we represent
		tags in memory to accomidate all of these fields.

		This also means we are telling the server we support the TAGMSG command which
~		we do not yet implemnt, but that should be fine for now.
	~	we do not yet implement, but that should be fine for now.

Description:

~		Previously we were missing the client only prefix and we're allowing .'s and -'s
	~	Previously we were missing the client only prefix and we were allowing .'s and -'s
		in the vendor field. I've updated the regex to support this and split the key
		into all of it's parts; the key, client only prefix, vendor, and key_name. Right
		now we only use the full key, but we may need to change the way we represent
		tags in memory to accomidate all of these fields.

		This also means we are telling the server we support the TAGMSG command which
		we do not yet implement, but that should be fine for now.

Review Board 6.0.2

IRCv3: Negotiate the message-tags capability and make sure our regex matches the BNF

Information

Reviewers

Change Summary:

Bugs:

Change Summary:

Commits:

Diff:

Description:

Description:

Status: Closed (submitted)