XSF Discussion - 2017-03-10

Good morning! Looks like a server restart.

moparisthebest, XEP vs RFC - Maybe, if you want to go that route. Or maybe we'll consider this when we revise RFC 6120 again - that might be more sensible.

Hm. 0045 needs a sentence that MUC services MUST send presence-unavailable to all participants on shutdown

That's not practical :)

You can try best effort, but if you're in the middle of shutdown you're unlikely to want to wait for slow S2S links to establish.

Kev: not practical indeed, but if the s2s link is there already, sending a bunch of packets over it is not that bad.

Kev: and irregardless of that specific proposal, the MUC XEP sorely lacks some kind of "am I still there" detection

shouldn't a ping be enough to detect if you're still there

Tobias: you need to ping yor own participant JID, and some MUCs block that.

Tobias: besides, my point is that such a mechanism should be described in 0045, and not passed from one generation of xmpp developers to the next as cautionary tales.

and this MUC has significant lag today, is xmpp.org DDoSed?

Server load looks largely ok.

PHP's using more than I'd like, but yeah.

Oh, interesting.

Prosody keeps spiking to 100%, and then going down again.

my prosody is experiencing a large number of failed login attempts for a week now.

27 IP hops between yax.im and xmpp.xmpp.org, but that shouldn't matter too much.

+1 on writing things like self-ping down in the XEP

test?

Ge0rG: test?

test!

mimi89999: test failed. server lags.

It's quite fast...

mimi89999: now it is. But I wrote my "test?" some minutes before it appeared in the MUC

OK...

Ge0rG: it just wanted your test to be as leet as possible :) -> (13:37:01) Ge0rG: test?

Actually even before I pinged Kev over in jdev@ (which was reflected at 13:34:36). And I see my message in here at 13:37:02, so that's around three minutes of lag.

🤓

U+1f913

jonasw: yeah, that.

xsf@muc.xmpp.org responded to ping after 4.955 s

I know, pango shows it when it doesn’t find a font with it

It does seem to be Prosody that's eating all the cPU.

PHP a chunk, but Prosody the bulk.

if only prosody had some useful monitoring mechanisms.

24,000 auth attempts in the last 6 hours for C2S.

xmpp.org doesn't do c2s

It does for Memberbot, right?

Could make it listen only on loopback or something tho

Sorry. I don't mean c2s is disabled, I mean there are no user accouns.

memberbot is special, yes.

31.13.144.33 seems to be the main culprit, I guess we could firewall that off.

good luck sending abuse mails there :>

Prosody's logs don't seem to be good enough to tell, but I reckon these are trying to iq:register spam accounts.

Kev: and bringing down the CPU?

*shrug*

hmmm… has anyone thought of implementing XEP-0184 (message delivery receipts) with MUC? I mean in the sense that the MUC itself supports them and sends back the <received/> element if requested. It could advertise that in its features like any other entity supporting that protocol. It would allow clients to request receipts from the MUC, solving that "how do I track my message in the muc problem" without breaking backwards compatibility.

jonasw: Yes, have thought of that.

Also "handling" chat states in MUC, such that the MUC would keep track of who wants them and filter them out for others.

Zash: only thought of that? why not implemented? any other concerns except time?

Time and motivation.

jonasw: re 0184: you'll be better off with sending a unique ID and waiting for that to be reflected, unless you are not inside the MUC. And in the latter case you are f'ed anyway

What Ge0rG said. But better make that a client-id. Because some servers change the message id

And instead of fixing those servers we have invented [xep 359]

Ge0rG: fixing those servers?

daniel: the ones that rewrite message ids on reflection

Ge0rG: where does it say I server is not allowed to do that?

BTW, who's going to Chemnitz this weekend?

Ge0rG: me

daniel: right. Instead of fixing xep 45 and those servers.

daniel: yay! See you there!

I mean the real fun begins when servers strip everything but the body

And change the message id

daniel: and replace the body with a pastebin link

Even more fun

MUC is FUBAR.

daniel, Ge0rG, me too, want to meetup somewhere?

There is not a single element in a reflected message that can be used to determine if this was YOUR message

Are we having fun yet?

(very obscure cultural reference)

Let's change 0045 in an incompatible way.

and call it MIX

jonasw: sure. I'm mostly going to hang around the chaos computer club Saxony booth. So come meet me there

ah right

need to stop by there anyways

Let's found the German MUC Sabotage Cabal there!

Fatboy Slim is not obscure if you're from the 90's!

(although admittedly, I had to think about why that sounded familiar for a minute…)

SamWhited: what about Zippy the Pinhead?

Ge0rG: Can't say I've ever heard of that one

If we only knew WHICH obscure cultural reference daniel was talking about...

huh, TIL, didn't know that apparently was even earlier than I thought

Ge0rG, daniel: FWIW I'm convinced that it's correct to rely on the 'id' attribute in MUC, and any server that modifies it is totally wrong

MattJ: tell that to the MIX people

I know the XEP doesn't forbid it, but that was an oversight because nobody thought a server would do that, I guess :)

Fwiw I don't know of a server that still does that

jonasw, I'm afraid I don't understand

MattJ: no, even the example is doing it. Also, there are xsf members who insist that it is correct and desirable behavior

Because I'm starting to despair at MIX, every time I look in on it

The one implementation I know changed that at some point

Ge0rG, the only vocal XSF member I know that was for it, changed their mind, afaik

I've tried to get the example in 0045 changed some years ago and was argued down

MattJ: feel free to bring it up again! 😀

Even if we get it through, it will come with a "note: you MUST NOT rely on this working"

MattJ: Despair that MIX will ever be finished, or do you not like the protocol? If it's the latter I'd love to know what works/doesn't work from your perspective as a server developer.

Like #436 does now

Ge0rG: XEP-0045: Add <x/> tag to MUC-PMs #436 https://github.com/xsf/xeps/pull/436

(a mailing list post about the server developers perspective on MIX would be *very* helpful, I think)

SamWhited, both. It seems to me there's a lot of the second-system syndrome going around, and when I heard that it now requires the user's own server to implement new stuff to work, it discouraged me from even trying to catch up on the latest developments

MattJ: MIX explicitly specifies that the server re-writes the ID and also provides (only in the message to the original sender) a <submission-id/> element which carries the original message ID

MattJ: Ah, yah, that one bothered me for a while too and I'm still a bit torn about it; Kev more or less convinced me that it was necessary for any new MUC protocol, but I do still have a vague unease about what it will do for adoption.

MattJ: please read MIX. it became much better in the 0.8 revision and I think it can be improved with respect to your concerns. I cannot provide that input because I don’t know the server side.

Ok, since you asked nicely :)

I got halfway or something

(and I think MUC can use a replacement)

I had to sit down two or three hours straight to read it and take notes for possible improvements, but it was worth it I think.

I think MUC could use a simple replacement

Define simple?

Something that doesn't require three hours to read? :)

Read faster :)

maybe it wasn’t three hours ;-)

anyways, heading out, cya

Maybe we can get someone with a very calming voice to do an audio book version of the mix xeo

+1

Dramatic (or calming) readings of RFC's and XEP's would be a fun podcast…

Someone get David Attenborough on the line!

And Morgan Freeman!

That sounds like you want to sugar coat the long tedious text.

dwd, "when we revise RFC 6120 again", is that any time in the nearish future?

define "nearish" ✏

Some time in the next decade?