XSF Discussion - 2019-07-31

I lack context

jonas’, look up “420 blaze it”.

do I want to at work?

For science.

I take that as a "heck no"

420 implement it!

flow, Guus: could you reconfigure the ignite discourse to not auto-close threads after three months?

Ge0rG: would you mind asking for that in that discourse, for the relevant people to be involved?

Fwiw, I don't have a preference

Guus: does it have a "meta" tag?

I've only posted "smack" issues so far :

:>

Guus: thanks, posted as https://discourse.igniterealtime.org/t/please-disable-auto-closing-of-threads-after-3-months/85765

Could someone regenerate the website, https://xmpp.org/extensions/ is outdated.

LNJ: it _should_ get auto-generated, with ~2 hours of delay, so probably something broke.

who is writing the xmpp newsletter thingy? :)

commteam@muc.xmpp.org

There's also a wiki page you can edit if you want things to appear in the next one

yep thats my goal

however if writing to the team also does the same. maybe I'll prefer this :)

thansk pep. I see the wiki link in the topic of that channel

They usually redirect you to the wiki because they can't remember everything people wanted to put in (which is fair enough) :)

Ge0rG, the extension list is not coupled to the other generation process, it needs to be triggered manually

someone with power (Guus maybe?) needs to kick the docker build job

I just did.

xsf/xeps was last built 19 hours ago

seemed to have been successful

I just kicked off a new build manually.

Guus, maybe a race condition then

thanks

ah!

There's a webhook on that dockerhub build that I don't recognize: https://api.hub.sotecware.net

ah, Google reveals a likely culprit 🙂

the webhook has been failing for months though.

Guus, that’s me

the webhook is mine, and should be irrelevant

I wanted to set something up which could do things when new XEPs are published

but I didn’t get around to do it

(sotecware.net is my domain)

sure, no problem.

my browser gives a security warning on that URL btw

cert probably outdated or not matching the domain or something.

yeah

I didn’t bother with maintaining that domain after I didn’t bother to write code for it ;)

I'll not bother bothering then 🙂

it used to be sotecware, but now it's abandonware

:P

> someone with power (Guus maybe?) needs to kick the docker build job @jonas’ FWIW, I think you have the power too. ✏

Guus, yes, but I don’t have my credentials on my work machine :)

hey, Converse is having trouble doing the mention.

ah, k.

in https://xmpp.org/extensions/xep-0060.html#entity-discoveritems, where is the definition of the "jid" attributes of items

edhelas, in XEP-0030, disco#items.

fair enough

The day disco+rsm is a thing, or featureX+rsm is a thing, if in the disco#info I get I see MAM, featureX, rsm, how do I know what I can do? Do we need a different NS per combination?

Add sub elements to the feature element!

Is there such cases currently where it can be confusing?

Advertising RSM on its own doesn't really make any sense.

RSM-for-Disco does, or RSM-for-MAM (which is really just MAM, as MAM requires it). ✏

I agree

Has this already been discussed somewhere? Something like Ge0rG said doesn't sound too bad :x

RSM for president!

There could also be order-by, 413 :)

Should a service even announce disco-with-rsm support? Wouldn't it be sufficient if the requesting entity would include i-can-do-disco-with-rsm flag into its disco request?

So you'd include rsm when requesting, and then?

if the server supports it and the result set is large enough he will make use of it

(that assumes we have defined, together with the i-understand-disco-responses-with-rsm flag, the semantic how that should exactly look like)

right now the only reason I can come up with why a disco responser should announce that he supports rsm is to track how widespread the support is

OK, that's fine for rsm, now say order-by+disco is a thing

brrrr

I need to have guarantees that the result is ordered

We are speaking of disco#items only, right?

Ge0rG: yeah

I don't want to go down that road right now. I would be happy if we had a solution to page through large disco result sets, like if you have a loooooot of pubsub nodes, using RSM

I'm actually looking for disco+search

Ge0rG, well there is nothing that prevents disco#info result from becoming too large for a single stanza (whatever "too large" is)

Lots of pubsub nodes is already a thing, edhelas says with comments disco results easily become bloated ✏

That's one reason why disco+rsm would be desirable

flow: but how are you going to split a single #info?

What does the disco#items look like on conference.jabber.org?

Ge0rG, cut in half? But yes, the issue is more pressing for disco#items

that is why I would start with that and get some implementations experience

Ge0rG: order-by might be something you want? You add a new condition "number of participants" for example :p

Note that mongoose's muc light uses RSM with disco#item: https://mongooseim.readthedocs.io/en/latest/open-extensions/muc_light/

but I am not sure if the way they describe it is the way I would do it

pep.: disco#items doesn't even contain that number, so you end up doing disco#info on each individual node. Last time I did it from yaxim, it took two hours.

Ge0rG: have you read order-by?

And the result wasn't really worth it

It would be too far-fetched to add that to disco#items

Yeah, jonas’ just needs to XEPize the MUC search protocol.

And then you could do what you're asking for, (and with rsm)

I think it's doable with the more or less generic bricks we have

I wouldn't create yet another xep

pep.: I'm looking for a certain subset of all disco#info results embedded into the domain's disco#items

Sure

Create another condition for the order tag, by='number-of-participants' or sth, and let the server do the work, they already have all that info

That was the easy step. The hard one is: deploy to jabber.org

Don't underestimate the power of a moving glacier!

Even the earth itself can't handle the pressure!

Let’s just wait for it to be done melting, I’ve heard heat waves are going strong lately.

Link Mauve: this year, Greenland will melt enough ice for a 0.68mm sea level rise.

so.. <feature var="urn:xmpp:order-by:0"><feature var="http://jabber.org/protocol/disco#items" /></feature> this would do it?

(Or rsm instead of order-by)

Ge0rG: you haven't heard the news, that's a Chinese hoax

pep.: global warming?

Of course

pep.: you swapped the namespaces. order-by is an option of disco#items, not vice versa

OK sure, I don't care which way as long as we talk the same :)

It's not very elegant, and I'm not sure how far it's supported by anyone, but it's the most logical syntax

It’s also not allowed by the schema, and will fail parsing in most parsers.

I find it elegant enough :/

Err

hmm I don't like child elements in <feature/>

partly due the reasons Link Mauve mentioned

What alternative is there?

Declare new NSs for these combinations?

pep., for instance, a feature var='disco#info-with-order-by'.

Right :/

It’s not a namespace, it’s a feature.

Yeah ok

Add a comma separated list into the var, because why would you use xml syntax for it?

JSON

edhelas: thanks, I forgot.

But then we rather should use DER.

no that’d make zinid happy

CBOR is the future!

jonas’ because you know how to make zinid happy ? 🤔

edhelas, he *does* like ASN.1

hehe