jdev - 2022-02-14

https://upload.magicbroccoli.de/a11cd1c5c3316374c6cd412dcf2dff134e54e8d1/4Z8RnOlyLP55xbnWo9mkvHgWik3zQEPyNwWsvm5o/5TwJum_dTeCka4sIOBCNSg.pdf

Impressive kikuchiyo

^ I generated a Client Comparison Chart. XEP-0384 and 0453 itself are not well documented in the doap files. Some clients don't even have a doap description. I can update the chart, if you are a client dev and created/updated your doap doc, just reach out to me. (Some source links are still buggy)

kikuchiyo: you should share this in xsf@, if it's automated we should integrate it into xmpp.org

moparisthebest: yes I cross posted to xmpp:commteam@muc.xmpp.org?join but I it is still buggy so I decided to move here, hoping to collect some feedback/correction.

kikuchiyo: You have forgotten Psi/Psi+, Psi is an XMPP client which exists since 2001.

Neustradamus: please link the doap if you know where to find it.

...or at least a changelog or wiki table mentioning the implemented XEPs

Ah, it is not added, if there is a contributor - https://github.com/psi-im/psi/issues/120 - https://github.com/psi-im/psi/issues/595

Neustradamus: thx I'm going to parse https://github.com/psi-im/psi/wiki/Supported-XEPs if there is no doap

:)

Neustradamus: you should get them to make a doap file instead

kikuchiyo: 🤯️

kikuchiyo: here is the doap for Renga, it seems to be missing in your list: https://github.com/HaikuArchives/Renga/blob/master/doap.xml Thanks, it's useful to know what other clients are doing :)

pulkomandy: thx

(that made me realize I forgot to update the DOAP for slixmpp & poezio in january :x)

kikuchiyo, you could just grab the clients.json or libraries.json from the xmpp.org repo and start with the DOAP files contained therein

Is it ok if I add Haiku to the platforms.json at xmpp.org (we have at least two clients) or should I just use "Other"?

(I see Solaris gets an entry, not sure which one of the two is most relevant :) )

Are the two clients already listed or supported by other things?

No, they are haiku-only

(I'm just curious, I have no say in whether something gets listed or not)

https://github.com/haikuarchives/renga and https://github.com/JadedCtrl/Chat-O-Matic

pulkomandy: feel free to add haiku

Renga doesn't seem worth listing if it's archived (assuming that means little-to-no-development); chat-o-matic seems interesting, I'll take a look. Thanks!~

Sam, it is not archived, that’s just the umbrella org

(last commit by pulkomandy 18 hours ago :p)

I should move it out of haikuarchives, yes

mathieui: the org specifically says "old software" in the description; but sounds like this doesn't belong either way, so that's great!

But yes that github org didn't end up working the way it was intended, turns out the haiku community is so small, it's easier to have all our projects in a single place and grant the same permissions to a lot of people, rather than having projects hosted by a lot of people on their personal account

I'll check with other haikuarchives people if they're fine with moving it since I pretty much adopted it

Mh… I have a crash because of a message containing an unescaped > character (possibly inside xhtml-im). Not sure because gloox crashes when I try to get a string representation of the xml for debugging, not very helpful…

but that is valid xml

if it is not preceded by ]]

The message seems valid xml at gloox input, not sure what's going on

Anybody knows where (if?) it's specified that <x xmlns='http://jabber.org/protocol/muc'/> be stripped by the MUC. There's no occurence of 'strip' in 0045, and too many of 'remove'

pep., where should it be stripped by the service?

MUC presence is usually adding the <x/> instead, and MUC messages do not have that element, private messages do but you don’t want to strip it there

There's a <x/> in the join presence, with a possible <password/> and <history/>. I heard that it was stripped, I was just trying to confirm

Well, the join presence is mostly processed and rewritten I guess, instead of being transformed

TIL, a GC 1.0 join to a non-existing room still creates the room with the default configuration, instead of locking it.

Second paragraph of section 10.

Hush, don't tell anyone, just quietly submit a PR to remove GC 1.0!

⤴️

Yup.

don’t make me read 0045 again and discover new stuff I don’t want to know

Y(esterday)IL https://xmpp.org/extensions/xep-0045.html#example-196

(or the day before, but it's not important, is it)

pep., I did not want to know

Too late.

(I read it twice thinking "what’s wrong here?" "oh, <message/>")

“because members-only rooms are relatively rare”, [citation needed]

-- 2011

Since the model was IRC..

Zash, Sam, https://github.com/xsf/xeps/pull/1163

Oh nice, thanks. I thought I remembered starting this once and it having a bunch of references and things that had to be untangled so I gave up; guess I was misremembering

hmm, has anybody ever checked that linked examples still correspond to what they were intended to mean? Since removing an example in the referred XEP renumbers them. ✏

Hm, references from where? ✏

In XEPs

Ah but examples "are not normative".. ✏

XEPs shouldn’t reference examples but sections.

And sections should get a proper anchor.

Yeah yeah..

Even though everybody only read examples

Maybe we should reverse the rule, start writing xeps where the examples are normative but the text is not!

Does anyone know sqlite very well? This is what I would assume is a good normalized way to store disco/caps, but I don't know sqlite specific quirks. Will this work or are there some other optimizations I should be doing? https://gist.github.com/SamWhited/4ff23875aca4ea594287c012ab840c99

Example 177, 191 and 196 are the only ones to use message.

hmm, and there's normative text above all of them