jdev - 2025-12-08

goffi. Congratulations for XEP-0508 (Forums). Could libraries that support XEP-0060 be utilized to handle XEP-0508 or are there a new API requirements?

> Time to vote to have the XMPP icon in "Font Awesome": > - https://www.reddit.com/r/xmpp/comments/1pgeeq7/time_to_vote_to_have_the_xmpp_icon_in_font_awesome/ A direct link at https://github.com/FortAwesome/Font-Awesome/discussions/21069 (badrihippo) ↺

But why is XEP-508 even needed?

Forums are perfectly implementable using just core XMPP functionality, aren't they?

XEP-508 is too overengineered for this

Better Forums XEP would rely just on MUC and maybe unique stanza id's (to store root post id). Then, client requests category tree, where leaves are thread id + root post id

category tree is not a thing in XMPP

stanza IDs aren't core XMPP either

MUC neither.

Yeah, but the point is PubSub way too complex for this thing

you might be right, it'll be fun to compare your implementation of forums vs implementations of '508 to find out

> Yeah, but the point is PubSub way too complex for this thing Everything in xmpp is a degenerate version of pubsub anyway 😉 ↺

Nah, i'm a firm believer that pubsub is overrated

There is zero need to invent a protocol inside a protocol

I don't know what that even means. Like is said all of xmpp is pubsub shaped except for messages to strangers maybe

singpolyma, i'm talking specifically about XEP-0060, not the concept of publish-subscribe in general

You can always replace 0060 with 0045 they are mostly equivalent especially if you add MAM to 0045. But there may be reasons that would be more annoying than 0060 in many cases

With PubSub you just replace describing XMPP stuff with PubSub stuff while having to do all the same job

No? It's just normal xmpp stuff there's no; magic

Like yes everyone's avatar could be a muc instead of a pep node and then we send presence to it and get back avatar metadata it would work out the same. But I'm not sure it would be better

No, my point wasn't about replacing PubSub/PEP with MUC. It was more about the fact that i don't see how PubSub-based stuff would be any different from the equivalent non-PubSub based stuff in terms of its development. Like, absolutely nothing prevents one from rewriting all the PubSub stuff in terms of plain XMPP (i don't know how to say it better, so i hope my point is at least somewhat visible)

Like, yes, you can make an avatar a PEP node. But you could also just hadn't used PEP at all and make XEP that doesn't rely on it ✏

Sure but that xep would probably be exactly the same as pep...

But with the current approach clients need to implement both PEP and XEP they want. With my approach, though, they only need to implement one XEP. And even if explicit PubSub semantics is ever needed, one can just add something like `semantics="(classic|pubsub|other)"` attribute for stanzas and all the PubSub stuff would be implicitly done server-side without any other participation from the client

There's no need to "implement pep" it's not like it has any bits that need to be implemented for such a use case

> goffi. > Congratulations for XEP-0508 (Forums). > Could libraries that support XEP-0060 be utilized to handle XEP-0508 or are there a new API requirements? Thx. XEP-0508 is designed to work out of the box with generic pubsub services, it's basically like blogging (based on pubsub social feed). If you want a hierarchy though, you'll need pubsub relationship (XEP-0496), but that's totally optional. Other specs may be useful such as pubsub type filtering (XEP-0462) to easily find nodes of interest. ↺

Happy to see pubsub#type be used as it should :)

nice to see xmpp development spread to wider use-cases, moving it into sight for (many) more users; although it remains important (IMO) to keep developing the original use-case (chat/muc/...) so "the others" don't run off with the userbase some more.