XSF Discussion - 2023-07-28

I have a question that how to encrypt message in chat room？

高杰1510: what client

in the User Avatar XEP: > one of the formats MUST be "image/png" to ensure interoperability. Are there really devices/clients that only understand png and not jpg? Or am I misunderstanding what interoperability means in this context? Slidge is complying to that btw, but I realized that existing clients are largely tolerant to jpeg-only avatars, and I want to understand the rationale here.

PNG is better in every regard or not

And even back then it was widely adopted across the internet landscape

So why settle on somethin older?

JPG and GIF are from 1987, PNG 1995

Hum I just realized that PNG compression could be lossy, I didn't even know.

Thanks for the replies

"lossy"

"lossyish"

And please don't get the idea that the standard allows to publish multi format. This will not work. The XEP is a bit bad written in this regard.

https://xmpp.org/extensions/xep-0084.html#examples-multiple ??

I think XMPP should stick with MP3 and MPEG2, its goodenough and it was widely adopted across the internet landscape.

/s

I'm interested by your remark lovetox since offering multiformat was precisely what I had in mind?

nicoco: ah sorry it was multi size

So multi size for the same content type or something

Why not?

I can't go into it I'm on the phone

Multi-size is forbidden?

It's because of the metadatanode id

It's a hash of only one picture

Now you can think how that works for notifications

Clients will not pick up changes to the metadata node because the hash never changes

So yes you can put everything in there but don't expect it to work

It's simply not thought through and I'm sure it moved to stable before anyone implemented that part

To me that part looks fine

But the notification itself contains the different formats, so I'm not sure I follow? <items node='urn:xmpp:avatar:metadata'><item id="hash of the PNG"><metadata><info of the png version/><info of another larger png version/><info of a jpeg awful version/>

You can have a small mandatory PNG of 32x32 and then put the large format in JPG next to it no ?

And which client is it using uuid as metadata item id? ✏

edhelas: do you support multi formats?

The existing clients ones will pick the 32x32 PNG and the other ones can pick the larger pictures

Does anyone know of a client who does?

lovetox I don't, but I could

Yeah that probably everyone said 😜

I'm not even respecting the PNG format, I'm just pushing a large JPEG

I wait until someone has implemented it

Because large PNG are just too big, and compressed they look awful.

nicoco: anyway my advice is, publish a single picture

350x350 JPG 95 I do

Until you find at least a impl who supports that

For context, telegram always provides avatar as "large", "small" and "thumbnail", all jpg. Right now I convert to PNG and that's it, but I'm think I should also provide the 3 other versions since it does not even require conversion, just serving. Even though gateways shouldn't dictate our specs, it can be seen as a nice playground I think, so I'm inclined to do that, and I think edhelas wants to try with movim :). It would also make sense to provide a http url which I think no client use either.

HTTP URL can be cool as well, doing async avatar downloading <3

That would violate the standard

> where the "image/png" content-type is available only at the data node

No sorry

That's just a description of the example

Not a normative text

And it seems even wrong because the example offers the PNG over http

not wrong, there is also the "main" PNG without url in the exemple

but it's weird that there is another with the exact same "bytes", "width", and "height" but a different hash

>hierarchical and free for all are not the only choices though. a community can still make their space safe without having a single dictator or an oligarchy. you misunderstand, i'm talking for myself, and i said i have trust problems

i'm not putting words into anyone else's mouths here when i say what's on my mind for it

no selection of moderators makes me feel safer than an unmoderated room, thats just how i am

i hate power plays

it seems we are talking past each other because i didnt mention about any moderators needed. but anyway..

i cant know what you did mention, only what you wrote

but yeah like i said this is just me talking with my head in the clouds, it has no relevance to current xmpp

wrt Avatars: the document initally only allowed PNG, so it's required as the definitive version of the image; if there are multiple image formats, which one should provide the item id -- still the png version is definitive, so its hash is used; what if you have multiple png images of varying sizes -- only one can have its data stored in the node, and thats the definitive version

I was wondering if it could be possible to publish several avatars (as different items in urn:xmpp:avatar:metadata), then a use could upload several pictures on its profile

This could allow having a kinda "gallery" feature, same as Telegram

*user

I'm not saying it's impossible, but that was never intended in this case, and a new XEP would be advised

Thanks theTedd, I could not remember exactly what the problem was I just knew it had to do with the hash ✏

So this means one can provide all kind of format and sizes, but they all have to use different delivery methods like http

That's the idea, yes

Hm?

Hm hm?

Who says you can only store one item?

The intention was that you'd have one png version in the data node

They're referenced by the id attribute of the <info> element, what stops you from having multiple formats and resolutions?

The data node is identified by the item id, which uses the sha1 of the png version, even if other versions are available; you could add multiple data nodes, but they would be seen as separate images (different item id)

It would seem logical to me to store each image under the hash of itself in the data node, then reference them in the meta node by id.

Of course that would be logical, but that's not what XEP-0084 says 😋

Ah under https://xmpp.org/extensions/xep-0084.html#proto-data

Seems inconsistent with https://xmpp.org/extensions/xep-0084.html#proto-info then

On format notes: pretty sure Conversations often uses only jpeg for avatar. PNG is always going to look nicer of course, but for photos can be quite large.

Didn't it use WebP for a while? ✏

It can. That's a hard coded setting

> id A hash of the image data for the specified content-type

If you use the animated avatars support in cheogram Android it will use webp or gif also

The xep originally only support png/mng, and later extended to allow for others, so we could choose to see it as an editing lapse and 'fix' it 😉

> Of course that would be logical, but that's not what XEP-0084 says 😋 combined with people already violating the PNG-only requirement, let's change the XEP to make more sense? ↺

It's Stable, so as long as nothing breaks as a result, I don't see a problem

People publish JPEG without breakage apparently

Clients just take whatever is there, and of course they supprot jpeg

Anecdotally most clients seem to support webp and gif just fine too

not my experience with webp

Android clients will support webp since it's provided by the os, others may struggle

Anyone aware of a page like https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types but covering a wider (than browsers) scope?

https://en.wikipedia.org/wiki/Comparison_of_graphics_file_formats#Technical_details ?

I'm thinking of platform support

https://docs.unity3d.com/Manual/class-TextureImporterOverride.html#texture-compression-support-platforms ? Probably not :) I'm guessing you aren't gonna find that outside a particular standard or implementation

"Can I use" for XMPP!

> Android clients will support webp since it's provided by the os, others may struggle Any gtk based one too, so long as the webp decoder is installed ↺

That's not my experience at all, but that was from a few years ago.

When there were barely CLI tools available on Debian

Probably better now

I'd expect PNG and JPEG to work *everywhere* tho, so having some recommendation of having at least one widely-supported in a good enough resolution seems sensible

And put that <info> first for compatibilty

And then publish whatever formats and resolutions you want, within reason.

moparisthebest: monocles

+8K .dng for stills. +4K +120fps DNxHD/444 for flicks.

高杰1510: then you'll need to join or start a private chat then turn on OMEMO on that screen