XSF Discussion - 2017-10-22

regarding message routing 2.0: can't we just make servers to always carbon messages to local users?

so if there is user@server/r1 and user@server/r2, then a message to user@server will be routed to r1 and r2, as well as a message to user@server/r1 will be routed to both r1 and r2

Bare JID routing like that is already allowed. Full JID forking would be problematic.

Zash: yes, no problems with bare JID routing, but what problems do you see with forking?

Non-chat messages basically.

example?

IBB file transfer, MAM responses. Basically stuff that maybe shouldn't have been messages to begin with, but we don't have a generic non-message payload container.

what about using 'no-copy' for them?

Don't you also get roughtly the same behaviour if all clients just always send chat messages to the bare JID?

yes, but what to do with old clients?

Will old clients add 'no-copy'?

What about old servers?

and what's wrong with them?

also, it's server responsibility to add no-copy for MAM messages

> can't we just make servers [do stuff]

what

what

old servers will monkey with carbons, like it is now

I haven't looked too closely at message routing 2.0, but something that boils down to having carbons enabled by default is probably fine

I don't think these new rules affect s2s

or MUC, or whatever

so the idea is: 1) upgrade your server to always fork 2) upgrade mam module to inject no-copy 3) disable carbon module

ah, 2nd is not needed, the messages are local anyway, the server can detect it's a MAM message and won't carbon

Except MAM-MUC

no-copy in this case indeed

Tho Prosody doesn't carbon type=normal messages unless they have a body, and MAM payloads don't

I also don't see major difficulties if clients will receive forked mam messages

as well as ibb

sure, it will consume bandwidth, but not fatal

Most of those problems are actually avoided by only carboning type=chat or ( type=normal with body )

maybe

And no-copy for when that doesn't work

like OTR

But old clients using OTR doesn't add no-copy, so yay

is it a problem?

I mean a user will experience something weird?

or is it just traffic problem?

I don't know, never used OTR

OTR not doing well with multiple clients can most likely cause weirdness

same here :D

receipts are of type normal, hehe

Are they? Not the same type as the message being acked?

Chat states are weird.

Zash: I just grepped 'type' in receipts XEP and didn't find any mention about it

Needs clarification perhaps?

or maybe it's described in other words

regarding chat states: "This protocol SHOULD NOT be used with message types other than "chat" or "groupchat"

"The 'type' attribute for content messages and standalone notifications SHOULD be set to a value of "chat" (for one-to-one sessions) or "groupchat" (for many-to-many sessions)."

I'm thinking to implement this stuff on my local server to check corner cases

I'm going to write another mail to standards@ about how broken message type is. Acks and CSN are on my list

Also the problem is not carbons, the problem is rerouting of full JID messages to a different client if the first client just went offline

Carbons have their own, related problems, but the current carbon rules are so vague that even an ancient transcribing monk would fulfill them.

https://xmpp.org/rfcs/rfc6121.html#rules-localpart-fulljid-nomatch all this?

Zash: yeah. I was told that ejabberd will violate that and reroute 'normal' messages as well, because they are used by many clients instead of chat.

I believe Prosody does so as well

Zash: could you check the code please?

https://hg.prosody.im/0.10/file/0.10.0/plugins/mod_message.lua#l72 https://hg.prosody.im/0.10/file/0.10.0/plugins/mod_message.lua#l34

TL;DR full jid messages to an non-existent resource are treated exactly as bare jid messages

normal and chat types are treaded the same

Zash: and headline will be sent to all resources?

headline to bare

Yes

Headline to non existent will be sent to bare, then to all.

Right-o

Yay for standard compliance.

I think the changes we're talking about should be atomically applied to the server

so we fix all issues in one go

zinid: there is no easy fix.

why would we bounce messages if they are already forked?

Bounce = ?

re-route

or maybe that's not the same as bounce

I'm lost ;)

Please state the nature of the technical emergency.

you're so funny

I know 😛

There is forking, rerouting and carbon copying. And then there is MUC that sends a new messages that might or might not have the same properties as the message you sent to the muc

what's the difference between them?

forking is creating exact duplicates as I undersand, unlike carbons with wrappers

and what is re-routing? I cannot find it in the RFC

> If there is more than one resource with a non-negative presence priority then the server MUST either (a) deliver the message to the "most available" resource or resources (according to the server's implementation-specific algorithm, e.g., treating the resource or resources with the highest presence priority as "most available") or (b) deliver the message to all of the non-negative resources that have opted in to receive chat messages.

" that have opted in to receive chat messages"?

I didn't get it

Have sent presence that doesn't have priority with a negative value

So basically that part is redundant with "non-negative resources"

ok

so the RFC allows to fork by default?

Sounds like

so nothing should be changed ;)

Everyhing is fine.

It depends on message type.

Zash: you can't quote only one of the four relevant sections and claim everything is fine!

I just did!

Damn. It looks like you can. But I won't let you get away with it!

there is weird shit in ejabberd regarding this re-routing thingy

fixed by 6 contributors

In my understanding, rerouting is when a message to a full JID is sent by the server to a different full jid

yes

8.5.3.2 from the RFC

That is only allowed to happen with type=chat messages.

But the servers violate it

ejabberd applies the same rule for chats and normals

from what I understand from the code

Yes, because some clients send 'normal' and users complain if the messages don't arrive

other message types are dropped silently

You should send back errors, that helps kicking out zombies from MUCs

for groupchat?

or both groupchat and headline?

It shouldn't hurt for all of them

Except error of course

I'm not sure, the last rules were written by Holger

I think he did that on purpose

so need to ask him first

Can we take a moment to complain about Github sending markdown as "text/plain"

He changed back normal rerouting. It was disabled for a short time and people complained

Zash: stop derailing

Aw

ah, groupchats are bounced indeed

only headlines are dropped

wonderful

Good enough

Did ejabberd drop the thing where it expects the receiving server to fork PEP notifications?

Zash: no idea :) I never wrote routing rules for ejabberd :)

Or was it that it expected the receiving server to filter?

Sending to the bare jid and having the receiver fork and apply filters would have been neat, if negotiated.

yes, ejabberd expected remote servers to filter peps, but we was severely blamed for this and removed it

but I still think it's much better idea than collecting caps from whole world

Zash> TL;DR full jid messages to an non-existent resource are treated exactly as bare jid messages < that breaks biboumi direct messages iiuc :(

But maybe I should see first why it doesn't get a unavailable presence

pep.: my opinion on that is that IRC and XMPP bridges are inherently impossible to get right.

Zash: that's a problem with all gateways, that's why I stopped fiddling with them

Well here prosody is not following the spec, or did I get that wrong? ✏

Uh, to many contexts at the same time

But those are chat messages, correct?

yes

And chat messages to a non-existent full JID are to be sent to any available resource according to the RFC.

hmm, ok I got it wrong then

pep.: I've changed my comment on #3304 recently

I see. So my only hope is for biboumi to catch unavailable presences?

From these resources

pep.: RACE CONDITIONS!!1!!

Why are computers borken like that :(

Because they consist of a dozen abstraction layers piled up on a little brick of sand

Tons of legacy crap

Tcp, ipv4, and so on

so much for poezio reconnecting

dwd, not in open_chat?

(I've asked a _very_ intelligent question there)

-certinfo muc.xmpp.org

Testinator: muc.xmpp.org has an untrusted certificate that expired 13 hours and 42 minutes ago issued by Let's Encrypt Authority X3

Ping intosi, other iteam people. Cert alert!

other iteam people: please educate me

zinid: Our routing rules should be fully 6121-compliant by now, with the one exception that type=normal messages to an unavailable full JID are rerouted rather than bounced.

zinid: We had one release that bounced them as per 6121, users went nuts so we reverted this.

Holger: got it

FWIW, I don't get the "opt in" part here either: "(b) deliver the message to all of the non-negative resources that have opted in to receive chat messages."

If it was just about non-negative priority then the "opt in" part of the sentence is totally redundant?

Whatever.

> Most of those problems are actually avoided by only carboning type=chat or ( type=normal with body ) Nah, this goes wrong in many places.

Holger woke up :D

:-)

Regarding XMPP 2.0 (or what's it called?), it's not important but I would find it most intuitive if all messages to bare JIDs were forked (regardless of type) and all messages to full JIDs aren't. I.e. the bare JID addresses the account, the full JID the client.

I think we should skip 2.0, and move on to 3.0 directly.

3.0 is matrix?

so we should skip to 4.0

This will only replace carbons if outgoing messages are also forked, of course.

XMPP 17.10.

3.0 is we get rid of the RFCs and just declare that everything is pubsub!

SamWhited: But pubsub isn't turing complete…

we need to use blockchain to be modern enough

Aware of Ethereum smart contracts?

those with 200Gb ledgers?

great technology

You're forgetting, storage space and RAM are free and infinite. My computer science education told me so.

Let's rewrite xmpp as a Turing machine

Also the entire world has 10 gig internet connections. These are facts that modern technologists know.

Ge0rG: with actual physical tape!

SamWhited: gaffer tape?

To make the messages stick!

SamWhited: I'm reading at the moment the paper where they achieved a great performance of blockchain within 100 nodes :D Cutting edge science

The B in blockchain is for bullshit...

Holger, department of redundancy department indeed

And let's skip to XMPP 2000

didn't we pass this already?

the current state is ICQ2001b

-certinfo muc.xmpp.org

Zash: Host unreachable: remote-server-not-found

How is that possible?

Ah, trailing whitespace