jdev - 2025-03-08

i dont get this example https://xmpp.org/extensions/xep-0424.html#example-7 ✏

this is a tombstone, it contains a retracted element to make it clear this message has been retracted

and the id of that retracted element references what exactly?

Is this a forward reference to the message that retracted this message?

I think so yes, lovetox. ✏

weird stuff

> the original contents … get replaced with a <retracted/> element which MUST include an 'id' attribute that's set to the value of the retraction's <message/> element's 'id' attribute Maybe the wording can be improved. But either you already have the replaced message (so this tells you which to replace, by id) or you never saw it and won't receive it anyway because it was replaced

I'd like to brainstorm/rubberduck something with y'all. With XEP-0084 being stable, most XMPP clients don't try to fetch the avatar:metadata node. They expect to receive a pubsub event containing the avatar:metadata to fetch a contact's avatar if necessary. But in most other chat networks, you can actually see the avatars of your non-contact/non-friends.

To try and work that out in slidge, I used to send the pubsub event avatar:metadata, regardless of the roster subscription state. I disabled that behaviour a while ago, because it felt like a violation of PEP rules, and it made XMPP client fetch hundreds of avatars for contacts they'll never actually need the avatar for.

But I'm considering re-enabling this behaviour, to achieve "display avatar of non-friends" on the XMPP side. Is that bad?

One thing I've considered too, is that the avatar:metadata element could be included in messages and roster sub requests, just like the XEP-0172 nickname can be. This feels more reasonable, and is a mechanism that could be used in a "real XMPP" context too. After all, if I make my avatar public, I probably want to share it with people I send messages to, and moreso in presence sub request.

Sounds like XEP-0153?

that's tight to presence only though?

And vcard-temp

I guess that work for roster sub requests though

> that's tight to presence only though? ~tight~ tied to ↺

Something like caps for PEP?

not as sophisticated as caps

As in, we've been through a cycle of adding a ton of stuff to presence and then inventing PEP and Caps to reduce that

I think XEP-0172 does that right for nicknames

You can include it in message stanzas, which sounds sane. If you send a message to someone, you expect them to see your nickname, even if you don't want to be in each other's rosters.

There was, equally, including the avatar hash in messages

When was there this?

Before it became pep-based

And it was bad?

Including the avatar hash in messages is basically what I was suggesting, using the XEP-0084 <metadata> element

In presence, sorry -- it's all in 0153

Yes that is my point. We only have mechanisms in presences, but I think there are valid situations where you would want to include the avatar hash in a message, eg, when you send a message to someone who does not sub to your presence (and thus, someone who never gets your sweet PEP events).

But then _every_ message?

Maybe a "here is my avatar, if you care" message ✏

Hmm yeah, well that was basically what I was achieving by abusing PEP. AFAIR, all clients I tested with would just fetch the avatars when they received a `avatar:metadata`, and that worked in practice. Very suboptimal and "illegal", but it worked. Maybe the behaviour is actually not intended in clients though ^^

Maybe I should just go back to that behaviour, it was fine.

If you only send something the first time in "recently" someone speaks that's probably fine.

> To try and work that out in slidge, I used to send the pubsub event avatar:metadata, regardless of the roster subscription state. I disabled that behaviour a while ago, because it felt like a violation of PEP rules, and it made XMPP client fetch hundreds of avatars for contacts they'll never actually need the avatar for. This sounds like the best way, but probably only want to broadcast for ones they're likely to care about? ↺

Nothing says you can't send pubsub messages to non subscribers, just like any other message

Nothing says you can't send random garbage every 6 seconds, but

There's a bandwidth optimization thing that buffers recent presence until a message or someting relevant is sent, could follow similar behavior.

Nothing says you can't stuff your `urn:xmpp:avatar:data` full of image decoder exploits and spam everyone with notifications?

I agree with only broadcasting things you think someone wants to know, but if you know they subscribe to avatars generally and are getting a message from this person then you know they may be interested in this. And relatedly clients probably should not blindly fetch avatars they don't care about upon receiving an advertisement. That they do isn't really your problem (though reducing this by only sending ones they probably want is a sane thing to do, as I say) ✏

This is same as we do for nickname, pretty much

In practice no one cares if you say "you might not want to..." So just do it and when client users/devs get annoyed by the number of avatars they are fetching they'll fix it, this is how the ecosystem improves :P

> Purposely make bad choices to encourage others to come up with better choices

>> Purposely make bad choices to encourage others to come up with better choices 👍 ↺

I can imagine someone trying to run a country that way

Better to do it first ourselves rather than an attacker doing it ;)

> I burnt down my house before any else did it first

> be chaotic in what you do, be conservative in what you accept from others

-- pon Jostel

I mean it took us decades to figure out that was the correct way yes

https://www.rfc-editor.org/rfc/rfc8701 see

Thanks for the discussion. I'll return to that old behaviour, but not the bruteforce-stupid way it was, something smarter like only pushing avatars of non-friends who we actually talk to, maybe add some buffering too, etc.