XSF Discussion - 2021-05-07

Ge0rG: would you be interested in doing an Office Hours about the traffic you've seen on your server due to Vaxbot and how you monitor / resolve it? Doesn't have to be anything formal, just a quick talk about how your monitoring setup works and some of the things you've tried to do to keep the service stable

Just something along the lines of your blog post

> Ge0rG: would you be interested in doing an Office Hours about the traffic you've seen on your server due to Vaxbot and how you monitor / resolve it? Doesn't have to be anything formal, just a quick talk about how your monitoring setup works and some of the things you've tried to do to keep the service stable > Just something along the lines of your blog post I have also seen the question or more an offer of another server admin to spread the load via his server.

The deployment worked finally: https://xmpp.org/2021/04/newsletter-04-april/

marek: I'm interested in a server provider offering IBR without captcha as a fallback server.

Hello and good Friday ❤️ The XMPP Newsletter on April has been published - again it would be fine if one could make a tweet based on this: https://fosstodon.org/web/statuses/106195170518281226

251

4

'*

Kids or cats?

please forgive me :/

my kid

:D

so XEP-0352 doesn't give any indication (pun intended) of what stanzas should be dropped, which should be delayed, or really anything else in the implementation right?

XEP-0352 is not about dropping, delaying or anything else, no

shouldn't that be defined in places other than various server implementations ? :/ (they also don't seem to remotely agree)

It's purely a signal to the server about the client's current state

moparisthebest: please read the servers and write an Informational XEP

What servers do with that info is their business. If you want to try to spec some optimizations, go for it :)

I hate all these hand-wavy "implementation defined behavior" XEPs.

there are, eh, semi-security considerations that exist with these implementations

maybe not security, but I don't know how else to say it

I think it'd be easy to regularly send silent stanzas to mucs and drain everyone's battery

moparisthebest: you can do that without any XEPs.

but you can't document that in XEP-0352 because it doesn't say you should do anything at all

What would you even document?

There will always be stanzas that need to be forwarded

probably advice for both servers and clients

stanzas with bodies will be displayed, not silent, no big deal

and optimizations will only help, they're not the problem here

Pretend 352 doesn't exist, and servers have no optimisations. The same silent stanzas will have the same behaviour...

stanzas with https://xmpp.org/extensions/xep-0380.html with an unknown type might be simply dropped by clients, but forwarded by servers, that's a silent battery eater

so the advice would either be for servers to drop ones without valid formats, or for clients to always display something on such a thing

If silently wasting battery is an attack, then let me tell you about xep 199

:)

yes, that too, the advice for that would likely just be don't have mucs forward that, do they now ?

You can't broadcast iqs, but MUCs would usually forward those sent to occupant JIDs

... to the full JID

Unless it's one of the special iq stanzas that get redirected to the bare JID

Unless it's not implemented like that and instead the server handles full JID iqs

Unless ...

so what we need is a bot that can join MUCs and do everything that can possibly eat all the member's batteries silently? :)

challenge accepted!

Please include OOB URLs to infinite HTTP streams

that's probably interesting outside of MUCs too, probably all sorts of silent stanzas you can send to a known JID constantly

ooh nice MattJ

like an http server that responds to HEAD requests with an endless stream of random headers ?

That's actually perfectly legal.

Thanks HTTP!

IIRC the standards-mandated limits are ... per header...

the question is how does your average HTTP library handle it

OOM on sight

I'm going to assume most of them handle it by eating memory until they explode

Probably. You go have fun now. 🙂

( echo -en 'HTTP/1.1 200 OK\r\nConnection: keep-alive\r\n'; while true; do echo -en 'bla: bla\r\n'; done ) | nc -l 8080 -w 1

command line curl handles it fine by buffering nothing I guess

and to test servers: ( echo -en 'GET / HTTP/1.1\r\nHost: www.moparisthebest.com\r\nUser-Agent: curl/7.76.0\r\nAccept: */*\r\n'; while true; do echo -en 'bla: bla\r\n'; done ) | nc -4 www.moparisthebest.com 80

nginx responds with 400 Bad Request "400 Request Header Or Cookie Too Large"

pro-tip: `nc -C` if you have a version with that flag

to translate \n → \r\n

I never know if a given machine has BSD or GNU nc :(

moparisthebest [20:49]: > stanzas with https://xmpp.org/extensions/xep-0380.html with an unknown type might be simply dropped by clients, but forwarded by servers, that's a silent battery eater I'd love to have a server side filter that would drop all elements not listed in a client's disco features

Ge0rG: I tried something like that, tho it may have involved filtering stuff from presence. Vague memory of it causing breakage.

I wonder how many stanzas clients receive in practice that they ignore, or at least end up invisible to the user

Very many

If you're in a bunch of public channels, oh so much presence

I need to install that prosody CSI module that just drops presence on the floor

Violates protocol and expectations, not recommended

what prompted all of this was a person complaining in a muc about how much battery his conversations used, I counted that I'm in 53 mucs and mine hardly uses any battery, but there are so many things it could be I don't even know where to start

Tho maybe that got fixed so the dropped stanzas don't count in 198

moparisthebest: and did they check that CSI is enabled?

yes but they use ejabberd, which at a glance does entirely different things than prosody's mod_csi_simple

I constantly suspect conversations uses more battery than it lets on

IIRC the most common wake up reason for me is client activity in the form of periodic pings, and their responses

it seems like the battery % android gives is utterly dependent on your rom, vendor, version, the color of the sky, and everything else too; but that's a different can of worms

the issue I have is I suspect conversations is waking up for every irrelevant MUC message

I've got a thing for that, so I can mark MUCs as "unimportant" and then those won't trigger CSI flush

I would like to have that tied into Something in the future, possibly some bookmarks2 mini-extension.

Zash: I saw that module, but it requires manually marking them all as unimportant

I want them to be like, default unimportant

(and important if it's a modern XMPP "groupchat" instead of "channel")

eta, you and me both

the latter part requires more trickery though

But I'm told this doesn't work for Normal Users

I've also done the radicalish thing of using bookmarks2 everywhere

with hacked up Dino and conversations

If there were a way to distinguish "groupchat" from "channel" based on only the stuff you see on join... but you don't afaik

yeah exactly

well, no, invite only is a good one

but I guess that's in data forms

which would require that the module do a disco, which is certainly possible, but complicates it a bit

hence trickery

but that may not be a perfect method either

how easy is querying bookmarks2

I mean, basing it only on whether a particular MUC is "channel" or "groupchat", but it could certainly be used as a default.

Some property saved by clients in BM2 would be nicer.

Zash: I have a conversations commit that saves such a property :p

Neat

mainly because I got tired of having to reconfigure notification prefs

when it used to eat the database

this required patching Dino to not instantly clobber the property when the bookmarks change

Why not using mentions of the nickname if there is a body, or EME otherwise

Private rooms will all have OMENNO, right?

Ge0rG - no one apart from the Germans will understand your OMENNO 😉

> Private rooms will all have OMENNO, right? Not sure if subtle joke or autocorrect 🤔

sebastian: yes

> sebastian escribió: > Not sure if subtle joke or autocorrect 🤔 subtle German joke 🙂