-
Arne
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!
-
Ge0rG
Arne: I can do that, please also send me your email address via DM
-
Arne
Ge0rG it's arne-bruen@monocles.de thanks
-
Ge0rG
Arne: > The user account for Arne (talk) has been created.
-
Ge0rG
please check your inbox (and spam)
-
Arne
Received. Thanks!
-
nicoco
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>
-
MattJ
What's the benefit?
-
MattJ
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
-
nicoco
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)
-
nicoco
I agree that there is no point, I was just trying to think what the "least confusing UX" could be.
-
Zash
Hmmmmmmmmmmm, <error type=continue>?
-
Zash
I'm not aware of anything anywhere using type=continue, ever, in the entire history of XMPP.
-
nicoco
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 :)
-
Zash
Yes, improve error handling!
-
MattJ
I agree, errors are possible
-
Zash
Would <error type=continue> be appropriate for cases where you strip some extension and carry on?
- flow assumes that many clients are not properly reporting xmpp-level errors to the user (for example, because it's hard to do so, without confusing the user)
-
Kev
What to do with errors as a client is *hard*.
-
Kev
What flow says :)
-
flow
yeay \o/
-
nicoco
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 =)
-
MattJ
Yep, I'm not saying it's not hard, just that it should be handled :)
-
nicoco
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?
-
Zash
🚨️🚨️🚨️ GET THEM!
-
MattJ
nicoco, yes, you should use RFC 6120 to determine those
-
MattJ
If it matches, you're fine
-
MattJ
or if you use common sense, you'll probably also be fine :)
-
Zash
Bookmark https://xmpp.org/rfcs/rfc6120.html#stanzas-error
-
MattJ
If you use the 'code' attribute, go directly to XMPP jail, do not pass Go, do not collect compliance badges
- Zash hides the util.error `code` support
- flow hands out "get out of xmpp jail" cards
-
pep.
Does /me usage get you a "get in the geek circle" card? :P
-
nicoco
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
-
flow
no, just in the "old timer geek circle" (obviously)
-
nicoco
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?
-
pep.
I'd say that's a bug yeah, maybe someone can confirm
-
MattJ
Yes, a bug. The jabber:component:accept namespace has its own <error> (with exactly the same format as jabber:client)
-
wurstsalat
> do not collect compliance badges :D
-
Zash
Unify the namespaces!
-
nicoco
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
-
pep.
I also probably don't have the knowledge to dig in there.. poke mathieui :x
-
nicoco
Hehe OK, I will start by opening an issue I guess.
-
Link Mauve
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.
-
Link Mauve
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).
-
Link Mauve
You can’t encode this kind of rules in a generic protocol.
-
larma
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
-
Link Mauve
larma, https://en.wikipedia.org/wiki/MUD
-
Link Mauve
It is a groupchat, just for a different usecase than what we’re using here.
-
larma
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"
-
Link Mauve
Why does it matter?
-
larma
I know text-based, dial-in multi user games, but I wouldn't consider this as a MUC
-
larma
And that matters because you're complaining about MUC not being compatible with something that MUC is not supposed to be used for
-
MattJ
Always trying to spoil our fun
-
larma
If you'd realize 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✎ -
larma
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 ✏
-
MattJ
xmoo allowed you to navigate between "rooms" and the presence list would update according to who was in the same room
-
larma
which you can also entirely do without MUC
-
larma
presences work with normal users as well 😉
-
Zash
and without XMPP
-
pep.
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?
-
MattJ
Clients wouldn't render that, or I don't know what you mean
-
pep.
I mean I'm fine, we can have extensions on top of MUC that say "This is MUC+foo" and it behaves this way
-
larma
In Dino and Gajim I can see the list of currently online devices
-
larma
Not sure about others
-
larma
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
-
Kev
MUCs modifying the messages that are sent to them is a very long-standing thing in XMPP.
-
larma
Kev, this is not about what is a long-standing thing but what is a good idea 😉
-
Kev
Be it pastebins, security labelling, whatever.
-
larma
There may be valid cases where special behavior of a MUC beyond forwarding are desired
-
larma
but that's not what we primarily design the specification around
-
Kev
It's not, but it works fine with it.
-
larma
Except when it doesn't
-
larma
I mean, security labels and pastebin are probably not very invasive, so they're unlikely to cause big harm
-
larma
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
-
larma
> 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
-
MattJ
Sure
-
MattJ
FWIW in all this recent discussion about this kind of thing, I don't disagree much with what you've said
-
MattJ
I'm the original author of mod_pastebin and a couple of other modules that do "interesting things"
-
MattJ
I don't regret writing them, and many of them are innovative, fun and sometimes even useful
-
MattJ
But if a client follows the spec, and doesn't work with them, I don't consider that a bug with the client
-
larma
(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)
-
MattJ
If the module (unintentionally) doesn't follow the spec, it may well be a bug with the module
-
MattJ
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.
-
pep.
What's xmoo?
-
MattJ
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.
-
MattJ
pep., something like Link Mauve described just now, see also https://en.wikipedia.org/wiki/MOO
-
pep.
Ok
-
MattJ
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
-
MattJ
E.g. you might type "stroke cat" and it would reply <message type="groupchat" from="room@server/cat"><body>/me purrs</body></message>
-
Kev
Pretty sure 45 allows messages from non-occupants, at least.
-
Zash
That's what the on-join history looks like, so yeah
-
Kev
""" 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 """
-
nicoco
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?
-
Kev
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.
-
Zash
Allowing out-of-room entities to send messages to MUC rooms can be ... tricky, implementation wise.
-
nicoco
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 =)
-
Kev
I don't follow the question, sorry.
-
flow
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
-
flow
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
-
Kev
You should only receive stanzas in 'your' namespace. It's only a server that has to transform when switching between clients, servers and components.
-
flow
right, the namespace transformation is only performed by xmpp servers (at least, I can't think of a counter example)✎ -
flow
right, the namespace transformation is only performed by xmpp servers (at least I can't think of a counter example) ✏
-
pep.
Yeah, here in slix it's just because it allows emitting multiple namespaces and does it badly
-
pep.
(client/component)
-
qy
https://repology.org/project/libomemo-c/versions it's spreading
-
nicoco
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
-
Kev
Inside the <forwarded/> should not be in :component, correct.
-
Kev
But every top level stanza you send, as a component, should be.
-
nicoco
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?
-
Kev
Yes.
-
Zash
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?
-
Kev
For non-specialist use, I don't think you would.
-
pep.
Zash, for when MUC has modified the message and thus is now no jabber:client anymore but :component :P
-
nicoco
but for on-join history it has to be: ``` <message type="groupchat" xmlns="jabber:component:accept"> <body> ``` no client at all here
-
Kev
Because every stanza you send to the server from your component is in :component. The server then rewrites to :server or :client as appropriate.
-
nicoco
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?
-
nicoco
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 =)
-
Kev
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.
-
nicoco
alright. thanks for your patience. in conclusion, my slixmpp hacks for what's inside forwarded were justified. good!
-
pep.
Kev, that's for the serializer to sort out, the applicative layer may require namespaces
-
pep.
In minidom (rust) we require that everything be namespaced for example, even though obviously we'll deduplicate where we can
-
Zash
Prosody also internally has no xmlns (or `nil`) on stanzas and rely on inheriting the namespace of the stream when sending them.
-
Kev
> 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.
-
pep.
issue?
-
pep.
I think it's a feature :P
-
Kev
Disallowing documents without a root namespace.
-
pep.
Yeah
-
Zash
Explicit > Implicit, but muh convenience!
-
pep.
I have specifically added a new endpoint for this that you may like
-
pep.
https://gitlab.com/xmpp-rs/xmpp-rs/-/blob/main/minidom/src/element.rs#L349
-
Kev
I'm not sure that helps me - it's not that my root was prefixed, it's that my root has no namespace.
-
pep.
Ah well
-
pep.
That's not a use-case for XMPP then
-
Kev
Not actually true, but it doesn't matter, I'm doing hacky string manipulation before feeding into the parser to workaround the issue.
-
pep.
Well if it were XMPP you'd have at least the None case with jabber:client or the like