jdev - 2023-02-15

is it useful for a muc service to include `<c ...>` (XEP-0115 (caps)) in participants presences? in other words, do clients care about participants disco features in MUCs?

Sometimes, e.g Swift used to warn if not everyone supported message corrections

I see. I wonder if it's worth the extra complexity (OK it's not *that* complex in theory) and the extra bytes in the presence stanzas for me to add that. One good reason to add it though, is that in my MUCs, all participants are going to have the exact same disco features, so for clients that are interested in participants disco features, it sure would reduce traffic by a lot.

No client other than https://migrate.modernxmpp.org/ supports Moved (0283) atm right?

Actually I think even that one doesn't 🤭

heh

On the to-do list

But as that client was written for a server that was shutting down imminently, Moved wasn't a priority

Technically it doesn't even do 0277, since there's nothing for a client to do atm :x

*227?

It does do that, since it lets you download as a 227 XML file

Yeah 227

But yes, 227 is not a protocol, but a data format

Ah ok, right, after getting vcard and roster the usual way

How does one go with a 227 file? They ask their new operator to import it manually? ✏

Snikket allows importing a file as part of account creation (in the web UI)

Only for stuff that's replayable by a client right? As discussed in prosody@ the other day

Would be nice to add that to migrate.modernxmpp.org too

(That is, not MAM, and maybe not PEP entirely)

Ah in the Web UI

Yeah, the web migrator actually doesn't export MAM either currently (somewhat intentionally)

Snikket's web ui has server access so it's easier there

But yeah basically one needs to ask their operator

Either the history is OMEMO-encrypted, in which case it is usually useless, or it's unencrypted and then I didn't want the liability of having chat history in plain text XML files

Some people might be fine with that (even desire it), but most people probably wouldn't realize

and then they might send it to some operator via email for import

It's not even clear that MAM can be truly imported on JID change. It would require some hacking, and I know it wouldn't be compatible with some Prosody storage backends

if you wanted to preserve ids, that is

If you don't preserve ids, you'd potentially have other problems on your hands :)

So yeah, I decided migration of MAM wasn't worth it to most people

Maybe there should be a note left in the spec? :/

Yes, possibly

about the id thing, for example

Re OMEMO, yeah most of the archived wouldn't be readable, expect maybe for the last few that haven't been decrypted yet

But then, would a client reuse keys from a different account..

Ok so no client implement 0283 so far?

And no client other than migrate.modernxmpp.org implements importing 227

snikket web portal

client?

kind of :-)

(It's been mentioned above)

it is technically a client, albeit using REST for XMPP instead of an XML stream

Ok I thought it had access to server API somewhat directly (maybe with some auth token)

no it doesn't

we decided against that

upon login (or registration) it obtains an auth token for your user and stores that in a cookie

and it uses that to do things as your user, so basically it is an XMPP client

Go tell that to the Matrix People, you're using HTTP+JSON :P

Here, we can boot Matrix already

no, it's HTTP+XML, mostly

hah

like in the 00s, but dirtier ("without soap")

https://github.com/snikket-im/snikket-web-portal/blob/master/snikket_web/xmpputil.py if you want to see all the glory of the XML stanza composition, or https://github.com/snikket-im/snikket-web-portal/blob/master/snikket_web/prosodyclient.py#L246 if you're more into the API interaction itself

And apart from Snikket and migrate.modernxmpp.org? Anybody else? :x

Client DOAPs say no..

nicoco, please also include XEP-0390 caps, this isn’t used by most clients yet but will eventually.

pep., none that I'm aware of

https://codeberg.org/joinjabber/support/issues/7 I just opened this re account migration

And now I can restart my browser.. that was the one tab preventing me to do so (hanging form)

Link Mauve: well, I should make 0390 a slixmpp plugin then. I confess everything disco/caps related in slix is not very intuitive to me yet (it's a bit better than a few months ago though =))

about the infamous room "avatar"s… from https://docs.ejabberd.im/tutorials/muc-vcard/ and https://modules.prosody.im/mod_vcard_muc I gather that vcard-temp (XEP0054) is the way to go. is there a reference document about how the protocol works *for room avatars*?

nicoco, what you linked and XEP-0054 is all there is

I once wrote a XEP, but it got rejected.

nicoco, https://github.com/xsf/xeps/pull/700

Oh, right, XEP-0153 too

Basically just the same procedure, but with the MUC JID instead of your account.

Perhaps I should resubmit it as historical.

Link Mauve, yeah, resubmit it

I think the decision to reject it was among the worst

right next to the XHTML-IM thing

I think so too.

OK lemme just shout my questions then :) 1.which entity should advertise support for 'vcard-temp' in their disco features? the muc service (whatevs.example.com)? the room (room@whatevs...)? both? 2.besides replying to iq/get/vcard, how does the room tell the clients 'hey, I have an avatar, you should fetch it because it's nice'? 3.about XEP-0153 `vcard-temp:x:update` when does the muc send a presence from its bare JID? on join, the muc send presences for participants, but for the room (ie, the bare JID) there is no presence to be sent, or is there?

And here I've been trying to move to XEP-0084 everywhere, but nope, vcard-temp is eternal and forever

nicoco, "yes", best of luck! :)

Zash, at least if it was documented that would be less bad imo.

Speaking of which, this list decision never happened: I thttps://github.com/xsf/xeps/pull/760

The rationale for the rejection was that there are already too many XEPs about avatars. ^^'

so, I'll just try to send ```xml <presence from='room@component'> <x xmlns='vcard-temp:x:update'> <photo>somehad</photo> </x> </presence> ``` along with the presences from participants, on join, is that the correct way to use XEP-0153 in this context!?

it feels weird because AFAIK the room never sends presence with from=the-room-bare-jid, or does it? it feels like I'm missing something here

somehad=somehash*

nicoco, yes, it's awkward, it even broke some clients that did not expect such presence

But users want room avatars!!!

I am a user and can confirm this

Poezio still displays room presence in the InfoBuffer just like other users... We should fix that someday

oh ok, it's akward but the way to go then. I'm a bit worried about annoucing support in disco#features because I moved to PEP Avatars for the contacts and hope that clients won't expect vcard-temp for contacts now… I'll do some testing I guess. thanks for the replies

jonas’, Zash, nicoco, https://github.com/xsf/xeps/pull/1269

looks less awkward than what I am hacking right now, I'm reacting with a thumbs up