jdev - 2023-01-26

Hi, I'm thinking about applying for a membership in the XMPP Standards Foundation. Would anyone create an wiki account for me with the Nickname "Arne"? Thank you!

Arne: I can do that, please also send me your email address via DM

Ge0rG it's arne-bruen@monocles.de thanks

Arne: > The user account for Arne (talk) has been created.

please check your inbox (and spam)

Received. Thanks!

if I'm an entity not implementing last message correction, is it OK to reply to an LMC-containing message with <message type=error>? The statu quo seems to be "just display the message body as a new message", but I am wondering if there something inherently wrong with replying with <message t=error>

What's the benefit?

The reason it's designed the way it is, is so that if someone doesn't support the XEP they still get to see the corrected message

yes, I figured. it's how slidge does it for legacy services that don't support LMC, but it's been confusing to some users. I'll just make the gateway component send a message informing the user that LMC does not work on XXX and that a new message has been sent instead. (well unless the legacy service supports retraction in this case I can retract/send a new one)

I agree that there is no point, I was just trying to think what the "least confusing UX" could be.

Hmmmmmmmmmmm, <error type=continue>?

I'm not aware of anything anywhere using type=continue, ever, in the entire history of XMPP.

I have found at least one client that does not display any hint that the correction stanza has been replied with an error, I think that's not good because I guess the stanza can have been rejected for another reason, so it would make sense to show in the UI that the correction did *not* work. I'll open a ticket :)

Yes, improve error handling!

I agree, errors are possible

Would <error type=continue> be appropriate for cases where you strip some extension and carry on?

What to do with errors as a client is *hard*.

What flow says :)

yeay \o/

yes. this "LMC error" case is indeed tricky. in general I find GUIs extremely hard to code, and user feedback about GUIs "surprising", so I'm not blaming anyone =)

Yep, I'm not saying it's not hard, just that it should be handled :)

since we're talking error handling, xep 0086 is "deprecated" but I still use https://xmpp.org/extensions/xep-0086.html#table-1 to decide error conditions and types. am I going to go the XMPP jail for this?

🚨️🚨️🚨️ GET THEM!

nicoco, yes, you should use RFC 6120 to determine those

If it matches, you're fine

or if you use common sense, you'll probably also be fine :)

Bookmark https://xmpp.org/rfcs/rfc6120.html#stanzas-error

If you use the 'code' attribute, go directly to XMPP jail, do not pass Go, do not collect compliance badges

Does /me usage get you a "get in the geek circle" card? :P

oh thanks for the link, this is a bit better than this obscure table. Some subtleties like difference registration-required and subscription-required are a bit confusing to me, but I need to read in details

no, just in the "old timer geek circle" (obviously)

btw, since we're mentioning error handling, slixmpp tends to create stanzas like this: ```xml <message xmlns=jabber:component:accept> <error xmlns=jabber:client>... ``` that's a slixmpp bug, right? no reason to switch to another namespace in the error, it should just be <error> here, right?

I'd say that's a bug yeah, maybe someone can confirm

Yes, a bug. The jabber:component:accept namespace has its own <error> (with exactly the same format as jabber:client)

> do not collect compliance badges :D

Unify the namespaces!

pep. this happens when I just `raise XMPPError('condition', 'text')` in a handler which is very convenient, but apparently does not handle the component case well. I tried to fix but got lost in low level stream stuff that I don't master at all. just saying that in case you want to have a look :P

I also probably don't have the knowledge to dig in there.. poke mathieui :x

Hehe OK, I will start by opening an issue I guess.

larma, moparisthebest, fyi biboumi’s limits aren’t in chars per messages, but in bytes per IRC command, which would make advertising that to the XMPP client very awkward. For instance, the recipient’s name is also part of the limit.

larma, another interesting use case I haven’t seen mentioned in this discussion is game MUCs, where it is an expected feature that not all users receive the same messages (or truth as you called it), and that your messages (e.g. “go left”) will get rewritten or even silently discarded (e.g. “your character went to the left room” from the narrator).

You can’t encode this kind of rules in a generic protocol.

Not sure what exactly a game MUC is supposed to be, but if it's not a groupchat, that usecase is totally out of scope of the MUC protocol

larma, https://en.wikipedia.org/wiki/MUD

It is a groupchat, just for a different usecase than what we’re using here.

Is it a groupchat or is it "you send messages to some server. multiple people are interacting with the same server to play a game"

Why does it matter?

I know text-based, dial-in multi user games, but I wouldn't consider this as a MUC

And that matters because you're complaining about MUC not being compatible with something that MUC is not supposed to be used for

Always trying to spoil our fun

If you'd implement this by just having a "bot" user, that people write and get messages with information about the other players, it would work as good without having any compatibility issues ✏

xmoo allowed you to navigate between "rooms" and the presence list would update according to who was in the same room

which you can also entirely do without MUC

presences work with normal users as well 😉

and without XMPP

larma, so if I wanted some groupchat-looking thing for my game I'd need to reimplement almost all MUC and not call it MUC?

Clients wouldn't render that, or I don't know what you mean

I mean I'm fine, we can have extensions on top of MUC that say "This is MUC+foo" and it behaves this way

In Dino and Gajim I can see the list of currently online devices

Not sure about others

pep., IMO the main idea behind MUC is "Send a message to the service, the service forwards that message (as is) to all participants in the room". If you're not doing that anymore, it's not MUC

MUCs modifying the messages that are sent to them is a very long-standing thing in XMPP.

Kev, this is not about what is a long-standing thing but what is a good idea 😉

Be it pastebins, security labelling, whatever.

There may be valid cases where special behavior of a MUC beyond forwarding are desired

but that's not what we primarily design the specification around

It's not, but it works fine with it.

Except when it doesn't

I mean, security labels and pastebin are probably not very invasive, so they're unlikely to cause big harm

But forwarding a message only to a subset of occupants or modifying it differently by recipient is going to cause trouble with all kinds of extensions we have in MUC nowadays that are designed around the assumption that this wouldn't happen

> Messages sent within multi-user chat rooms are of a special type "groupchat" and are addressed to the room itself (room@service), then reflected to all occupants. This is from the requirements of XEP-0045

Sure

FWIW in all this recent discussion about this kind of thing, I don't disagree much with what you've said

I'm the original author of mod_pastebin and a couple of other modules that do "interesting things"

I don't regret writing them, and many of them are innovative, fun and sometimes even useful

But if a client follows the spec, and doesn't work with them, I don't consider that a bug with the client

(beside my opinion about these things being not nice and also definitely not in the spirit of the spec, we should probaly improve support for these things in Dino for compatibility reasons)

If the module (unintentionally) doesn't follow the spec, it may well be a bug with the module

Sometimes we break certain rules on purpose - I'm pretty sure xmoo violated many sentences in XEP-0045. But it worked in practically all clients, and it was fun to build.

What's xmoo?

The pastebin thing... it worked because most clients do just have one hook that handles messages from the MUC, and they use this to update their display/history. I doubt it was even a conscious decision by many of them to treat the MUC as the source of truth, just a convenient implementation approach that avoids the need for tracking/deduplicating reflections. A number of clients didn't/don't work that way, and although it's inconvenient for a user of that module, that's not a bug in those clients.

pep., something like Link Mauve described just now, see also https://en.wikipedia.org/wiki/MOO

Ok

It relied on various non-standard behaviours that happened to work in clients. For example, messages from non-occupants, and messages from the room bare JID

E.g. you might type "stroke cat" and it would reply <message type="groupchat" from="room@server/cat"><body>/me purrs</body></message>

Pretty sure 45 allows messages from non-occupants, at least.

That's what the on-join history looks like, so yeah

""" an implementation MAY allow users with certain privileges (e.g., a room owner, room admin, or service-level admin) to send messages to the room even if those users are not occupants """

back to my boring namespaces issues, is there a list of cases where a component need to sends stanzas where some (direct or indirect) children elements have xmlns=jabber:client? everything's that "forwarded" has to preserve the original namespace and that's it, right?

If you're working out when you should rewrite namespaces to :component, I think the sensible rule is that once there is a namespace that isn't the root namespace of the stanza between you and the stanza root in the hierarchy, your namespace should be left alone.

Allowing out-of-room entities to send messages to MUC rooms can be ... tricky, implementation wise.

Kev: thanks. so I send from a client with <jabber:client> and then the MUC "echoes" my message but with <jabber:accept:component>, that's OK? same for MUC MAM or history-on-join, they have no reason to have jabber:client anywhere. I didn't have any trouble with this btw, but I'd like to avoid things that "accidentally work" and do things the right way =)

I don't follow the question, sorry.

nicoco, xmpp has the (IMHO) design flaw, that stanza namespaces are hop related and change during the transmission of a stanza. clients should always only see the jabber:client namespace for (top-level) stanzas

for example, if the muc is a component, then the reflected message will start with jabber:accept:component, when routed to the components server. if the server then routes the message to another server, it will have the jabber:server namespace, and if the final server routes it to the client, then the message will be under the jabber:client namespace

You should only receive stanzas in 'your' namespace. It's only a server that has to transform when switching between clients, servers and components.

right, the namespace transformation is only performed by xmpp servers (at least I can't think of a counter example) ✏

Yeah, here in slix it's just because it allows emitting multiple namespaces and does it badly

(client/component)

https://repology.org/project/libomemo-c/versions it's spreading

thanks kev and flow. I think there are some bogus jabber:client namespaced (non-top) elements in what slidge sends then. apparently it's not been a problem for clients to handle but I'll change that. I think the only case where I need to make sure I use xmlns=jabber:client is for "messages sent on behalf of normal xmpp accounts", as per https://xmpp.org/extensions/xep-0356.html#sending_mess

Inside the <forwarded/> should not be in :component, correct.

But every top level stanza you send, as a component, should be.

yes, for the top-level no problem, always :component. what about MAM replies? what shold message/result/forwared/message use? right now slidge does that: ```xml <message xmlns='jabber:component:accept'> <result xmlns='urn:xmpp:mam:2'> <forwarded xmlns='urn:xmpp:forward:0'> <message xmlns='jabber:client'> <body> ``` clients seem to be happy with that, but is that the *right* way?

Yes.

Probably easiest to always go with `jabber:client` in the inner forwarded. When would you ever forward a `jabber:server` or component message and who would care?

For non-specialist use, I don't think you would.

Zash, for when MUC has modified the message and thus is now no jabber:client anymore but :component :P

but for on-join history it has to be: ``` <message type="groupchat" xmlns="jabber:component:accept"> <body> ``` no client at all here

Because every stanza you send to the server from your component is in :component. The server then rewrites to :server or :client as appropriate.

I understand that the client will neven see this :component xmlns because the server will change it, but this is what slidge should send above, isn't it?

again, all of this seems to be working, but I'd like to avoid things working just because clients are tolerant, since they may stop at any point =)

You'd typically put the xmlns on the stream element for jabber:component:accept, and then not include a namespace on the stanzas, but the end result is the same, yes.

alright. thanks for your patience. in conclusion, my slixmpp hacks for what's inside forwarded were justified. good!

Kev, that's for the serializer to sort out, the applicative layer may require namespaces

In minidom (rust) we require that everything be namespaced for example, even though obviously we'll deduplicate where we can

Prosody also internally has no xmlns (or `nil`) on stanzas and rely on inheriting the namespace of the stream when sending them.

> In minidom (rust) we require that everything be namespaced for example, even though obviously we'll deduplicate where we can I know, I had to work around that issue just the other day.

issue?

I think it's a feature :P

Disallowing documents without a root namespace.

Yeah

Explicit > Implicit, but muh convenience!

I have specifically added a new endpoint for this that you may like

https://gitlab.com/xmpp-rs/xmpp-rs/-/blob/main/minidom/src/element.rs#L349

I'm not sure that helps me - it's not that my root was prefixed, it's that my root has no namespace.

Ah well

That's not a use-case for XMPP then

Not actually true, but it doesn't matter, I'm doing hacky string manipulation before feeding into the parser to workaround the issue.

Well if it were XMPP you'd have at least the None case with jabber:client or the like