jdev - 2023-04-07

https://wiki.xmpp.org/web/SRV_Records

the xmpp wiki does not mention xmpps records

lovetox, be the change you want to see in the world? ;)

im on it

There's https://wiki.xmpp.org/web/Tech_pages/XEP-0368 it could link to

From the history, it looks like the SRV Records page hadn't been significantly altered since 2015 when XEP-0368 was published

While you're in there, wanna delete https://wiki.xmpp.org/web/SRV_Records#TURN_SRV_records since we use XEP-0215 for that now? (I can do it otherwise, tho later to avoid editing conflicts)

Oh, STUN and TURN? All that can go

The Securing DNS page seems to have been lost. Anyone got any strong opinions on whether to restore it or drop the link from the main page?

Seems it can be recovered at https://web.archive.org/web/20160507033641/http://wiki.xmpp.org/web/Securing_DNS

Not sure the XMPP Wiki really needs to have a bunch of BIND documentation, surely there's resources elsewhere for that.

i added a link under external links

and added some examples for xmpps

i dont know what people usualy use as port for xmpps-server ✏

i did only the bare minimum, Zash you can have a go if you want

I've seen 5270 in a few places, like ejabberd config examples

Poof, gone!

lovetox, https://xmpp.org/rfcs/rfc3920.html#rfc.section.D.1

Does anyone know whether it's possible to have a different vcard per muc?

In theory? Maybe. In practice. Noe.

Squeaky Latex Folf, personal vcard?

Squeaky Latex Folf: it could probably be the MUC's server, like in a semi-anonymous MUC, the MUC server is the one that relays the vcard

If you're trying to separate identities, it's better (for many reasons) to use separate accounts for that

Not impossible at the protocol level, in fact, Prosody does it, but only in an all-or-nothing kinda thing.

As in, if you restrict your avatar / profile settings to contacts, non-contacts (including MUCs) will either see a limited vcard or an empty vcard.

Or what about avatars?

Separate accounts is far superior of course.

But having separate accounts just to have different avatars seems overkill for example

I don't think XEP-0153 makes sense in that case and it would be kinda complicated.

Having a whole protocol around supporting multiple avatars (why?) seems overkill

It's cool tho

Don't really need any new protocol for it, just new code

"just"

Yeah it's already theoretically possible

Yup

You used the word "just", therefore your statement is invalid. Try again :)

If you're just after coolness factor, nothing stops you from implementing something yourself.

I want to do at least granular vcard permissions eventually. Matter of priorities / making the time to write the module

If you're after opsec properties, separate accounts is the way to go.

Yes, for sure, if it's for persona

I for one don't currently feel like finding out what edge cases would pop up

MUC doesn't even support avatars actually :)

only legacy "temporary" vcards

just modify the MUC server's software to hijack the vcard-temp

for a user

You mean the users server?

MUC just proxies the request

that's the point

the MUC proxies the request

and you must send a different xep-0153 hash per aaaaaaaaaAAAAAAAAAAAaah

the MUC can modify the response

so, you could make vcard per muc a thing

But how would you publish a vcard per muc?

Squeaky Latex Folf: since this is a non-standard, that's really up to the MUC sysadmin and client to implement that

techmetx11: vcard per muc better done at your server than at the MUC server, I should think

singpolyma: true

Ad hoc command to configure ✏

» [17:02:08] <singpolyma> techmetx11: vcard per muc better done at your server than at the MUC server, I should think Nah it could be done at both ends

although that's kinda ugly

Squeaky Latex Folf: yeah, thats ugly

✏

send multiple vcards in one stanza

Sure, one could define a new custom protocol, but then you need client implemetation too and a xep eventually

It rather build on what exists first

If it were me, I'd do some hacky thing like use the sender JID as PEP item id. Or something.

While not arguing for anyone putting the time in, there are non-opsec reasons to do per-community avatars too. Like e.g. having community avatar match the ingame avatar that goes with the game for that community.

That’s one that I would definitely use on Discord if I paid for nitro. And one *could* use many accounts to achieve the same thing on XMPP, but it does seem unnecessary.

MIX and having some way to attach arbitrary per-user data, instead of wonky IQ proxy things? I'm all for it. Not going to put in the time for that today tho, sorry :)