XSF Discussion - 2021-04-07

Is there a place I can get information on xmpp spec? I'm looking at https://xmpp.org/extensions/ and I can't find clear info on how to work with xmpp messages (stanzas?)

anyone here?

alexbay218: I think most will wake up in a few hours.. But isn't it in the core what you seek? https://xmpp.org/rfcs/rfc6120.html

I see, I got there eventually, but I'm wondering if I'm missing some sort of tutorial that more easily explains it. Reading full specifications is pretty dry

There are some devs in this room.. Maybe they know some tutorial website.. But its early in the morning in Europe and late in the US east cost

figured, I'll ask later

Now I wonder... are my Last Call responses so long that nobody is going to read them? Maybe I should just strategically bring up the most important point only, and then -1 the XEP so that I can bring up the second most important point in the year after? :D

jonas’: AOB for today, or maybe just for you with your Editor hat: would it make sense to collect CVEs related to XEPs in a XEPs meta-data / Security Considerations / somewhere?

yes

or maybe

CVEs are for implementations, so it’ll be interesting to find a good clear cut of when a CVE should be mentioned in the XEP or not…

but in case of '280, heck yeah, add it

did you just say DOAP?

I'm also looking at 0313

did I miss something there?

0297 Security Considerations are rather clear OTOH

jonas’: https://monal.im/blog/cve-2020-26547/

Ge0rG, that’s 280 tho

jonas’: it's MAM and Carbons, as well as https://gultsch.de/dino_multiple.html

ok, the description on the page only says carbons

"Monal before 4.9 does not implement proper sender verification on *MAM* and Message Carbon (XEP-0280) results."

yeah, those CVEs should probably be linked as an example for '280, '313 and also '297, because people don’t seem to get it.

Yeah, but the Security Considerations typically already contain wording saying that "you must not". And still, people don't get it. Or don't read them. I'm not sure how to improve the developer-experience here

short of a Huge Red Blinking Marquee

CVE numbers are scary

only if you see them

yes, hence add them to the security considerations of all those documents

I suppose it would make sense to have some plumbing for adding CVEs, making it possible to auto-extract them in some way?

maybe, PRs welcome ;)

I imagine this to be tricky though

like a `<cve number="2020-26547" uri="https://monal.im/blog/cve-2020-26547/">Improper verification of MAM and Carbons in Monal before 4.9</cve>`

I wouldn’t want to associate them to document metadata directly, because in most cases it’s not a problem with the document, but a problem with implementations.

so having a list of CVEs on a XEP gives the wrong impression

Yeah, I'm speaking of a template for stuffing it into the body and rendering

and havnig a list of <cve/> elements in the header and then making xep.xsl inject those in the security considerations section is breaking lots of abstractions

ok, yeah

somewhat like link/footnote etc

Yeah

go for it I’d say, we can discuss it in council if need be. we might learn that it’s a board matter though, not quite sure

Probably better than https://xmpp.org/extensions/xep-0223.html#revision-history-v1.1

(though I’d argue it’s an editor matter)

Then there is also the last sentence of https://xmpp.org/extensions/xep-0373.html#security

I'm in favour of including CVEs encountered in implementing XEPs in those XEPs, whichever hat I'm wearing.

dwd: but what if you are not wearing any hat?

Even then.

I'd actually be fine with information notes pointing to implementation dicussion on the Wiki, too, thinking about it.

Does anybody volunteer to create an XML template?

dwd: I think that's why we created https://wiki.xmpp.org/web/Category:Spec_Remarks but it might be non-trivial to do an automatic redirect from XEP title to mediawiki slug

especially if the slug isn't consistent

Ge0rG, I'm thinking manual works for now.

Ge0rG, you just did, didn’t you? :)

jonas’: I'd love to, but who's going to plow my snow?

your laptop which you’re holding in the snow while running the test build with the new xsl file!

win-win!

Ge0rG, Is that a euphemism?

jonas’: unfortunately, my new laptop is very energy efficient.

dwd: whatever floats your boat!

Ge0rG, Is *that* a euphemism?

Maybe it's euphemisms all the way down.

dwd: it always is.

Maybe the turtles are a euphemism.

What are the turtles a euphemism for? For turtles?

You may have just blown my mind.

is that an euphemism?

jonas’, No, just a metaphor.

It’s like an explosion in his brain-cage.

Aren't euphemisms a subset of metaphors?

A subset *and* a superset.

(It's possible that only Kev will get that reference...)

But he did, so that’s alright

dwd: I suppose that your statement isn't based on set theory.

Ge0rG: Someone once claimed that their implementation of a XEP was both a superset and a subset of the functionality.

Kev: that's not a bad statement actually

Not as long as they meant that it was an exact implementation of the XEP. They didn’t.

"Sure, we don't do that mandatory thing, but we do this other thing instead so we're still conformant, right?"

Well, handling it right requires a certain understanding of set theory, yes.

I got questions asked in context of a standard that defines some kind of uniform data transfer over XMPP, that I am unfamiliar with: IEC 61850-8-2. When I google for the standards, I find various applications of Openfire (eg: electricity grid management over XMPP). Anyone familiar with that standard?

Only aware that there's some grid management RFC involving XMPP.

i think that's a different grid

the IEC standards deal mostly with power girds I'd assume

but no familarity here, cause I don't have the bucks to pay for that standard (and I am also unable to retrieve it via my university)

Zash, I think *that* grid is for the Cyberzz, whereas the IEC one is for the Leccy Grid, as we say here.

Wat

Zash, The RFCs as I recall do Cyber Threat Information Exchange, whereas the IEC one does - I think - electricity grid management.

Zash, Possibly interconnect management. Your country's power controlled by Openfire.

Zash, And probably version three point something ancient.

EPOX - Electric Power over XMPP

dwd: I couldn’t be more scared.

I mean, I tried, but my power failed.

badum-tisssssh

jonas’: I wanted to push a PR on gitlab, but gitlab/main is two months out of date

Well, now it looks like I created it on my own repository. Well done.

jonas’: rendering build is running on https://gitlab.com/ge0rg/xeps/-/merge_requests/1 - code is also on https://github.com/ge0rg/xeps/tree/cve

rendered version also at https://op-co.de/tmp/xep-0280.html#security - feel free to bash

I'm not sure if this is enough or if the format should have a caption that contains a title and a text area that contains a description.

https://drewdevault.com/2021/04/07/The-next-chat-app.html

Should... should somebody tell him?

Sam already did: https://lists.sr.ht/~sircmpwn/public-inbox/%3C08dd6c3d-b9f6-4b50-83b1-3fedbb763de8%40www.fastmail.com%3E

Hah, I, of course, didn't expect much of it.

I don't get it, when I come up with a great idea and find someone else already implemented it for me I'm delighted I don't have to do any work :)

i thought he was describing xmpp too...

i bugged him about it on irc and wouldn't even consider it at all becuase xml and it "already failed"

It's a shame since people look up to Drew, or at least seem to admire the tenacity, but there's two sides to that apparently.

If you disregard the actual technical/implementation aspects of XMPP, the fact remains that the collection of RFCs and XEPs describe in great detail the *semantics* of a federated, extensible communication protocol.

I find it hard to believe that any other federated system won't end up walking down the same paths in many ways.

100%

Unless that other federated system is just a marketing plot of a startup company?

Email? Hm, I don't think so.

> I'm converting more and more people from other messengers to come join me on @matrixdotorg. Clearly the best choice if you want something that's OSS + open-standards-based and federated *and* not requiring a phone number as a primary identifier (I always found that sooo dumb). https://twitter.com/juliusvolz/status/1379891845229117452

> Sam already did: https://lists.sr.ht/~sircmpwn/public-inbox/%3C08dd6c3d-b9f6-4b50-83b1-3fedbb763de8%40www.fastmail.com%3E :facepalm: