XSF Discussion - 2021-08-12

> wurstsalat wrote: > Re xmpp.org update: I added some more redirects for blog posts and I think I covered them all now. I also added data driven announcements (e.g. for upcoming events) which can be enabled/edited via an announcement.json file. I think it's ready now :) Good

🚢

I vaguely remember at one point someone wrote a stream feature that advertised the servers disco#info (or maybe caps?) stuff so that you didn't have to query for it or check if it was updated on start. Is that a thing or did I imagine it? If I imagined it, would others find it useful if I wrote it up?

Isn't that in XEP-0030 even?

or the RFC?

Wait, caps would be in the caps xep

Sam, https://xmpp.org/extensions/xep-0115.html#stream

Oh hey! I was looking in disco and not finding it, but I vaguely remembered that it was a thing. Don't know why I didn't think it was in cpas; thanks.

Wanna write a ProtoXEP for including caps of other entities? Most notably you wanna know the caps of your own account

I forget if I started on one, or just wrote a prototype implementation.

Actually yah, in this case that's what I want to know (I said server, but really it would be "own account")

Although this also wouldn't require a namespace butmp (it's just a feature, it may or may not exist and you have to deal with that), so maybe it could just be added to caps

Hm?

Wait, didn't we have a CAPS2 too?

I was just saying "maybe we could just modify that section to allow features for other JIDs". I know it's draft, but I also don't think this would require a namespace bump or anything that it would be important to avoid in draft.

https://xmpp.org/extensions/xep-0390.html

You'd need to specify which JID it refers to

Not sure if you can do that easily without confusing previous implementations

Without a wrapper element or somesuch

That's what I was thinking, change the feature name and it's backwards compatible.

I think you would need a wrapper but then not require a namespace bump

ahh no, not even a wrapper, it needs to be a new feature

I had `[ <item jid=""><caps:c/></item> ]`

Yes, that

Maybe we could just shove this into 390 before it gets implemented 🙂

hmm yes, as child element of <c/>, that would work and wouldn't require a namespace bump

maybe needs an explicit namespace declaration for <item/> though

Actually, my prototype recursive caps thing was an `<iq>`, not a stream feature

I've kind of given up on 390 (or any of the "version 2") ones ever being implemented. I've got prototypes of a few of them though if anyone else wants to pair up and write some integration tests.

But caps1 had security issues, so we probably should replace it eventually

jonas’, around?

mmm?

caps2, can haz some thing for pushing caps for random other entities? own account, local components etc

do we want caps2 to become another '45 or '60?

or do we maybe rather want it in a separate document building on top? :)

Perhaps

This doesn't seem like it warrants a second document to me; IMO it's core functionality that can't be separated from normal caps support.

But I don't hold that opinion strongly.

Sam, IIRC I tried to write it down and it turned out to be a quite a rabbit hole

oh, pushing caps **for** random other entities

I read it as *to*

if someone writes a patch or so, I might adapt it and integrate it :)

Problem: There are features advertised on your own account. To find out which, you have to do a disco#info query.

Also fun: Combine that with XEP-0288

https://xmpp.org/extensions/ should probably list https://datatracker.ietf.org/doc/rfc7712

whenever wurstsalat 's changes are merged I'd put in a PR...

👍️

I had a thing I wanted to do there, maybe that gets easier too

https://cerdale.zash.se/s/PiPMeacd5pNdHIr1/e472f1c7-6486-4e86-b4d4-1fb9043e7f26.png

Thing like that

Ooh, pretty. Just having the current compliance suites be automatically updated on the web page would be a big win.

Mostly I'd want to have more focus on it

Perhaps direct links to the XEPs referenced by the latest compliance suite would fit in there too?

Or maybe there's some reorganization between that and https://xmpp.org/about/compliance-suites.html that would improve things

wurstsalat, going to put in a PR at some point? :)

Zash: Looks like a good idea :)

moparisthebest: if that's the way forward, yes. But I'm not sure that would help a lot, since other things regarding the deployment have to be arranged, which is probably most of the work compared to exchanging the pelican stuff with the hugo stuff(?)

wurstsalat, at quick glance looks like the build/deployment is fully contained in that repo too? Just changing the Dockerfile looks like it'd do it?

I can probably help with that if you need it

moparisthebest: it builds fine when using the dockerfile from my repo, but I'm sure there's some magic involved in the deployment (and I don't know where/whether I can view and check those)

presumably *something* on the server that runs xmpp.org runs https://github.com/xsf/xmpp.org/blob/master/MakefileDocker so if your Dockerfile works, it'll just work ?

I'd say put in a PR and if iteam disagrees they'll say? :)

Sounds sane.

If you fix the dockerfile, that’s all that should be needed.

Alright, I'll do a PR then :)

Thank you!

wurstsalat, moparisthebest: There's an nginx in front but IIRC it mostly just dispatches between web, xeps, wiki