XSF Discussion - 2023-03-02

That looks cool

fwiw, i have their arch, pmos, and fdroid polo shirts

It's a neat idea. The logos are quite small and the shipping to Canada is unsurprisingly atrocious, so probably not for me heh

They have zip up hoodies and non white t-shirts, I'm in

$20 for shipping a $58 sweater from EU to US, that might be ok

Yeah, the $20 isn't great but then next to it it says usually $60 lol better get it quick!

quality costs money

go to zazzle to get your cheap logo-wear

;)

here's a shirt: https://store.manutd.com/en/manchester-united-cup-home-authentic-shirt-2022-23-long-sleeve-with-rashford-10-printing/p-1270583536005267+z-900-264030590?_ref=p-ALP:m-GRID:i-r0c0:po-0

Daniel I've updated XEP-0425 and marked it removed the "Draft" status

I'll look at the feedback for XEP-0424 some other time. Back to work...

I start to have some performance/bandwidth issues with base64 avatar download, especially with gateways (that can bring MUC with hundreds of new avatars), not sure if there's some good solutions there :/

Don't download them / not all at the same time? You're only getting the hash first right? It's up to you then to download or not

slidge is the new official XMPP client stress test :P. edhelas you could open an issue so that slidge provides avatar via http too, since XEP0084 allows it? but if it's for xep-0153 avatars, well, no luck.

pep. That's what i'm doing, comparing if I already have them then sending them into a download list

But I still have to receive/handle hundreds of base64 PNG/JPG files somehow, in the XMPP pipe

nicoco, that'd be giving out Movim user info to a third-party. That's actually one of the nice things with Movim, it acts as a proxy

edhelas, a common optimisation I see clients for other protocols do, is to only download avatars, names, etc. when they are in view of the user.

Leaving a spinner in their place before that.

pep.: not necessarily? that would only be the case if we use 3rd party "legacy service URLs" as avatars sources, but slidge also acts as a proxy by downloading them and serving them via pubsub. for attachments slidge relies on the presence of a http server on the same host; it could also use the same "path" to provide downloadable avatars.

or maybe I misunderstood what you meant?

nicoco, how do you deal with the unknown time limits of these services?

Hmm ok yeah if slidge acts as the proxy. But hmm really, if Movim doesn't manage that many avatars I wonder how the server does it (or it's not really comparable?)

Link Mauve: it's different for each service. some libs handle avoiding rate limiting automagically (implementing retries with random delays). for others I just accept that avatar fetching sometimes fail :). it has suprisingly not been that much of a problem for avatars which are often just publicly downloadable URLs that don't seem to be rate limited. if they have an etag I cache them on disk anyway, so that probably helps.

jcbrand: there is no protocol for emoji reactions on emails, so I'll 👍️ here for taking my suggestions into account for XEP-0425. Thanks!

You can always use the fallback, "> [the whole email]\n👍"

(not)

I think the fallback is "👍\n[the whole email thread]"

I must have missed the update clarifying this behaviour

I'm pretty sure it has always been this way, but you're on a newer version of email than most people

thanks nicoco

Because it messes up the order in which people normally read text. Why is top-posting such a bad thing? Top-posting. What is the most annoying thing in e-mail?

I am sad to report that that fight was lost, it's simply impossible to do proper quoting in Modern Email™ clients.

Also in Outlook.

ralphm, it works here because most XMPP clients will display text top-down :P

edhelas: something I do in a few places is throttle such a fetch list to only send the requests one at a time or two at a time or whatever and a small wait before the next one. That way you don't starve yourself while fetching

What's the biggest bottleneck for you? Simply decoding base64? I wonder if there's also some work you can background to make it not as big an issue ✏

singpolyma yes I can delay that, I was more talking about the base64 itself inside the XML stream

I'd prefer to have for example a way to request those things outside of the XML stream, HTTP or something else

I guess that makes sense in a web client. I'm working to move more stuff *in* to the XML stream usually

Open a secondary stream, don't send <presence>, but send potentially heavy but low-priority things there?

Hm, wait, can't do MUC with that

If stanza parsing is the bottleneck I guess throttling the fetches is probably the biggest help

Optimization tips: Don't For experts only: Don't, yet

> Optimization tips: > Don't > For experts only: > Don't, yet 😄

https://sure.im:443/upload/c7e68ac3-d17c-4b5a-9686-2aff889fdf35/7cxpn1.jpg

I don't know if anybody did it before, but I replied to Masum Nishat who emailed standards@ with an implementation question, to suggest they come on jdev@.

i love XMPP

https://carlschwan.eu/2023/03/02/digital-market-act-workshop-in-brussels/

^ interesting summary of the DMA workshop

Oh that's a nice summary :)