XSF Discussion - 2021-08-09

singpolyma's solution for disco feature attachment is far better than my proposal. I plan to update my proposal if it's fine with council members which have already voter in favor of it.

(not now cause I'm at work)

voted*

goffi, do you have a link to singpolyma's solution?

flow: last email on standard@

ha, was in my spam folder :/

it's using disco extensions, and that is already included in caps, so I don't see any downside

I'll reply later on standard@, I'm at work and will be in meeting soon.

I’m not 100% convinced it *is* a better solution.

Kev, feel free to share why :)

Kev: why? Could you elaborate (maybe on standard@ would be better)

goffi, same goes for you: why do you think this solution than your proposed one?

I'll share on standard@, I'm in a meeting now.

kk

probably write something tonight, after work.

+will

I am myself torn between those two, as they both have their ups and downs

I might be completely misunderstanding the problem domain, but these are basically just traditional Disco features as far as I can see, and I’m not sure why the existing mechanism of just checking for the presence of a feature in the list doesn’t work here. Whereas the new proposal involves all consumers having to then do two-level map lookups for no benefit that is immediately obvious to me (although I might be missing it).

nothing a good API can't hide from the user

It seems to me that a consumer wants to know “Can I RSM with Disco” and that the normal approach of looking up the “RSM with Disco” feature works fine, and having to do “First I’ll lookup RSM, and if that’s present I’ll look up the RSM map in the attachments data form and see if that contains Disco” isn’t providing anything but additional complexity.

Although as a whole, I’m not entirely convinced this is a standards track XEP, rather than just a suggestion for how other XEPs could do their naming for optional features.

I share singpolymas concern about the opaqueness of the strings though

Ah, but these *are* opaque strings.

You’re not constructing these things arbitrarily.

If ‘pubsub and rsm’ is a valid combination of things, that’s going to be defined in pubsub, rsm, or a pubsub+rsm spec that will be defining the feature.

if they were still opaque, we wouldn't need a XEP to write down how to construct the product of RSM + Disco

Which is why I think this should really be little more than a suggestion of how you can name such a feature when you define it.

then it'd be informational I guess

And that is unecessary, because they’re opaque.

Yes, I agree with that ‘we wouldn’t need’ - I don’t think this is really needed.

unless people really care about the genericity, in which case singpolyma's approach is saner in the sense that it doesn't violate the opacity

It feels to me like this is an rsm-specific sticky plaster over rsm being MTI for some specs, but not widely deployed and wanting to advertise after-the-fact who advertises it. But for that, it’d be better to be explicit in the source XEPs.

well, RSM is not MTI for '30

and there's no way to retrofit a feature for RSM into '30

you could add it to RSM itself, sure

other topic: Any member working at Isode to review and confirm: https://github.com/xsf/xmpp.org/pull/885

emus: you mean #950, right?

ups, yes

https://github.com/xsf/xmpp.org/pull/950

jonas’: right, for disco it’d be in RSM, or in RSM+Disco.

I think this is really just a somewhat-bug in 59 that it says ‘just advertise rsm’, and fixing that to say “Individual protocols need to advertise RSM support themselves, unless MTI."

I am not sure why the discussion about "feature attachments" seems to only revolve around RSM now, we have that problem in a few other areas too, notably E2EE ✏

-v?

What’s the equivalent need in E2EE, flow?

example: if you announce support for omemo, does that mean that you can also process encrypted chatstates

flow, that would be handled by SCE, not?

jonas’, I don't think so, no

why not?

unless you want to imply that implementing omemo means implementing a lot of other additinal protocols

OMEMO does not specify encrypted chat states at all.

and even then: what about future extensions?

only encrypted body.

so I don't see how a mere OMEMO feature would be related to encrypting non-body content at all.

for anything beyond that, there's stanza content encryption, and that has its own feature, I guess.

I am not sure if you are guessing right

due the modularity of XMPP, at the point where you can combine one protocol with another, e.g. MAM+PubSub, or OMEMO+ChatStates, you need a way to announce those as distinct features

Kev: flow: you are right with the added complexity, I just find singpolyma cleaner, easier to read, and taking profite of XML. I don't think this can be informal though, as we need to know if the dfa is implemented to know if a missing 'http://jabber.org/protocol/rsm@http://jabber.org/protocol/pubsub' means that the RSM is not implemented for pubsub, or just that dfa is not implemented.

also it's useful for other XEPs, order-by for instance.

Ok my meeting is resuming.

I didn’t say informal, I said it needs to be specified in the respective XEPs.

I'm inclined to agree

Otherwise you could advertise interesting combinations of features without it being clearly specified what that means

Quite.

If you say you support RSM for MUC, how does that function exactly?

Poorly :D

313 has semantics around the use of RSM, such as saying the RSM IDs match the archive IDs

And I think this will apply to most things

313 also has (or rather, used to have and is split off) semantics around 313 with 60.

You also couldn’t just advertise omemo+csn and expect it to work usefully without arbitrary element OMEMO being defined.

Right

So I agree that either RSM support is declared mandatory by the source XEP (if you advertise MAM support, you *must* support RSM), or you need to document it somewhere else if it's optional

Or not somewhere else, even if it’s optional.

Which I *think* is what you meant.

You can't just combine arbitrary features and expect everyone to understand what that means

all very reasonable

Quite.

Er, sure, it can be optional in a protocol indeed

sure nothing prevent to explain it directly in concerned XEPs, I did it in last version of https://xmpp.org/extensions/xep-0413.html#disco . But that means that you have to repeat each time how to produce the disco feature string, instead of just linking to a XEP, and also that we have to update all concerned XEPs, and for some of them we can't bump version, so how do we know if the feature is implemented or not? With dfa, you can just say "this feature can be attached as of XEP-xxx (dfa)", and if necessary explain what that means.

"produce"

there is no way to produce an opaque string

I think everyone agrees that the combination of two protocol extensions need to be declared and specified somewhere (even if it is trivial) ✏

> there is no way to produce an opaque string Right.