XSF Discussion - 2023-07-13

XSF folks at FOSSY: anyone want to grab food/beer?

Sam: ossguy and I are at the sustain oss event at hey love ✏

I'm not familiar with them, but I think they're the folks doing an interview with me tomorrow morning

Hi, what happened to this ProtoXEP? Did it ever get voted to get a number, or rejected, or what? https://xmpp.org/extensions/inbox/muc-avatars.html

2018-10-05 6) AOB Link Mauve queries the status of the MUC Avatars proto-XEP (https://xmpp.org/extensions/inbox/muc-avatars.html); Kev notes that it had three +1s, and Sam vetoed on-list.

Kev, no, this is after 2023-02-15.

Now that it is on the Historical track.

Following https://github.com/xsf/xeps/pull/1269

Ah. So needs to go back to Council then.

Speaking of which, Sam, do you agree with this PR? https://github.com/xsf/xeps/pull/1279

Council for https://github.com/xsf/xeps/pull/1278

Link Mauve: oops, missed that somehow. Yah, that's fine by me. Thanks.

Very interested in the veto

Gajim implements the muc avatar xep and it's the right solution in my opinion

I'm not sure anything based on vcard-temp can be "the right solution" but maybe an expedient one sometimes

I find it curious this xep says you need to be joined to get a muc avatar in the currently deployed way. Can vcard-temp not be fetched from outside? I would expect it could

singpolyma, MUC is based on presence, you can’t send an iq to a “participant” who isn’t currently joined (they aren’t a participant in that case), nor if you aren’t joined yourself (unless the MUC is configured to let you do so).

Link Mauve: this is for the muc itself though, not a participant?

singpolyma: only the upload mechanism is vcars temp and for that it is good.

This xep allows exactly what you asked to fetch the avatar while not joined, like all other MUC infos ✏

lovetox: but I think we already can with what we do today?

No

The xep claims we can't

But I can't think of any reason why

singpolyma, where does it say that?

Link Mauve: in the intro when talking about why this xep exists

Section 2 says “Let users discover the avatar even when not present in the MUC.”

singpolyma: are you saying you can invent a not documented protocol which would allow you to?

Anyway. In either case if we were going to change current behaviour why would we not change to pep avatar rather than speccing a custom thing for MUC?

singpolyma, ah, third paragraph of section 1, that’s the limitation of using presence instead of disco#info.

lovetox: I'm talking about the currently in-use protocol for muc vcard

Therr is no documented protocol in use

singpolyma, the historical track is for documenting existing protocols, which haven’t been through the standards process but are widely used.

You claim vcard-temp is undocumented?

singpolyma, usage of vCard-temp on MUC is documented only in some Ejabberd tutorial.

And in the vcard-temp xep

Is it?

How is it not? Is the protocol different in some way I have missed?

singpolyma: it's not about vcard temp storage

It's about the distrbution

The disocvery

singpolyma, the only mention in XEP-0153 is that you can query other participants’ vCard-temps.

It doesn’t mention anything about the rooms themselves.

Which is what this ProtoXEP aims to fix.

You can query the vcard-temp on any jid. A MUC has a jid. The fact that it's a MUC shouldn't affect the protocol?

It's not about the query again

singpolyma, and if you read my ProtoXEP that’s exactly what it describes.

Link Mauve: but then why does the protoxep say we need this new protocol in order to get the avatar for a room we have not joined? That was my question

And if you read the XEP it does not change anything about the query

singpolyma, it isn’t about joined or not joined, is it?

If you disco#info the room you get the hash of the avatar, so you know whether you support it already or not, because otherwise you have to always fetch the avatar of every room you come across whether they changed or not.

It can make a lot of traffic on each client’s startup if the user has a lot of rooms.

Ok, I think I see what I misunderstood > Some implementations recently chose to advertise those avatars using the existing vCard-Based Avatars (XEP-0153) [2] extension in <presence/>, but it exposed issues in other implementations, and was only available when the user is already present in the room, not before joining it (for example when listing all available rooms). Sounded to me like "was only available" was referring to the avatar, but in fact is referring to the extension. ✏

singpolyma, it refers to section 5.2.

Any suggestion as to how it could be formulated better?

I am also curious how a new protocol nt yet in use can be "Historical" but I don't care much about that and I certainly agree if anyone implements it it should be considered almost as though historical so I kinda get it

singpolyma, Prosody already implements it, under the {http://modules.prosody.im/mod_vcard_muc}avatar#sha1 field var instead of the proposed muc#roominfo_avatarhash though.

Link Mauve: maybe it could say "exposed issues in other implementations, and this extra metadata was only available after joining the room" I think something like this is more clear than "it"

Prosody and ejabberd also implement the xep-0153 way that caused trouble for some clients, but if you're thinking "a jid is a jid" then that's that and no further xep is needed, and the prosody ways is not needed.

It's about the discovery of the hash

Of course we need a mechanism

And presence is a bad one for a muc

Right you only get it by joining with the 153-only method

We need to disco mucs anyway, and the best way is to add it there

Plus MUC alrady had that notification message for configuration change

advertising the room avatar hash in the disco info of the room, I didn't know this was a thing in prosody. any clients use that yet?

Gajim?

Yes you can test it on the muc join dialog nicoco

cool, so something like `<field var='{http://modules.prosody.im/mod_vcard_muc}avatar#sha1'><value>thehash` in the extended disco features?

Yes you can check disco info of the prosody muc

Right here too. :)

Zash, missing you at Fossy. Will you go next year?

Across the pond? Unlikely

Ah