XSF Discussion - 2018-09-19

https://xmpp.org/extensions/xep-0084.html#proto-data Why does it say > The XML character data MUST represent the image data for the avatar with a content-type of "image/png"

Are you not allowed to put other kinds of image data in <data>?

no you’re not

other images are supposed to be delivered via other means

the pubsub thing is supposed to contain image/png always

That does not seem to reflect current usage at all

yes

it’s daniel’s fault

It's not my fault that the xep says png for no reason whatsoever

Not no reason, tho it is overly strict in restricting it to only PNG. JPEG and GIF are well-supported enough to be ok there.

can't wait for animated gif

Please don't

Everyone has realized that GIF is a terrible video format by now

Zash: but it's too entrenched.

Ge0rG: But "GIF" now means "looping audio-less video"...

In your opinion, does/should XEP-0030 support unregistered values for Disco identities (category/type), possibly using Clark's Notation, and falling back to the registry for unqualified values (like XEP-0068 does)?

Do you really have something that isn't already covered?

or is this just a "I need to identify my thing" requirement?

Well, the use case is different types of user accounts: regular people v.s. e.g. agents of a commercial entity.

So for the former I can use account/registered, but for the latter, I'd need something new for the type field.

And while I appreciate we have a Registrar function for this in general, having a capability to achieve distributed extensibility using Clark's Notation would be nice.

MattJ: ^

If you really think that's the best option for you, I don't think it's not allowed

I meant, the XEP explicitly says it is "preferably" a registered identity

*I mean

and if you're going to go for something unregistered, Clark's notation makes sense

For me on my own self-hosted server, it's is a bit weird to call my account 'registered'

Tho there is also admin IIRC?

Zash: the idea here is that you can see who's the admin of a server, so you'd probably have two identities: one with `registered` and one with `admin`.

MattJ: right. Any other ideas?

I'm probably _also_ going to add a Data Form (XEP-0128) for additional meta-data, but it felt wrong to put this information there, if there's the nice concept of identity already.

ralphm, I think your approach seems fine, though if it's also a registered account I would include the standard identity also

So clients can still get an idea of what it is, even if they don't recognise the non-standard one

There's also stuff you can stuff into the vcard for this kind of thing, altho that's a bit more directed towards human consumption

MattJ: for sure

Zash: well, vCard is kind a set in stone. It is not really extensible.

Or at least our use of what became known as vCard-tmp

vcard4!

ralphm, fwiw, I suggest to have account/registered *plus* the account/{private-namespace}agent tihng

for compatibility

But I mean like the 'role' field

jonas’: yes indeed, just like MattJ said :-D

Zash: I guess. Still feels like a hack

Do clients ever change the list of PEP nodes subscribed via +notify filtering during a session? I mean if they didn't, servers wouldn't have to bother with caching the +notify caps and could just auto-subscribe based on the caps sent with the initial presence (or am I overlooking something?) ...

Holger, "do they" vs. "could they"?

Well if they don't, 0060 could be adjusted. In theory.

Holger I'm not doing it on Movim

I mean right now the design is "auto-subscribe the client to all open PEP nodes, then filter based on +notify". That's somewhat complex/expensive compared to "auto-subscribe based on +notify".

Prosody dynamically adds and removes subscriptions based on +notify

That's somewhat expensive as well ...

And right now the idea is that a client sending presence to a single contact on my server will change the behavior of all PEP nodes on my server, no? Though seems even less likely that clients will depend on that ...

Can someone even explain to me the different between "auto-subscribe + filter w/+notify" vs. "auto-subscribe w/+notify"?

*difference

The XEP makes quite sure to get this point across, but what is the practical difference?

The server auto-subscribes on *initial* presence. Due to the filtering semantics, the server also needs to check all following presence.

How do you handle following presence that doesn't contain caps? Unsubscribe all PEP nodes? (Doesn't happen in practice?)

ECaps2 adds the concept of sending the caps only on initial presence, the server advertising to the client it will add it on all subsequent presence changes.

I don’t know of any server implementation though.

Also 0163 (though not 0060) says this in a footnote: "any subsequent presence stanza with no 'type' attribute that the PEP service receives after the initial presence notification but before the subscriber against goes offline MUST NOT trigger sending of a new pubsub notification."

So strictly speaking, if the server sees a CAPS change with a new +notify string, the node should be subscribed but the last item should not be sent? :-)

I'm not a fan of our mod_pep, and can rarely figure out what it's doing - however from a glance I would say that we would unsubscribe if a future presence didn't contain caps

Ok, thanks. So then your solution to auto-update the subscription lists whenever you receive presence is probably no more complex compared to only doing it on initial presence indeed. But I'd really like to avoid checking all subscription lists on each and every presence :-/ Especially if clients never change their +notify lists anyway.

I do wonder if we should try to standardize filtering on the receiving end?

Haha. Now that I'm in the middle of another attempt of fixing ejabberd's PEP once and for good :-)

As in, with explicit negotiation instead of just sending all everything to everyone all the time

Holger can you please fix ejabberd Pubsub once and for good at the same time ?

edhelas: But it's awesome already! You just need a webscale DB backend or something.

wobscale

what about clustering SQLite on RPi instances ?

I think MongoDB is the one and only option.

Hm I'm undecided whether to ask standards@ if we can remove that requirement of checking subsequent presence for +notify updates.

Realistically there's zero chance of changing this in 0060 right ...

If a client really did want to change its PEP subscriptions, it feels a bit wrong to force it to reconnect for that

and what difference does initial vs. non-initial make, to the server?

I'm just concerned about load. I think clients sometimes send presence quite regularly ...

Load on what?

CPU

Plus cluster sync.

Ok

so it's not a simplification, but an optimisation

Yes, if I buy your implementation.

Not sure I will, I can imagine a separate filtering step ending up being cheaper (though more complex) ...

I'm all for offering any functionality clients need, and if it's expensive, so be it. But if it's expensive and no client ever needs it, that's a bit annoying.

I think the reality is that no, it will rarely (if ever in an IM client) change

But it feels like a pretty awkward limitation to impose on the protocol

just to save some CPU cycles

I mean, I'd be ok if we found some way to say explicitly "yes, I want my subscriptions updated"

But is it worth it?

Holger, uh, a client may load a plugin during runtime which adds a +notify

it would be awkward if that didn’t work until a reconnect

Hmmm :-/

Ok, I'll think about it a bit more. Thanks for your feedback.

jonas': Though I think spec-wise, at least 0163 #4.3.3 (2.) should be updated if you want to be sure that conforming servers work that way: https://xmpp.org/extensions/xep-0163.html#notify-when

Holger, from my reading, the text only implies that you need to fetch the last item manually if you publish +notify in a non-initial presence

Ah yes you're right I guess.

Doesn't sound straightforward to me either though.

Holger, you got quite the set of role labels there, and they are *very* visible in Converse.js

Cool!

I feel special now.

Steve Kille: I don't understand the requirement to specify node='mix' here: https://xmpp.org/extensions/xep-0369.html#disco-channel-info

XEP-0030/XEP-0128 allow for multiple identities and associated disco extension forms. Also, how does the client know to use node='mix' _before_ it gets the disco identity?

This is to support MIX and MUC on same node. To make this work, you need to have different info for MIX and MUC

Andrew Nenakhov, what license is the Xabber logo? Would it be possible to upload it to Wikimedia Commons?