jdev - 2021-06-30

Anyone ever written an implementation of https://xmpp.org/extensions/xep-0239.html ?

Shame it only supports c2s

moparisthebest: yes :)

Not sure why it's not in prosody-modules

I came across Simple Jabber (https://klemkow.net/sj.pdf) on web. Its takes a unique approach to making XMPP clients. Thoughts?

“The Extensible Messaging and Presence Protocol (XMPP) is like the web. It is far too complex to be implemented in one program with Unix philosophy in mind. But like the web, you have to deal with it”

I think people are still confused about what XMPP is and isn't

pep. +1

Maybe that should be clarified in some XMPP propaganda material. You're not supposed to implement everything

I was interested in section [2].

They propose to split a client into a few daemons in that section. It reminds me of being overly excited about an architectural pattern (splitting things into multiple processes, in this case): it can be nice (especially for daemons, with postfix being a nice example), but can just complicate things (say, make a mess of extensions/shell scripts and make it awkward to deploy and use, using user-facing system facilities instead of

language and library ones). Needs more of analysis/justification/demonstration that it's useful, I think.

"{thing} is complicated, let's make it easier by having multiple programs and a complex architecture to synchronize them" ?

I smell telepathy

how i hate the term overengineered. sure, there are things that could have been done in a simpler fashion or better (especially in hindsight). but often the term is just simply dropped without a deeper understanding of the path that lead to the current state ✏

defanor: Good point.

I see.

Hey, I'm wondering if any client is doing pubsub caching and how it is doing with it? You have no way to check that your are in sync with Pubsub service, even if you are subscribed to it, retract notifications are optional. Furthermore nothing prevent Pubsub service to offer different content depending e.g. on the requesting entity. Not to mention that you may not know the access model so you don't know if you can share a node cache between different users.

I have the feeling that we are lacking tools to deal with that, but just want confirmation in case I've missed something.

sharing caches between users = no-go

that’s always bound to cause pain and sorrow

sure, but it may be a huge space saver. When I'll start to cache tens of thousands of public pubsub nodes, I would avoid to duplicate then between hundred of users.

but I would already be happy to cache reliably for one user, unfortunately in current state of Pubsub it seems not possible.

missing retractions shouldn’t be a problem though. you’ll notice they’re gone when you try to interact with it

I'll have to deal like that for now yes. I'll try to work in the coming months on a protoXEP to improve the situation.