jdev - 2023-01-22

okay, my close friends decided to not use xmpp apps any more. Besides multiple issues, the core on was push notifications on android. I wanted to recommend to devs to review creation of awarness towards batteryoptimization deactivation. its a problem people usually dont understand

Beherit: like, not getting notifications or?

Beherit: if that's what you meant, normal people who use normal phones and install XMPP applications through normal app stores shouldn't need to disable battery optimizations, assuming their server supports push notifications, and it should or they will have a bad time

Disabling battery optimizations is for weirdos like me who don't have Google play services and install through f-droid

disabling battery optimization doesnt work on all devices anyway: https://dontkillmyapp.com/

also huawei devices don't have google play services either, and their devices ignore battery optimization settings

do you know if huawei runs their own push notification service?

> moparisthebest: > 2023-01-22 02:54 (GMT+01:00) > Beherit: if that's what you meant, normal people who use normal phones and install XMPP applications through normal app stores shouldn't need to disable battery optimizations, assuming their server supports push notifications, and it should or they will have a bad time Then I dont know whats the problem

their servers are fine

there is defibitively a huawei phone in that group I was talking about

I refered to that issue already

huawei phones should gernally work fine if there is a proper XMPP push mechanism in place

Just saying that there seems to be issues still

Another thing are passwort / lost accounts when switching phones commonly. But thats a server side thing

That's more a user thing. 😂

No, its not working if servers do not offer password reset for normal users

That depends on the server admin. There are servers with reset, and there are some that don't have it

I know, thats also why I introduced the password reset key in the providers project.

Yeah. That should be standard for public servers

It should be standard for servers recommended to newbies etc

Yeah

I basically wanted to express that onboarding and essential working setups is not a thing of the past yet.

Not on public servers, indeed

That's why I don't recommend public servers to most people, and why I work on Snikket which solves all the problems you've mentioned, and more

Beherit, if you don't want to run your own server, move your friends to mine: https://chat.trung.fun

> MattJ: > 2023-01-22 03:41 (GMT+01:00) > That's why I don't recommend public servers to most people, and why I work on Snikket which solves all the problems you've mentioned, and more Yes I see that. But we shouldn't deprecate the federated idea because of all this.

MattJ: you actually offer hosted services?

Trung: I dont run my own

Snikket is still federated. https://snikket.org/hosting/

"Public server" as in having registration open to more or less anyone.

Orthogonal to whether it participates in the open federation.

Beherit, you don't have to. Not everybody has to run a server to use XMPP. You can get onboard with the Snikket team or on my domain. All is well.

But everyone who can run a server should

Maybe 'everyone' who can commit to maintaining a server in the long run 'should' do so, but that's usually hard to predict.

At least until we have a good account migration story.

I dont know if I should setup snikket now. The game with my close friend is lost anyway for the next years and I dont have interest to deal with their frequent incompetence on some stuff. Holger: yeah, I pay for my free of costs public servers indeed

I also donated and paid for conversations even I dont use it directly + Quicksy, which worked pretty fine indeed

To be clear I meant "for their friends and family", running a public one is indeed a commitment

It's a commitment for friends & family as well, no?

moparisthebest: heh, well in my experience anything, even for one other person becomes mission critical quickly. 😁

At least if you own your own domain, you can switch hosting providers while keeping addresses

Yes that's fine though, it's a few people you know personally and you can get it sorted quickly

Maybe off topic, but that's a nice thing about phone numbers: portability with no @domain part.

I'm amazed by how broken threads turned out to be in matrix-land, is there any ongoing willingness/effort towards implementing/revamping threading in XMPP?

rom1dep: cheogram has implemented threading

oh really?

Cheogram Android, a conversations fork

jackhill, reminds me of https://en.wikipedia.org/wiki/Telephone_number_mapping

rom1dep: video demo of cheogram demo video for the thread UI branch: https://kumi.tube/w/1LQQp5Uia4u8Pdojxen1y8

I gave it a look the other day after inquiring about ad-hoc commands and it didn't strike me as having such fancy features… is there a place/blog where I can read about it?

ah, thanks jackhill :)

Threads still pre-release I think ✏

after the first 15seconds it seems like what nheko's doing

Zash: thanks, I wasn't aware of that

(which, amongst element, neochat and nheko is what makes the most sense to me)

I like this UX. I don't think it's necessary to have a feature for "creating threads" explicitly, they could arise automatically as the consequence of replying to a message.

and about that, anyone's working on contextual replies/citations where clicking on the cited message scrolls back to it?

Beherit [15:08]: > MattJ: you actually offer hosted services? Yes

rom1dep: yes to that too

in snikket?

Probably after Conversations 3 🙂

with reactions

I just meant to say that people are working on it

gotcha

at least I've seen Daniel committing a lot towards C3 lately

Yes, he has funding to work on it properly at last

I'm glad he still has the stamina to dive into large refactorings like such

> Yes, he has funding to work on it properly at last Oh, it's NLnet at it once again. Good use of taxpayer's money :)

rom1dep: yes, indeed

rom1dep: Dino has replies implemented, Movim, too. Gajim will soon follow

> dino(hg-git)[ default master]➤ hg ↓ > pulling from git@github.com:dino/dino.git > importing 26 git commits Time to check that out :)

looks like it was added 2 weeks back, good job there!

> rom1dep: Dino has replies implemented, Movim, too. Gajim will soon follow let's see how that looks ↺

https://upload.tamytro.org/upload/a3849b367f4dd4cedd5ad6f64afa7645b7d4f834/rHaQxfbairFRZbTHYiA6EXy4GgwfiD06Qorzub3i/be07886c-4f77-45b1-bbe9-5f8c3cfc064c.png

humm, apparently pasting an image in dino doesn't create an attachment :(

or maybe, just maybe, pasting images is restricted in this channel

is it right on the side of dino to pretend it attached, then?

Zash, is it?

IIRC that module is loaded here, yeah

That is.. it removes <oob>? ✏

Anyway, it would be nice if it was explicit I guess. I had no clue (and I guess I'm not the only one)

There's a `"{xmpp:prosody.im}muc#roomconfig_unaffiliated_media": false` in disco#info

"explicit" would mean what exactly in this case?

Pictures dont work in the description i guess

Yeah I guess the disco thing isn't exposed by many clients

Maybe it should be

So in the meantime in the topic or desc or sth..

Thats actually a good idea. A list of checks with what you are allowed to do in the group

From disco

Funny, that's already a thing

Somewhere

https://xmpp.org/extensions/xep-0045.html#impl-service-traffic

Conversations' channel details should show something like that below "XEP-0313: MAM → available" for instance

Well for this specific feature, the upload button could be greyed out in dino say, with a thing on hover. I don't know how to expose it in Conversations

I don't see what the big deal is with this one though. The recipient still gets a link. Why would you disable upload?

Maybe preventing upload isn't the right thing either.. just that expectations aren't respected

A user could think it's borked

(And that's actually what just happened here)

Yeah, because we're in a room of XMPP developers 🙂

I don't see why XMPP developers should have this expectation :P

We're also users, people with a heart!! ✏

Speak for yourself

I knew it

could be the same attachment icon with a warning symbol "content will be shared as a link instead of being embedded"

;)

rom1dep: unless they use Movim or Converse.js which I think will still show it "embedded" 😄

Even if you just send a link

it's just super misleading that dino sticks to the "embedding" UX while the rest of the world (including user's own clients) sees a URL

Give up, we have more important things to "fix" 🙂

After all this is a very rare used module in prosody. Its unlikely one finds it In the wild , beside these jabber rooms

Weird and unexpected anyway, but yeah I won't die on this hill

https://upload.tamytro.org/upload/a3849b367f4dd4cedd5ad6f64afa7645b7d4f834/L64XFGQT7aGlHSp0EDhnOw5Xh8dh6eDDeziFcF8l/42a10537-90b5-4e50-a07f-ba4393d319fe.png

dino did really up its game there

I remember not long ago when history retrieval would be freezing the client for minutes

There's the issue like https://github.com/dino/dino/issues/590 tho

I.e. the sending client not showing what the MUC reflects back.

Zash, looking at XEP 0045, I don't think Dinos behavior is wrong here ✏

Not wrong, but non-cooperative with server-side stuff like these

(and also mod_pastebin? :P)

'these' as in mod_pastebin, mod_muc_restrict_media, mod_swedish_chef :)

Zash i heard of that prosody feature also the first time now

so how do you think client devs will discover that?

i would expect at least that someone would open some feature request on our tracker to support that

Zash, maybe, if you want this kind of cooperation, maybe spec it properly.

0045 describes that the service can discard non-body content and if it does so, it should make a whitelist of supported namespaces discoverable. Blacklist is not supported. And any modifications of the body are also not supported.

Where does it say that? That would be news to me.

which part?

i second that, white/black list of namespaces Oo

Modifying body

What Matt linked earlier?

https://xmpp.org/extensions/xep-0045.html#impl-service-traffic ?

The service sends back the message. Up until recently, basically all clients would show what the MUC sent back.

i read this the first time, amazing

Only using an allowlist seems quite restrictive

pep., i think it makes sense

if you want to restrict something, you want to have a whitelist, because the blacklist is potentially infinite ✏

https://xmpp.org/extensions/xep-0045.html#bizrules-message > A MUC service SHOULD pass extended information (e.g., an XHTML version of the message body) through to occupants unchanged; however, a MUC service MAY disallow message specific extensions

lovetox, if you want to allow anything but, you have to literally allow everything but, and you can't know 'everything'

larma, ah

Ah, through "Allowable traffic" again

Whay you are effectively doing is "silently rejecting the incoming message and then sending a new message on the users behalf". However rejecting should typically cause an error message to be sent to the sender and generating a new message seems entirely out of spec for me.

And way too many occurrences of "body" to find if it disallows modifying it

it's not explicit, it only speaks about reflecting the message with modified from

But given that for all other elements than body it's explicityly defined they need to be be passed unchanged, it is very stretch to assume it is intended to be allowed for body

The proper solution to mod_pastebin defintely would be: Return an error message with description "Message to large, maybe upload to paste.example.org?"

SHOULD means doing the opposite is allowed if you have good reason, right? So you must be prepared to deal with it.

i think its probably like with most things in XEPs, nobody thought of the use case, else they would have explicitly forbid or allowed it

and now you go and interpret things into the XEP which probably are not there

either way

"I must be prepared" doesn't mean I must give perfect UX for it or allow the server to arbitrarily change my local database

Zash, i dont see how you would care how Dino shows the Sending bit

client can display that as it wants ..

I care because I used it and I liked being able to paste logs and patches into the chat without it taking up 3 screens.

Now I have to do roundabout things involving uploads.

Plus there's the thing Biboumi does with breaking multi-line messages into many.

ah you used the the feature to shorten your own messages

i understand

Zash, sounds like you want a totally different client feature from Dino: "If outgoing message is large, ask user to send the text as a file instead"

Sure, that'd be great

But the thing is, the server sends you back what it sent everyone else, and it's nice to have a shared view of the chat.

That would be totally fine with me and much more liked than "overwrite my local state of what the user sent with whatever the server sends"

larma: returning an error and telling someone to use an external site kinda defeats the convenience of the module

That's basically what IRC did 30 years ago

With muc, what comes from the muc is the source of truth, if it didn't come from the muc it shouldn't be in your local state

Adding upload support to anonymous hosts is also ... uncomfortable.

Expect maybe with a *send pending* flag

MattJ, I hope XMPP is not IRC 30 years ago

Haven't people been asking for this reflection for 1:1 chats?

You're proposing it, as I understand things 🙂

Muc is slightly better IRC from 24 years ago right?

but its also not nice, if a user sends a message, and gets back a pastebin link in its local history, how will the user search his history? ✏

IRC explicitly doesn't sent you back what you sent.

Which also leads to other things, like different people seeing different ordering

I'd also like to point out that mod_pastebin is almost as old as Prosody, and predates my involvement by years.

effectively the pastbin link will become invalid, and then history is lost

or, at least a year?

You only want the mod_pastebin thing in the case when users send log files or other text files as text instead as file

Right, that's what it was written for

which is a client issue if users do that

Because reactive "please don't do that" was happening at least a few times per week ✏

Then every XMPP client has this bug

When will you fix it?

As soon as servers announce their message size limit I guess

Done 😇

It's in disco

Can I haz per-user length plz

Done 5 years ago

I was told it's not gonna work with MAM etc.

https://larma.de:5281/upload/7-ZZ_73EcNvSqnJe/Screenshot%20from%202023-01-22%2020-01-06.png

Isn't a Slack snippet a regular message prefixed and suffixed with ``` ?

Zash, no, snippet is a text file ✏

Also, mod_pastebin does that, oob tag and everything. But since it leaves the first line, every client ignores it.

The first few lines are displayed inline as a preview, to open the full text file you have to click additionally

nice slack feature

Slack does it client-side though

so message-limit in muc is announced already in disco?

Also, what's the difference between the server overwriting your local state from mod_pastebin vs me sending a message correction from a different client?

``` "{https://modules.prosody.im/mod_pastebin}max_characters": "1584", "{https://modules.prosody.im/mod_pastebin}max_lines": "12", ```

i would say, the data is lost if its put into pastebin

as i said, the link will become invalid

the content will be lost

i would expect my client to store the full message locally

as file or whatever

i think its funny that this discussion is done now a decade after pastebin mod

Why? The pastebin is ran by the same server serving the muc

Zash, now make this a XEP and put a proper namespace on it

i think it served its purpose, but we can do better

MAM limits can be identical

moparisthebest, my local history is way longer than the MAM history in most rooms I am

I write code, not XEPs!

larma: sounds like you want to write a XEP for a more IRC like muc v0.5 where the Source of truth isn't the muc, and it doesn't relay messages you sent to it

But then you gotta have carbons, in order isn't preserved, it's a big step back

Biboumi can't work

The XEP is for exposing server message limits to the client

"error: this muc only supports one line per message" from biboumi I guess?

so that a client knows before sending a message that the server doesn't like the message as is

and can decide to do *something* instead

So all transports would need new XEPs to define crazy rules for clients to format messages

moparisthebest, no I want a disco field max_lines_per_message=1 instead

That's that I said? Each transport would need a XEP with formatting rules and all clients would have to implement them all before it would work

legacy clients will still send multiline messages and biboumi will still split them, but clients understanding the limits can expose them to the user

or whatever

This is not about formatting

This is about what clients can send to the server so that it is reflected unchanged

Sounds far worse than the current system, where transports mangle the message however they need, and clients display what the muc actually sent

Don't agree. Because transports won't be able to do it properly in all cases. The sending user knows how he wants stuff to be displayed at the recipient, so if what the send is what is received by others, no issues will occur.

I think your proposal vs the current state of muc causes an impossible situation for all client devs (having to adapt to new remote service rules at the speed of changes by those remote services, that's way faster than Debian releases for instance), plus terrible ux for users

I don't remember which transport was it (maybe biboumi) that split messages which are too long (not by number of lines, but number of chars) into multiple messages, but do that with python code where it totally matters if someone injects a newline at wrong place

Now each user has to understand what transport they are connected to, and constantly get back "no, now it's too many lines, no, now too long of lines, etc etc"

moparisthebest, huh? The way I'm thinking this, everything would work as is for old clients. Only new clients will tell the user "the recipient only supports up to 2000 chars per message, do you want to send a text file instead?" or someting like that.

breaking news, UX over transports is crap

IRC has a line length limit indeed

If you want UX over transports to improve, we need to get information about the transports (and its limits) to the clients and not hide it from them

i think both sides are right, we need more info to provide better UX, but on the other side we should also deal with a MUC rewriting a body

It's stupid to have XMPP users split their lines for IRC when the component can just do it

I don't want to have to remember which MUCs are IRC and which aren't

you seem to think your client can't be intelligent

I'm not saying users have to do it

Same thing, why should my client need to know about biboumi inner details

e.g. the sending client can do it for you *and* tell you that it will do so *before* you send the message

that's not biboumi inner deails

that's really just three limits: - max chars per message - max chars per line - max lines per message

Right now it gets done for you and you are told it's been done for you

but only after the fact

Except for all clients, by the muc

when you already sent out crippled text

Which is best case

You think any user ever is going to press "oh no please don't just send this and let me manually fix it" ?

If you want this terrible ux, write a XEP so MUC can give it to you

Ie a flow like you send it, muc responds with "sorry I'll have to mangle it like so: "

And the client can choose whether to send that or not

Think of the following my client can do: - Display a note "The individual lines of this message will be seen as individual messages by the recipient" - Insert a line break after the max-chars-per-line limit in the input field so user will see where the line-break would be - Tell the user that the message is too large and should be sent as a file instead

All of this would greatly improve UX

moparisthebest, I *never* want the service to mangle with my messages

Encoding all logic to what's acceptable for all remote protocols in each client is the path to insanity, it changes too much

I understand there are reasons why the server would want to do it, and I want the client to know these reasons before so it can prevent it from happening

nothing more, nothing less

larma: I'm saying it wouldn't, it would respond "I can't send the message that way for these reasons, I could send it reformated this way: $proposal"

I was literally saying 3 variables that already cover 99% of the known cases. Why you wouldn't want my client to know these? ✏

That cover IRC and mod_pastebin only you mean

which are 99% of the known cases

why not just fix the issues we have instead of overly complicating things?

What about msn, aim, icq, Google $protocol-of-the-week, signal, WhatsApp, Facebook, tiktok, I mean I could literally go on forever

I'm thinking of these three limits plus information if they are soft or hard (where soft limit means "you can send, but server gonna do things" and heard means "server will reject/error") ✏

I think your proposal is vastly overcomplicating things for all clients forever, mine would let MUCs opt in

Clients can entirely ignore my proposal and would continue to work as is

It's entirely optional allowing clients to optimize UX where they see possibilities.

No harm done

These 3 are easy but then when nicoco introduces 99999 more for slidge

Then clients may decide to not implement those.

All done.

Status quo preserved with no additional work

But all clients need to display what the muc says they sent, not what the client thinks they sent

moparisthebest, all clients can display anything they want. That's totally up to them (and that is also the status quo)

I don't think so, that's why Dino is broken and no other clients are

Also when it comes to slidge: we're already discussing how slidge will communicate the possible reactions to the client because some networks don't support all reactions. The client should know the limits or UX will be worse.

Dino works perfectly well for me 🙂

With muc what the muc sends is the source of truth, a client that guesses what it'll send is incorrect

"source of truth" to whom?

If you don't like it, propose some negotiation where the muc doesn't do this

Per the spec

what if the MUC sends different messages to different participants

what's the truth then?

What the muc says

it says different things

so there are multiple truth?

What it says to you

who is me?

Your client

What if my clients receives different things in multiple requests?

I think it would be useful for the MUC to return in a human-readable way why and how the message was rewritten (so the user gets to know what happened and why it happened), but I think it's insane to expect a formal description of all constraints, rules and limitations any past, present and future MUC/gateway/protocol may be subjecting arbitrary messages to.

Then the truth is different for each client :)

moparisthebest, that's not how "truth" works

(that's actually the situation you have now right? Only the sending Dino has incorrect history)

larma: if different clients show different messages, as a naive user, I consider them (or the protocol) broken

Sure it is, something something observing something changes it bla bla

truth is: user A wants to send message B to users C and D in the MUC. If user C receives message E instead, that doesn't change the truth what user A wanted to send.

knowing how other get to see my messages is pretty fundamental

And as the sending client I happen to know for sure what message B is.

Right, but we don't care about what user a wanted to send, we care about what was sent

I disagree

that's literally why we sign and e2ee messages.

> truth is: user A wants to send message B to users C and D in the MUC. If user C receives message E instead, that doesn't change the truth what user A wanted to send. that doesn't change what A wanted to send, but then it can create a lot of confusion and qui-proquo ↺

The truth is what was sent, and for the sending client only to have a different view (than even his other Dinos) is pretty clearly wrong

I think it's a pretty universal assumption that all participants within a same discussion get to see the same content

moparisthebest, it totally is wrong, that's why I want to change that, but not by letting the server rewite my messages

why can't we just try to make sure that the message user A sends is what is shown to users C and D?

larma, I think it's fine that the server rewrites the messages if the client is provided enough context. You can display the rewritten message as other sees it, with a warning & reason for rewriting and a way to show the original if needed

So propose a negotiated change to the spec, but when that new thing isn't negotiated, fix Dino to display what the muc sent

It's only fine if the user knows how stuff would be rewritten before he sends the message in which case the client can also just do it for him

moparisthebest, that's not how this works here

I mean or keep Dino broken for current behavior unlike all other clients, your playhouse your rules

moparisthebest, if Dino wants to have this information and use it, let it have it?

Absolutely, that's the new spec thing we just talked about?

yeah I guess. I don't really understand what you're ranting about :)

larma: I think it's very ambitious to expect the client to be able to do that. You would have to share the same processing logic on the client and server otherwise you would have no guarantee that your client did a good rewrite job. I don't see how that can be solved generically and safely

But currently, if I send a message the muc rewrite, I see the message everyone else sees, on the sending client, all my other joined clients, and other people's clients *except* if the sending client is Dino and then I see something else, to me that's a crystal clear Dino bug

yup

If we don't find other solutions what I'd rather want to do: - Add proper inline preview for text files, if the server replaces the message with a link to a file like mod_pastebin, check if the file content's match the sent message and then display the message as a inline text file preview. This way, all Dinos will see the message the same way. - For the Biboumi splitting case, detect the message reflected being split into multiple and make sure to not display any content twice.

larma: what if the constraint isn't about message length, but about e.g. forbidden characters for protocols not supporting e.g. UTF (like e.g. SMS), how would you go about exchanging this info with the server? It's an endless complexity pit

larma: even in case 1, it's potentially very important for the user to know what the pastebin link is

Don't other clients display the link as file because it has an oob tag?

Let's be precise: I want Dinos on both sides of the MUC to display the same or mostly similar message, but still make sure that misbehaving servers can't arbitrarily change my outgoing message history. Whatever that means.

> Let's be precise: I want Dinos on both sides of the MUC to display the same or mostly similar message, but still make sure that misbehaving servers can't arbitrarily change my outgoing message history. Whatever that means. > misbehaving servers what if it's a feature? ↺

E2EE?

If it helps you aren't sending the message, you are just asking the muc to send it on behalf of the username you are currently connected with

Zash, in the end, yes probably

Have messages in public MUCs signed is certainly an interesting option

The muc sends it, and it can change it if it wants

It'd deanonymize people worse than avatars currently do

larma said public MUC for a reason

moparisthebest, if you want so, I might be jsut asking the MUC to send it, but I ask it to send it *exactly as I sent it*

That's not what the XEP says... At least not last time I looked at it lol

> A MUC service SHOULD pass extended information (e.g., an XHTML version of the message body) through to occupants unchanged; however, a MUC service MAY disallow message specific extensions

You can't arbitrarily impose "MUCs MUST not alter messages" after 2+ decades of them doing it without negotiation

It's not a MUST, it's a SHOULD

SHOULD is not MUST, and that doesn't mention body

I'm asking the MUC to send it exactly as is, but the MUC of course can ignore that and send it diffrently

still that's what I'm asking for

Certainly the XEP authors thought "the muc should send the XHTML body unchanged, but it's very much desired that it changes the normal body"

New negotiation for a muc to do that seems fine

Thoughts don't matter, only text and running code... Well really only running code

You seem to misunderstand. I don't want to add complexity to MUCs, I want to add complexity to *my* client exclusively.

Why does muc reply with what was sent if clients weren't supposed to use it

but would leak into MUC wouldn't it? Or how would it signify to dino what its conditions and means for message rewrites are about?

moparisthebest, because of ordering. Same as for presence.

larma: they don't need to send the body for ordering

Now please don't tell me that you think that servers are supposed to change a joining user's presence status text just because they can.

If the spec doesn't say MUST NOT then sure

Perhaps a muc hosted in Germany and a user joins with a holocaust denial presence

Remember when clients failed to log in if the server didn't take their bind preference

I guess we have different understanding of what the RFC2119 terms are supposed to mean

If something is SHOULD NOT and you are doing it anyways, you are to blame if it causes problems.

because apparently, you did not understand the full implications before implementing

aka, changing the body may cause the sending client and the receiving client to have different understanding of what was sent and you have to understand and accept that before doing so

You cannot rely on SHOULD behavior, that's why it's not a MUST

I'm not relying on SHOULD behavior. Is Dino crashing, deleting your hard drive or doing anything else than just displaying a history of the messages you sent merged with the history of messages from others you received? ✏

You seem to wrongly expect that Dino displays the messages as the MUC seees them, but Dino displays the messages it sent merged with the messages it received from others. Which is by the way also exactly what it does in 1:1 chats, so it's being 100% consistent here. ✏

You are basically asking Dino to change its behavior to better reflect what others wanted to reach when they decided to do something they shouldn't even be doing. ✏

That's just how the spec and all other clients work 🤷‍♂️

https://xmpp.org/extensions/xep-0382.html comes to my mind. But client's would have to send it like that in the first place

em larma, MUC does rewrite presence the client sends

last i remember you sending a join presence to a muc, it can return the presence with a different nick

or at least i think that was an option for the muc, and im not imagining that

> 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.

i dont say i know what the initial authors of the MUC XEP intended, but to me the XEP always read like the Server is the source of truth, everything we send is just a "request" and we will receive later if it was accepted or not.

but i think nobody ever thought of rewriting the body, so we are left now guessing if this was intended or not ✏

Prosody is rewriting the body since 1989, so In think it is ok. Regardless of what was an intent. Its more important what's written and what's done in real life. Dino is also not wrong in showing what it wants. I don't think there is specified what the client *must* show. So its less important to argue if something if it is wrong, (I think none are wrong) but to decide if and what to do, without searching the answer in the XEP. Because is isn't there.

+1 Menel