jdev - 2025-04-17

> gajim's library is nbxmpp, guess who owns/maintains it? 🤣 And who uses it in other software than Gajim.

> Schimon: gajim's library is nbxmpp, guess who owns/maintains it? 🤣 moparisthebest. I know. Asterix and Dicson have created it, because the previous library of Gajim, xmppy, is synchronous. ↺

Even Emesene utilized xmpppy. ✏

Gajim 0.16 (04 October 2014) * use external python-nbxmpp library Gajim 0.7 (23 May 2005) * Gajim jabber library migration from jabberpy to xmpppy https://dev.gajim.org/gajim/gajim/-/blob/master/ChangeLog

>> gajim's library is nbxmpp, guess who owns/maintains it? 🤣 > And who uses it in other software than Gajim. bodqhrohro: no one right? ↺

moparisthebest: someone might be the first one finally (why though?)

By the way, I noticed Mellium exists. Is it worth even considering migrating there? go-xmpp I use is rather stalled for years already and I have to extend and patch it significantly. Though Mellium looks even less like a full-fledged library.

> By the way, I noticed Mellium exists. Is it worth even considering migrating there? go-xmpp I use is rather stalled for years already and I have to extend and patch it significantly. Though Mellium looks even less like a full-fledged library. im currently uh fightng with it ↺

debating if it would be simpler to either roll my own or use cgo and libstrophe

genuinely bad documentation, and what to me as an arguably novice dev reads as batshit. the dev is pretty chilll and helpful though so ymmv

currently trying to abstract most of mellium away into a kinda wrapper library to glue the movinig pieces together, but thats an uphill battle with the lack of documentation

>> gajim's library is nbxmpp, guess who owns/maintains it? 🤣 > And who uses it in other software than Gajim. Iiuc using it would mean pulling in glib event loop... Which is obscure and not used anywhere but in gtk apps. If you wanted to make a qt client, you'd still have to pull in g* stuff (if not gtk whole?), spin nbxmpp in another thread and communicate with it somehow. ↺

And if I'm not mistaken that'd apply to most libraries, because they use event loop A and you'll probably want to use whatever your GUI framework uses.

bodqhrohro: > By the way, I noticed Mellium exists. Is it worth even considering migrating there? go-xmpp I use is rather stalled for years already and I have to extend and patch it significantly. Mattn recently gave me access to go-xmpp and I added some things I needed in go-sendxmpp. Why not join forces and also merge your improvements upstream?

Martin: AFAIR, I made PRs for all the patches anyway.

Most just don't go to the library though. As it's just scarce in terms of XEP support. So I end up with registering lots of custom extensions.

I only see one open PR: https://github.com/xmppo/go-xmpp/pulls

Or are you talking about the processone lib?

Martin: yup.

Ah OK, I'm not using that one.

> And if I'm not mistaken that'd apply to most libraries, because they use event loop A and you'll probably want to use whatever your GUI framework uses. Unless the library accounts for it e.g. by provides a its own event loop that can be run BY another even loop like libcurl, or spins its own thread(s) and provides a nice api abstracting thay away, like tdlib. Personally, I do not know of any XMPP library that does that. ↺

I had no problems integrating gloox with my own event loop. It just runs its thread in the background and has callbacks when things happen

Then you usually have to forward these events into your own event system so you do the work in the right thread, but that's fine. And I think there is a way to run it in your own thread as well, just call its polling function regularly

I think lik any other library, it doesn't implement "all the xeps" so I end up adding a lot of extensions, but thatws woat I would expect from an xmpp library. And also what makes it difficult to use them accross programming languages, and that's why there is at least one library per programming language

Good day. I would be glad to receive your advise. I have an XMPP news bot. I have decided to replace XEP-0048: Bookmarks as a storage for rooms, and replace it by a list which is stored locally. However, I intend to create a component interface for that bot which would realize each news source as a contact. Should I utilize XEP-0402: PEP Native Bookmarks or utilize local storage?

If each news source is going to be a different contact, does that mean each will have its own bookmarks store? ✏

I can think of two ways to do this

Either you can make the component behave like a client, so each news source will be managing its bookmarks through 0402 and letting the server handle the storage and broadcast ✏

Components don't get PEP tho

Or you can handle storage internally (eg. with a local database) but implement the server side of 0402, so other clients can query your component directly to receive news updates

> Components don't get PEP tho They could if they fooled the server into treating them as a client? ↺

Oh, maybe not if PEP is tied directly to a user

> Or you can handle storage internally (eg. with a local database) but implement the server side of 0402, so other clients can query your component directly to receive news updates I suppose this is the more workable option then ↺

As it'd only require fooling *clients* into treating your component as separate users, which is easier

> Components don't get PEP tho Even better they can do their own pep ↺

Yep, that was my next idea and probably the best way to do this

Handle all the storage yourself but expose the news items as PEP native bookmarks

So the answer to Schimon's original question of "Should I utilize XEP-0402: PEP Native Bookmarks or utilize local storage?" would be to utilise both 😉

I mean it doesn't make sense for a component who needs to store some internal data to also expose it in a way other things can mess it up right? Just store it locally to the component

badrihippo. To a chat client, I would utilize XEP-0402 and XEP-0048. However, this is a bot, so one might use a different JID. Yet, it might be wise to utilize all: XEP-0402, XEP-0048, and local. I chose local, for now.

This would be like prosody storing user credentials in PEP or something

What if you want other clients to be able to query that data through PEP?

From a client's perspective, it'd be like "I have [news source] as contact, and I can get its bookmarks through PEP the same way I get my human friend's bookmarks through PEP"

Wait did I get something wrong or isn't PEP meant to be public?

moparisthebest. Concerning to component, it is due to a special circumstance. I have decided to store bookmarks by Jabber ID, in order to make it workable with component JIDs too. ``` { 'bookmarks' : { self.boundjid.bare : {} } } ``` ✏

moparisthebest. Concerning to component, it is due to a special circumstance. I have decided to store bookmarks by Jabber ID, in order to make it workable with component JIDs too. ``` { 'bookmarks' : { self.boundjid.bare : {} } } ``` ✏

moparisthebest. Concerning to component, it is due to a special circumstance. I have decided to store bookmarks by Jabber ID, in order to make it workable with component JIDs too. ``` { 'bookmarks' : { self.boundjid.bare : {} } } ``` ✏

> What if you want other clients to be able to query that data through PEP? That's different of course, still need to write your own pep impl and store that locally though ↺

Yeah I agree my answer was taking things a bit further than Schimon's original question

> moparisthebest. Concerning to component, it is due to a special circumstance. > I have decided to store bookmarks by Jabber ID, in order to make it workable with component JIDs too. > ``` > { > 'bookmarks' : { > self.boundjid.bare : {} > } > } > ``` 👍 ↺

Thank you for the offer.