Modern XMPP project discussion - 2022-04-30

does anyone have a link to a page explaining the (likely) requirements for using OMEMO in MUCs?

raucao: found this https://wiki.xmpp.org/web/Tech_pages/OMEMO/MUC

thx

Curious... what's your client's message archive preference setting set to? In Conversations, my options are: Never, Contacts, Always. It sounds like you may choose one option over another depending on device type and other factors.

For privacy, **Never** sounds like it would be best (so long as your device has the space for it). For convenience, **Always** would let different devices gain and regain access to those messages. But how long can they really stay on the server?

By the way, is this room considered a good place for general XMPP (IM) user discussion? I can't seem to find one -- everything is very niche (app, server, or protocol related).

If no, we definitely need one.

xmpp:chat@joinjabber.org?join There is also this room crypt Its supposed to be for easy onboarding and for new users to ask questionr

It may be what you are looking for

I guess you're saying this isn't it. Even though I would like to discuss many things that are related to XMPP's messenger use case.

We need use case rooms just as XSF needs use case working groups.

Too often things go #offtopic in a niche room.

Ok, so I'll ask something specific to the purpose of this room. After meeting and wiki updates, do any of the client devs take steps to implement your recommendations?

crypt, in a small way, perhaps. Most of the current recommendations reflect current consensus (not always unanimous) among developers

But I don't know that any client developers are committed to following recommendations at modernxmpp.org

So they're posted as a reference for anyone who cares to look.

So modernxmpp.org is mostly documenting consensus and best practices that aren't necessarily clear from just XEPs

When I launched the project, I had more ambitions, but I mostly diverted those into Snikket

(once it became clear that getting multiple teams of people to agree on something is a ridiculously hard/impossible task)

Sounds like the group needs to add "commitment" project/dev members. ✏

It's not really that easy. Pretty much all the projects involved are open-source, and open-source developers run to their own schedule, priorities and ultimately answer to their users

> MattJ: > 2022-04-30 02:29 (CDT) > (once it became clear that getting multiple teams of people to agree on something is a ridiculously hard/impossible task) LOL - I believe it

The best anyone can reasonably do is provide guidance (and rationale for the guidance), so that's my main focus with modernxmpp.org these days

I understand. But the original intention is good.

I commented is XSF Discussion there needs to be official working groups for each use case.

They're all over the place with what they want to do with XMPP.

Even their website posts about these use cases, but really don't segment anything.

All XEPs listed in their directory are unfilterable by use case.

All mashed together for unrelated projects.

That's why https://docs.modernxmpp.org/client/protocol/ exists

It's not just a list, but also provides context and explanation about each XEP it links to

> MattJ: > 2022-04-30 02:36 (CDT) > That's why https://docs.modernxmpp.org/client/protocol/ exists EXACTLY

So this group wants to be the go between between client devs and the XSF. Providing guidance both ways. ✏

If it was an official working group in the XSF (under the messenger use case) it would hold more weight.

I guess, partly, yes. The main problem I saw was that the XSF has historically only specified protocol details in its specifications, and actively discourages any recommendations about user interfaces. I didn't see that changing any time soon, yet I knew there was a lot of stuff about user interfaces that needed to be documented.

Since then it's become a general place for documenting any kind of stuff that doesn't fit at the XSF (basically, almost anything that isn't a protocol extension)

So should there be a non-protocol XMPP body that tackles other things that they're not interested in?

I can see working with the XSF to improve things is not their forte.

I'm trying to think... _What's other there that tried to fix a similar problem?_

Have you guys had that talk?

> MattJ: > 2022-04-30 02:41 (CDT) > Since then it's become a general place for documenting any kind of stuff that doesn't fit at the XSF (basically, almost anything that isn't a protocol extension) Then they should rename themselves to XEP Discussion.

You are also trying to create "standards" for XMPP clients.

> the xmpp standards foundation (also known as the xsf)

They just choose to focus on XEPs.

Rant... over. Enjoy your weekend everybody.

crypt, for the record, I'm thoroughly a part of the XSF

It's not an "us and them" situation

Non-XEP documentation was needed, so non-XEP documentation got created

I don't think it needs to be a problem that it's not an XSF thing

👍

It's none of my business, really. I'm just a user looking for a secure messenger alternative.

and that's why Snikket exists ;)

I'll stick to Conversations for my noob related question so the adults can discuss protocol and implementation.