jdev - 2025-01-09

Hello. Please advise a beginner tutorial on writing xmpp application for computer

You can do so in Python very easily

There's a python module that makes things really easy writing xmpp bots

The only problem with it is well it's python

KaAk, which kind of application? The easiest is probably to start from an existing free software client.

Xmpp-client

KaAk: i think Link Mauve meant more like do you actually want to write a client like dino/gajim or do you want to write some other application which uses xmpp like e.g a bot

I want to make my own client. I want to do this after trying the terrible dino...

KaAk: what language/stack do you prefer?

This is something I'm actively working on making easier

Probably vala and C

Interesting. So snikket SDK does have C bindings. I hadn't really been thinking about Vala too much. I wonder if that's your stack if it might be worth forking dino?

Forking is obviously the easiest thing to do, but I don't want to use their code...

You don't think there's anything of value in there? I expect no matter how much you dislike the app they've solved things you'll need to do again

In any case if you don't want to do that and you're interested in a high level xmpp SDK, the snikket SDK will be doing alpha soon

KaAk: i think you underestimate how much effort an xmpp client is. Probably everyone in this room wrote one, but most of them gave it up.

KaAk: also don't make the error writing your own xmpp library.

Ignore this guy, it's easy and you'll inevitably end up writing your own library

moparisthebest will say you did if you end up contributing to yours

I certainly have written several clients and never wrote my own library

🤣 You are writing your own library right now...

No I'm not

I'm contributing to xmpp.js and libstrophe but I'm not even a maintainer in either case

Oh are we gonna pretend the snikket SDK isn't a library (:

It's certainly not an xmpp library, since it uses xmpp.js or libstrophe and those are the xmpp libraries

Tomahto/Tomayto.

More live tomato/water

If a user can't interact with it, it's a library. (repl doesn't count)

I'm making a tomato not making water 😉

Well, most people will be using some lower level. Not everyone is stupid enough to fork and maintain their own XML library.

kalkin: yes it's obviously a library. But it's can't be an xmpp library since it depends on an xmpp library

Ohh, ic

libstrophe supports "XMPP". I would like (I started) to write a lib on top of libstrophe to implement the XEPs and do all data managament which is required to build a modern client. I think it would be much better than redo all the work.

Stefan: that's what snikket SDK is basically. A high level client support layer over libstrophe

I wanted to make a client like telegram in that it lets you properly search chat history (e.g. if you find a message, you can scroll up to that message, no matter if it's on the server or already cached). The mam xep hasn't turned out that friendly to partial, arbitary archive parts fetches, because it lacks sortable message ids, and neither can you rely on time alone. So I'm not sure how msg cache could even work then, it'd have to be a linked list? lol.

You record holes.

I could replicate pages locally, with numbering within those, and make a separate table to keep track of pages I guess...

I think recording holes is better, and is relatively straightforward.

what do you mean? in sql terms

I don't know that it's relatively straightforward but I'm happy to hear new strategies for it

But yes, you end up with something like a linked list, which isn't exactly pleasant.

You could also not cache stuff from the search results

You'd end up creating your own sortable ID, which is certainly icky, but isn't unmanageable, I think.

And yes, not caching the search results is certainly easier.

> creating your own sortable ID, That'd be seemingly be simpler than quasi linked list, but then what if you fetched a,b,c and then g,h,i, while assigning them local ids from 0 to 5, but then you need to fetch d,e,f... do you shift the local ids for g,h,i...? Bruh that very messy

Yes seems like caching like that is unfeasible...

Yeah, 64 bits and twiddle down. This has always been my thought too but I haven't actually implemented yet

You'd use an infeasibly large space, like i64 or something, and do something based on holes, I think. You're right, I misspoke when I suggested it was trivial, there are dragons here. ✏

Is there any scenario where a message can appear between messages already on screen, instead of below or above the already displayed messages? I'm just thinking how to design the chat view api

If you receive a delayed message that might or might not be a way you want to render it

I think I've seen it several times that timestamps mismatch the factual message order in C. When does that happen and should that ever happen?

> If you receive a delayed message that might or might not be a way you want to render it under what circumstances would I receive such message? I think I've only seen <delay ../> in archived messages ↺

Say someone sends a message while their client is disconnected (say mobile client in a subway) some clients will add delay tag when connection is resumed to indicate when it was actually written

Oh, so a delay may come from the client as well as from the server. Hm. I don't think messages should be reordered based on that? I don't want another user to be able to spoof chat history like that

Sure, how you order them is your choice of course

honestly as a user I definitely would not want order to change arbitrarilty depending on the client

What do you mean? *Everything* changes depending on the app. There's no reason to believe any two apps would present things in a similar way or have similar features at all ✏

as the user I hope I see roughly the same thing as my interlocutor. I don't want messages to be lost or randomly reordered.

for example, what if I tap "send" on a message while I have no internet, and then only connect a few hours later, in the span of which my interlocutor has already written a screenful of messages. if his client orders messages by time, my message will end up before his messages, so he may not even see it.

so i think relying on client assigned timestamp for anything other than maybe a hint seems like a terrible idea

doge: I think so too. But other devs think differently. But this is not a protocol issue. And the reason we have many clients is because people disagree on GUI stuff

And believe me this topic is in practice a rather non issue