jdev - 2022-06-11

I use libstrophe, cause it fits fine, i dont foresee ever needing "more"

But then, my client isn't exactly "popular"

Hi ! I'm trying to grasp the concept of xmpp authentication and specifically SCRAM-SHA-1. On the wiki there's "The client prepends the GS2 header ("n,,") to the initialMessage and base64-encodes the result." with initialMessage being ""n=" .. username .. ",r=" .. clientNonce". When you decode the base64 generated (biwsbj1yb21lbyxyPTZkNDQyYjVkOWU1MWE3NDBmMzY5ZTNkY2VjZjMxNzhl) it gives you "n,,n=romeo,rm442b5d9e51a740f369e3dcecf3178e". Isnt the equal sign missing after the r letter here ? Here is the link https://wiki.xmpp.org/web/SASL_Authentication_and_SCRAM#SCRAM-SHA-1(-PLUS) ✏

Nevermind ✏

> moparisthebest> virtually no popular XMPP client uses a common XMPP library, they all wrote their own, take from that what you will Ok it's not popular (:p) but sleekxmpp was a thing before poezio (right?)

pep.: Note I also consider "forking a library and rewriting+maintaining it yourself" as "writing your own" lol

It doesn't matter how the lib came to be and how it's maintained, the question is, is it used by two or more clients?

And is that ever true?

No true popular client uses a library used by more than one client

moparisthebest: except that sleekxmpp isn't actually maintained anymore and slix is now the one that's being used instead :x

Gotta ensure the goalposts sits just beside Conversations

I'd be curious to have usage stats on sleekxmpp/slix

Compared to other libs. Python also being a popular language

Smack is used by tons of things I think, but they don't count!

Not just conversations, also gajim, Dino, siskin, the other tigase clients

Poezio and slix ? :)

Actually, libpurple might count, depending on whether othre clients using it must be considered popular

is spectrum a client? :-)

Right pidgin and libpurple

Perhaps the rule is more like "only libraries developed in tandem with a client are usable in clients" ?

I didn't make the rule I'm just pointing out there seems to be a pattern

Extend that reasoning to the protocol and you have Matrix

Except that's disproved by the undeath of XMPP!

I don't think you can extend it to the protocol, XMPP libraries are very useful for bots and servers and such, just seemingly not clients

I blame GUI work

Isn't it fairly well-known that having components developed by separate teams introduces overhead?

I am perfectly happy with how Gloox is designed and it fits well into my client so far

and that's from a client which was already written with its own custom jabber thing when I started

so it doesn't have to be this way?

Also, that effect that components separation tend to mirror organizational structure.

Small team doing the whole client → single codebase - i.e. no library

I don't know that I buy all this. I don't know why no one reuses libraries, but some (not all) of them are perfectly suited to GUI work. aioxmpp, for example, is pretty well designed and could be used in clients much easier than building your own and with less overhead. I like to think Mellium could be too (but no one but me has done it, so I can't speak to that). I suspect it's a mix of NIH, lack of discover ability of the libraries, and bad documentation.

Don't forget 'historical reasons' 🙂

True.

I mean, I imagine Gajim predates aioxmpp by a number of years

What other Python clients are there?

There aren't many XMPP clients, and they're mostly legacy, so few new things yo reuse newer libraries.

Yaxim uses Smack

And I'm pretty sure Smack is used in tons of things, IIRC from poking around in the android store or something

lack of discoverability? is https://xmpp.org/software/libraries/ not enough?

Yah, while the newer Babbler is rarely used.

pulkomandy: not really. I default to search and that page never shows up. Not our fault, and it's good that it exists, but one list doesn't make things better.

I tried to find the name of babbler the other day and it took me ages, various combinations of "java XMPP lib" didn't turn up much.

Well, they turned up Smack.

I don't know I typed xmpp library in my search engine and this was one of the first hits

search engines work in mysterious ways

Lucky you. Probably some algorithm nonsense. Or a more specific search wuery

the second result being https://github.com/topics/xmpp-library

Query, even

so that's two lists :)

Oh right, Converse.js uses strophe.js? Which is used in other things, tho certainly lots of more obscure things

> https://xmpp.org/software/libraries/ it's kinda ironic that the .net xmpp libs are called matrix

predates matrix.org I think

That list appears to be extremely incomplete too, so even if you did find that at the top of your search I'm not sure how helpful it would be.

I mean, again, better than nothing, just not likely something I'd click through to while looking for something specific (and if I did, it doesn't give many options)

observation, there are 88 entries in the data, only 36 are renewed at any point

[the data]: https://github.com/xsf/xmpp.org/blob/master/data/libraries.json

Grouped by renewal year: 52 null 16 2022 9 2021 5 2020 2 2019 2 2018 2 2017

provide more DOAP

anyone up for giving the same treatment to the libraries page as the clients got?

I can do that

(same for server software)

❤️

(w.r.t library discussion) see, my logic is, libstrophe is minimalist enough, that it allows building upon it to provide whatever functionality you need

by that logic, if more people were like me and wanted to dev in C, C++, vala, zig, rust[c], whatver, libstrophe would be really popular

because it doesn't inherently have any reusability issues

in that sense, i kinda have built my own library on top of it, i just don't export it as a library

firstly because it's half baked, but secondly because i don't want to maintain a library

i imagine that's the solution though, having transport-level libraries like libstrophe, that things can then build on and provide language-native ergonomic bindings to

just as an exercise, assuming python-c FFI was no issue whatsoever, imagine conversations rewritten to be built over libstrophe

that would not be a problem, coding-wise

InputMice: right?

er, sorry, java-c

wurstsalat; ditto python/gajim, i guess

http://strophe.im/libstrophe/doc/0.12.0/ for reference

gloox has interface higher level than this, but has "extension points" where you can easily add your own stuff. I think the API is quite well designed. I wouldn't want to write a client on top of something very lowlevel like libstrophe and have to re-figure out all XEPs myself

_shrug_ worked for me

I'm not implying everyone should agree with me, that's how I feel about it, that's all

I have started to build a layer on top of libstrophe for XEPs implementations. Unfortunately, it's too much work for me. 🤷

This is (more or less) the direction we took with Mellium, except that we also provide the higher level features. But if you don't like our implementation you can only use the low level stuff and write your own extras