XMPP Service Operators - 2021-04-20

Unless you run the server :)

... or get a bcc of all the o.j.n alert for that server in your inbox ;)

jonas’: any chance for a custom per-host timeout setting?

maybe upping it to 60s will get rid of most of the alerts? :D

ehh... yes probably

is a bit of development work though, and I’ll have to look into it closely

the entire stack involves a lot of regexes

vax.im?

hahaha

😢

:D

» <Ge0rG> jonas’: any chance for a custom per-host timeout setting? In prosody? I don't think so

That wouldn't fix the error 404 and 500s though

tom: yax.im is an xmpp server, where are you receiving 404s and 500s from?

Yes

No?

Ge0rG, reminer about code="" attribute on <error/> in RFC 6120

I said yes

When i try to join mucs

Medical Uterus Clefting

tom: could you please kindly provide a clear and concise error description?

Sorry is that not clear?

I could provide a screenshot

https://cdn.nuegia.net/6c996e18-c81f-45af-85e8-aae391cf2310/screenshot_005.png

This is all I see client side

tom: which date and which MUC?

also which time zone

Which muc is kind of sensitive i'd rather not say in public

Pacific

PST

Or PDT

tom: do you have raw XML of the errors?

Are those even from yax.im or from your server?

No, it doesn't happen predictably

My server doesn't use error codes

Not that i'm aware of

I thought that was a legacy thing

Yes, error codes are a legacy thing. Are you using a legacy client?

No

Are you using pidgin?

No

What *are* you using?

isn't this some kind of Psi derivative?

So we have a legacy error message with zero details from an unknown source at a time where only the minute is known. This is not something I can debug, sorry, tom

404 seems to be a legacy mapping of "server not found", but it lacks detail on which server misses which other server.

Psi+

Psi+ is not a derivative of psi it's the rolling release version

Well, `code` is RFC3920 and has been deprecated in 2011.

You might want to raise this issue with the psi+ developers

> Yeh, Psi+ supports a lot of deprecated things and does not support some of new ones... 🙂

I wish there were more people to help rion

It's a lot to implement a committee's standards all on your one

It's a one man show?

yaxim is a one-quarter-of-a-man show, and it manages to show readable error messages.

To he fair he got more noise in his issue tracker.

Yeah but it doesn't support nearly as many features, and it's not a computer program it's an app

It’s 2021 and there’s still mo reliable XMPP client on iOS.

yet :)

s/mo/no

Tell me more :)))

to be fair, there have been over the years but Apple keeps silently changing things to break them

antranigv: the clients are reliable, when opened in foreground...all are...but...

Snikket iOS + Snikket server works fine when it's in the background :)

(*small print: except MUC) ✏

It's one of those "XMPP on iOS would be great if only it could <X>"

and as soon as you implement X, it becomes Y

It'll end at Z?

It will cycle to AA, AB, AC, ... like Excel

It will end at message bubbles

Message Bubbles. The most anticipated feature of yaxim!

MattJ: last time I checked the X Y and Zs were really basic stuff like getting messages when not using the app (aka push messages) or MAM being disabled by default

Both of those are fixed in Snikket iOS

Just today in a german MUC: People won't use xmpp as it doesn't have video messages and a/v conferences…

Does the client have to reconnect to the server on every open?

octagon, on iOS, yes

But Snikket on iOS is Snikket not "XMPP on iOS" in my books (as you can't use it with any JID)

Because it requires the host server to connect to apple pn?

octagon, when an iOS app is not in the foreground it is completely stopped by iOS, there's no way to stay connected. So to receive messages it needs push notifications (via Apple), and it needs to connect to the XMPP server when you reopen it

that is awful aggressive

It's what's "best for users"

Apple knows

The same goes for Android where Google has the same kind of component (using FCM).

There are more workarounds on Android (at least currently)

MattJ: > Both of those are fixed in Snikket iOS Enough slimy marketing!!1!

> Does the client have to reconnect to the server on every open? Monal does, Siskin doesn't.

Martin, other way around?

and technically Monal does reconnect, but it resumes the same session

so if an iOS XMPP client could keep the underlying connection open across being killed, that would improve things quite a bit ?

It would, but the point is that it can't :)

it can... with QUIC :)

If the app is killed, it's not running, it can't react to incoming traffic

What you're proposing is essentially resumption at a different layer, right?

yes, still would need the push notification to wake it up, but resumption should be significantly faster

and where is the traffic stored while the app is not running?

how's that different from smacks resumption

I think XMPP-over-QUIC is interesting, and I'm glad someone is experimenting with it, but I don't immediately see it as a solution for this problem

I can't help to notice that you've drunk some serious QUIC kool aid moparisthebest :)

eta, you just don't have to do any of that, no new TCP/TLS negotiation or anything, you just use the already-open QUIC connection you already have

moparisthebest, right, but the problem is that you can't suspend a connection forever because that uses RAM etc. on the server's end

(especially since it has to queue up messages)

same with smacks I guess, just a different level, you still need push notifications etc certainly

:3

Who is running XoQ?

Wiktor, I just think it has some real efficiency benefits especially for mobile XMPP, where jumping between networks and sleeping happens constantly

> Message Bubbles. The most anticipated feature of yaxim! What's this now?

XMPP handles that really well with smacks etc, but it's much better to just stay connected

moparisthebest: but but but... It's a Trojan horse from google! Like... Like chrome!

yea... I think they did bad by keeping the QUIC name, that old bad google-QUIC is dead, this is good ietf-QUIC

> Martin, other way around? Was thinking about push. 😂

moparisthebest: quic is in userland. your quic session is as dead as the normal tcp xmpp session would be when iOS kills the app.

jonas’, you persist the state to disk ?

on every packet you send?

then you don't gain anything, you can do that with tcp/sm already.

moparisthebest, I mean, sure, with persisting QUIC state (if that’s a thing which is possible), you might also gain avoiding redoing the TLS handshake. but persisting stream management is much harder, and when you lose that state.... you are faced with much worse than TLS roundtrips (presence and pep floods)

so for the iOS use case, I don’t think that quic buys you all that much

iirc the app isn't simply killed right? it's told to save state and turn off?

I’m not sure about that

I’m no iOS dev, but what I hear sounds more like SIGKILL than SIGTERM.

I think stream management works still? this is simply a shortcut

if indeed that happens then yea this fixes basically nothing

Office hours starting in 10 minutes; this week is an intro to the protocol if any operators want to learn about what's going on under the covers of the servers they run! Office Hours starting in 10 minutes! https://socialcoop.meet.coop/sam-pku-dud-niv

dinner time

moparisthebest, stream management does generally not work because you don’t get woken up often enough to keep the SM session alive

> Office hours starting in 10 minutes; this week is an intro to the protocol if any operators want to learn about what's going on under the covers of the servers they run! Office Hours starting in 10 minutes! https://socialcoop.meet.coop/sam-pku-dud-niv I wish, but work. Will it be recorded?

Yes

Awesome

> MattJ wrote: > octagon, when an iOS app is not in the foreground it is completely stopped by iOS, there's no way to stay connected. So to receive messages it needs push notifications (via Apple), and it needs to connect to the XMPP server when you reopen it This is why we can't have nice things. Too much malware and badware doing bad things. Only one allowed to spy is the manufacturer and "they're concerned about privacy". Plus, I'm sure it makes fruitco look good on battery life and lower device temps.

It sounds like a good idea for your average shady, tracker-filled proprietary application but, it also significantly reduces the capability of your phone to be used for communication.

thndrbvr: it's not about that, that's just the superficial upfront public excuse. It's about artificially gimping anything that could compete with facetime unless you pay off a bribe in private which only other bigtech corporations can afford

Classic anticompetitive move

Like back when Micro$oft vs Stacker Electronics would use undocumented entrypoints into the OS because stacker wouldn't sell them their technology

And then sued any company also using those undocumented entrypoints into the os boot to implement transparent disk compression