jdev - 2022-10-15

> <selurvedu> They expect the users to join and remain there, like e.g. irc bouncers work, but bifrost is not a bouncer, and join-parts are just how XMPP works Which is why on purpose the parts are voided not the renames though

Maranda, ah. But, well, can't that be worked around?

Or more likely on plumbed rooms on gateway room a part will happen only if all resources part

> <selurvedu> Maranda, ah. But, well, can't that be worked around? The rename happens only on a profile fetch on a rejoin

And the fetch on join is a configurable option

Maranda, I mean, could the rejoin happen without renaming to a localpart?

If the user is already there, why rename to localpart just to rename back to the nickname right away?

> <selurvedu> Maranda, I mean, could the rejoin happen without renaming to a localpart? No local part is renamed just the screen name

Maranda, so you're saying this is fine?

https://upload.jabber.at/http_upload/0HoOw7nGvFw9LKtdGFDIVoItjGiv8e50/ba949544-93d6-4c72-98df-50d2d0b91924.png

I'm not saying the localpart is changed, I'm saying the nickname on the Matrix end gets changed to localpart, and then to the actual nickname right away on every rejoin.

Because Bifrost fetches the vCard from there (at least on aria-net.org) it fetches both the nickname and avatar and applies that to the puppet profile.

> <selurvedu> I'm not saying the localpart is changed, I'm saying the nickname on the Matrix end gets changed to localpart, and then to the actual nickname right away on every rejoin. The alternative is a long clogged mxID

Bear in mind join and parts can be really hidden from the client timeline

So it is impossible to prevent those unnecessary renames? I see.

And so can Nick changes

I know, but it would be preferable if they never happened in the first place. The user actually never changed their nickname.

> <selurvedu> I know, but it would be preferable if they never happened in the first place. The user actually never changed their nickname. Atm that can't be totally prevented

:(

Thanks for the info.

Wonder if ejabberd will behave in the same way.

The code is highly asynchronous and the current workflow is vCard Nick First and Resource as fall back mainly for DMs, but MUC and DMs share the same code for that

Since from a Matrix perspective it's all rooms