Modern XMPP project discussion - 2021-12-05

Zash, just because im reading the old history in this room

about XEP0084

it was not created with the goal in mind to publish the same avatar in multiple sizes

what it specifies is that you can publish the same avatar in multiple content-types

but only image/png, can be in pubsub

the rest needs to be added with alternative methods like https links or whatever is allowed

you can't stop me from publishing multiple resolutions!

why though, why would i not download the highest resolution one, and scale it to whatever i need as client?

why would you, when you could not

save the bandwidth and storage use until it is needed

the logic you would need for that is not worth the 2 seconds more for a higher resolution

you cant just say as a client i need 100x100 pixel

it may be more than 2 seconds on a GPRS mobile link

you need to ask, on what monitor am i, do i have high dpi?

what reosolution does the user operate on etc

then it goes furter, do i display this avatar in different sizes in the UI?

in roster its small, so i need a smaller one

in profile window its big so i need a bigger one

you can invest months into adding this logic only to determine what avatar you download, and the user does not even see the effort or value it in any way

you didnt spend your time to actually make a useful thing for the main goal of your application

that is communicating with other people

if it unblocks the mobile link, sure.

you just invested months into a 40x40 avatar picture somewhere on the side on the screen

(also, months? wtf…)

yeah months, and it will be buggy, and not even work on all operating systems

and you will draw in dependencys only to get the needed infos from your system on all os

and you are the first human who ever invested that time into an avatar, and nobody will ever know

because nobody cares really

you don't care ≠ nobody cares

Ok.

not worth the effort in a desktop client with broadband ≠ not worth it

Product vs protocol: probably a product would store every avatar in two standard sizes, and that's that

The smaller size would be enough to display as a thumbnail in/beside a chat or in the contact list. The larger one would be used only when viewing the user's profile

yes MattJ but i download the higher one, and scale it myself to the smaller one

because i need to scale anyway

because nobody will publish in the size i need to display anyway

If the high one is high-res (photo, etc.) that download and scaling *can* be costly multiplied by contacts and time

but it is not costly, scaling on any machine is only a fraction of the time a download needs

and we are talking about small resolutions here

like <400x400 max

What's the guarantee you'll have a 400x400 max picture

the standard who says dont upload big pictures :D

and the size attribute in the metadata, who tells me what i dont want to download

the standard that says you must upload 64x64px png, but gives you a way to communicate the size and the type?

and does having only 64x64px png seem like a Modern thing?

no i agree there probably should not be a size mentioned

just a guiding value

64x64 is definitly to small

on highdpi with scale 2 thats like almost an icon

or i have to scale it up and it looks shitty

Maybe standards have to be updated with the fashion of the moment

(*surprise*)

It's the kind of thing that if we don't get into a XEP, should definitely have recommendations on modernxmpp.org

but i would offer a option to download no avatars at all for the user, if he is on a link where this can be a problem

lovetox, image bombs are a thing, where the file size is small but the resolution is very high, burning through a lot of computation when you do your scaling.

because many small avatars is still much traffic

It might not matter on a big powerful modern desktop computer, it will on a not-so-modern mobile device.

I'm thinking publish a scaled something reasonable + original as alternative format.

Link Mauve, thats sad, but still i need the resolution i need in my gui, and not the one someone publishes an avatar for, so no scaling is not an option

Zash, whats you idea behind that?

like you want to save people data with your avatar

or what?

you cant even know on what machine, in what UI they look at it

every size you think is ok, might be shitty for them

we would have to make some vote under the clients, what the ususal avatar size is they need

to determine "reasonable"

*at the time of voting

And for the type of clients voting*

in Gajim i upload avatars at 200x200

if the original picture has that of course

“13:32:44 lovetox> because many small avatars is still much traffic”, btw, do you have stats about the bandwidth required by the various features in different usecases?

Like, for avatars I’d assume that’s mostly a one-time download, afterwards it will get cached, so it’s not that much worth optimising for.

of course not, but yes would be interesting, measure MAM vs Avatar download on MUC join

etc

Even if you have a shitton of contacts, the download will only happen either when you add them, or when they update their avatar.

Ah right, MUC as well.

yes, thats what im saying, its not worth to put any work into this logic

i download the highest and im fine

Well, first connection is still a thing.

It gives the first impression of your software.

yeah, thats why i have for avatars a queue

so it will need some minutes to download 100 avatars

also so joining mucs is faster

because most avatars are via vcard request

if you join a muc with 300 people and you send 300 vcard request, this means you join the other mucs slower

if you join a MUC with 300 people and all of them fetch your vcard, that's a pile of traffic for the MUC and your server

Is your queue priorised? So that when the user scrolls in the participants list you will move downloading the visible avatars to the front?

Zash, if it became an issue, the MUC service could cache the response. ✏

haha Link Mauve, no

lovetox, also I’ve seen people use services like Discord or such, where the list of users is so long they don’t download anything not in the view.

yeah that depends on the capabilities of your framework

It makes it feel pretty slow ime, but optimises away most of the traffic until it is needed.

GTK 4 supports that. :)

alone the work to get the info "whats currently in the view" is not an easy task in gtk

Gtk4 supports not drawing whats not in the view

wasn't that the thing GTK4 has magic to do for you?

lovetox, even not having widgets for those.

its great that GTK4 has some new things which are welcome

And recycling widgets which moved out of the view for the ones now in the view.

but look at the gtk4 issue tracker

shit is broken all around, basic things dont work

Oh really?

like im notgoing to migrate to that in the next year

its a small project, they have view developers who added a bunch of new things

I haven’t had any issue with it so far, after I finished fixing its GLES 2.0 backend for my phone circa GTK 4.2.

and now we can wait for them to find the time to make them stable

so yeah, gtk3 has issues, but im not ready to trade them against other issues :)

especially if i know other messengers, from companys who pour in millions into the development

Ok, well, have fun then. ^^'

and i dont see them perform any better

Cross UI Frameworks on desktop are a compromise

but yeah that gtk4 feature to draw only whats on screen is badly needed

in Gajim we have logic, to unload much stuff, or otherwise the client will get laggy

lovetox: BTW, on the topic of Gajim and modern XMPP, do you think it's a possibility for OMEMO to merge into core or at least be enabled by default?

And is there an issue about it sending the first couple of messages in plaintext even when enabled?

omemo has to be enabled for every chat specifically

and no if you enable it, its not possible to send a message unencrypted

at least im not aware of any bug there

what probably happens is, people download the plugin, enable the plugin, and now think everything is encrypted

I see

they probably miss that the need now to enable it in the specific chat

enabling it by default, is an open improvement issue on our tracker ✏

i just didnt have yet the time to do it

Good to know, thanks

on Windows the plugin is packaged, and enabled by default

so i dont see much difference to it beeing in core

and on debian for example it is also automatically installed if you pull "recommended" packages

That's the difference with it being in core though; some OS's (Arch in particular, Debian as well but they provide an easy way to install at least) won't install any plugins by default and people don't know they have to go install them separately

Other OS's take the approach of bundling sensible defaults.

Having it in core means you don't have to rely on their policies, they'll all just have the sensible defaults you pick.

Sam, ArchLinux very much assumes the user will read the optdepends when installing a package.

If the user doesn’t do that, they probably should use a different distribution.

Link Mauve: yes, that's my point.

Sam, usually if something new comes up, and its not sure if its something the community needs, we implement it as a plugin

later if its clear that it something that everybody uses now, we move it into core

plugins also let you faster iterate

and its not something the core maintainers need to look at

also it gives contributors and easy way into the project, implementing something of use, without going into broad discussion with the core maintainers if this is something we need in the core ✏

lovetox: yes, I know, I was suggesting that it might make sense to have this in core now (or as a bundled plugin, doesn't matter, just "shipped with core" however you do that).

you mean the current version, or the one the XEP describes but almost nobody has implemented :D

but yes omemo has become a wide implemented thing right now

it makes sense to consider it core of a client