MUC-service-given nickname not respected by beagle (#602)
Unknown opened 2 years ago

From XEP-0045:

The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks are locked down or based on some other policy). The service MUST allow the client to enter the room, modify the nick in accordance with the lockdown policy, and include a status code of "210" in the presence broadcast that it sends to the new occupant.

Example 22:

<presence
    from='coven@chat.shakespeare.lit/thirdwitch'
    id='n13mt3l'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
    <status code='110'/>
    <status code='210'/>
  </x>
</presence>

Beagle does not respect this new nickname given by the service on join, resulting in self messages appearing as duplicates in the chat view: first, a message with the nickname beagles thinks is my nickname, then, the actual "echo" of my message with the proper nickname that the MUC service has given me.

Unknown commented 2 years ago

Thank you for reporting this issue. XEP-0045 is rather a big one. We will try to address this issue in the next big version of the Beagle IM.

Unknown commented 1 year ago

For context, this would be awesome for most gateways, since being able to pick a different nickname in a each room is something relatively XMPP-specific.

issue 1 of 1
Issue Votes (0)
Watchers (0)
Reference
tigase/_clients/beagle-im#602
Please wait...
Page is in error, reload to recover