When trying to join prosody@conference.prosody.im with the nickname "🤖", the join never completes.
The client receives the list of (other) participants, but does not get their own reflected presence, and neither a room subject.
If the client sends a groupchat message, it is delivered to other room participants, but not reflected to the client.
The join/message also kills of a bunch of other users, but that is not prosody's fault ;-)
Ge0rG
on
Addenum: the presence of the joining client is sent to all other participants.
MattJ
on
Thanks for the report. How certain are you that this is not a client issue?
Within Prosody JIDs are just strings, and can contain anything. On entry to the server, before a stanza gets routed, JIDs in the 'to' attribute are validated according to stringprep (using libidn's or libicu's implementation, depending on how Prosody was compiled - libidn by default).
If your Prosody decided the JID was invalid, it would have never made it to the MUC. Same if the MUC's Prosody decided the JID was invalid, this would happen long before presence distribution to other participants in the room.
Therefore I'd conclude that Prosody has no problem with the JID. Indeed on reviewing the logs, I see the user join the room successfully, the presence get broadcast successfully. Even some participants in the room sent vcard queries after the join.
Some participants' clients/servers disliked the JID and replied with an error presence. This caused Prosody to kick them from the room (the sender would be unaffected).
I also see messages sent from the successfully joined participant, again demonstrating that everything is working ok.
All the evidence points to the joining client discarding stanzas with the fancy JID. If you tell me this is certainly not the case, I'll believe you and look into the issue further.
Changes
owner MattJ
Ge0rG
on
On further investigation this looks like an issue of #583. The s2s connection just happens to stall when the full list of presences is sent over.
Zash
on
Some secondary issues where most likely due to how ICU rejects this character (probably the entire range).
MattJ
on
Closing this, as the issue with the robot is a client one. It would probably also affect Prosody servers compiled with libicu (which is an option), but that's not the default configuration and would need fixing in ICU, not Prosody.
When trying to join prosody@conference.prosody.im with the nickname "🤖", the join never completes. The client receives the list of (other) participants, but does not get their own reflected presence, and neither a room subject. If the client sends a groupchat message, it is delivered to other room participants, but not reflected to the client. The join/message also kills of a bunch of other users, but that is not prosody's fault ;-)
Addenum: the presence of the joining client is sent to all other participants.
Thanks for the report. How certain are you that this is not a client issue? Within Prosody JIDs are just strings, and can contain anything. On entry to the server, before a stanza gets routed, JIDs in the 'to' attribute are validated according to stringprep (using libidn's or libicu's implementation, depending on how Prosody was compiled - libidn by default). If your Prosody decided the JID was invalid, it would have never made it to the MUC. Same if the MUC's Prosody decided the JID was invalid, this would happen long before presence distribution to other participants in the room. Therefore I'd conclude that Prosody has no problem with the JID. Indeed on reviewing the logs, I see the user join the room successfully, the presence get broadcast successfully. Even some participants in the room sent vcard queries after the join. Some participants' clients/servers disliked the JID and replied with an error presence. This caused Prosody to kick them from the room (the sender would be unaffected). I also see messages sent from the successfully joined participant, again demonstrating that everything is working ok. All the evidence points to the joining client discarding stanzas with the fancy JID. If you tell me this is certainly not the case, I'll believe you and look into the issue further.
ChangesOn further investigation this looks like an issue of #583. The s2s connection just happens to stall when the full list of presences is sent over.
Some secondary issues where most likely due to how ICU rejects this character (probably the entire range).
Closing this, as the issue with the robot is a client one. It would probably also affect Prosody servers compiled with libicu (which is an option), but that's not the default configuration and would need fixing in ICU, not Prosody.
ChangesStatus-FixedStatus-Invalid