Modern XMPP project discussion - 2026-02-24

> You can make an is_joined program that takes an XMPP stanza from the client, extracts the requester JID and room URI, and produces a yes/no/maybe signal. why don't you just make the MUC members-only? ↺

then, maybe, have the bot send invites based on the hats people get in other MUCs

Does anyone here know if that "request voice" button in sone clients is specified in a XEP?

See: https://github.com/nioc/xmpp-web/issues/157

I assume it's somewhere in XEP-0045 ?

https://xmpp.org/extensions/xep-0045.html#requestvoice

I guess

Yep

> If you separate the two needs, 'I want a *secret* conversation' and 'I want a *publicly searchable wiki*, it makes it so much easier to tell what kind of cryptographic hammer to use and where the correct nails are. Don't forget "private project coordination tool", i.e. what Slack tries to be. I think in that use case you are better off treating the conversation more like a shared document. Participants will come and go and they should get access including history for and only for they are part of the team. Cryptographically-wise I think something along the lines of Tahoe-LAFS/MagicFolder would be the best bet. I know that Keybase tried to cater to this use case before they got bought but I've never tried it and don't know their design past what they offered as PKI. ↺

Otherwise absolutely agreed in that different uses need very different designs, often from ground up.

RIP Google Wave

ultimatly this is the latest iteration of the age old wiki Vs. forum argument. Yes a well maintained wiki is better than a forum as a knowledge repository, but maintaining a wiki is a lot of effort and rarely done.

so people used forums because those were actually used and worked ok as ad-hoc knowledge repositories.

now that chat has replaced forums, we see the same argument but slighly modified.

git + markdown files > everything

very high barrier of entry for non-technical people, even worse than wikis

it is ok for individual project documentation, but once you need to collaboratively work on documentation git is terrible

Chats as wikis are just access controlled markdown pages, prove me wrong.

>> You can make an is_joined program that takes an XMPP stanza from the client, extracts the requester JID and room URI, and produces a yes/no/maybe signal. > > why don't you just make the MUC members-only? Different needs, different solutions. I'm pointing out how easy it is to instrument dynamic access requirements with logic if you have sockets to attach to instead of program libraries. ↺

> Different needs, different solutions. I'm pointing out how easy it is to instrument dynamic access requirements with logic if you have sockets to attach to instead of program libraries. not to discourage or disprove your point. But do you have any practical case where this may be helpful? I was of the impression that you'd want something similar to "this role get access to this room/perk" that discord has, so ↺

Me. I'm the practical case. If you have any questions, when I do the work you can refer to my proof-of-concept, and if you don't like it, I won't push it on you. That's how open source development works.

Consider that it may be more harmful to your program to bake in a feature users cannot configure instead of exposing the logic stream to outside programs, especially when there is an optimal kernel mechanism for this.

In other words, if you design your programs prescribing what the users want rather than implementing independent components, when the users want new or different abilities, instead of simply plugging in a new component, they must recompile your program, despite that not being necessary. ✏

heya

Yo.