Skip to content

Conversation

@maidl0ver
Copy link

Fixes parsing of XMPP nicknames containing / and/or @

Example with jid@srv.tld/nick/n@me:
Previous behaviour produces an empty string
New behaviour produces the intended nick/n@me

Fix nicknames with @
@selfhoster1312
Copy link

I'm actually not sure that @ is allowed in resource parts. See https://xmpp.org/rfcs/rfc4622.html

What client/server are you using that allows it? Can you find a reference for it to be allowed? If so we should open an issue in upstream https://github.com/xmppo/go-xmpp to add a helper function for that purpose.

@maidl0ver
Copy link
Author

@selfhoster1312 I don't think the RFC you're referring to describes our case explicitly, here's a more concrete mention of what can go in the resource part: RFC7622 (3.4)

thus, for example, an XMPP address of the form <localpart@domainpart/foo/bar> does not identify a resource "bar" that exists below a resource "foo" in a hierarchy of resources associated with the entity "localpart@domainpart".

The '@' character is allowed in the resourcepart and is often used in the "handle" shown in XMPP chatrooms [XEP-0045]

@selfhoster1312
Copy link

Thanks for digging this high quality source! We would definitely accept this PR in the matterbridge community fork: https://github.com/matterbridge-org/matterbridge

Maybe they'll also be interested in upstream go-xmpp, but that's a story for another day :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants