Modern XMPP project discussion - 2020-09-16

Hi all 😃

Strypey: hi!

Howdy ;)

I'm a longtime jabber user, and I recently started helping MattJ with community management stuff for Snikket.

nice!

Strypey: 👍

Hi all!

to make XMPP modern again

What's the goal of "Modern xmpp project"? ✏

eyome, hey, have you had a look at https://docs.modernxmpp.org/ yet? ✏

Thank you.

Link Mauve, I added some styling (re DOAP) https://github.com/pulkomandy/xmpp-doap/pull/7 What’s holding back your other PR regarding stylesheets and samples?

Nice!

wurstsalat, which other PR?

#6

https://github.com/pulkomandy/xmpp-doap/pull/6

Hmm, mostly that samples should now be part of https://github.com/xsf/xmpp.org

I see. But can we update the samples (your PR) once more, so they (and the renderings) are compatible with other DOAP files? then everyone could check how it would look for their project until we found a way to bring DOAP files to the xmpp.org repo

Sure.

wurstsalat, DOAP files are already linked in the xmpp.org repository.

where can one see the doap stuff in action on xmpp.org?

See for instance: https://github.com/xsf/xmpp.org/blob/master/data/clients.json#L205

Aside from that, it isn’t used on the website yet.

ah

thanks

I fought Pelican and it won.

😀

stupid bird!

I recently started a Rust parser for those JSON files and for DOAP files.

For instance I can query which projets implement a given XEP.

Or query the name and description and XEPs implemented of a project.

That sounds handy

I think so too.

I don’t know what to do from here, I could expose an HTTP API for instance.

that would make it usable for multiple projects, probably the most flexible approach

Some api where you can quickly query "which version of XEP-XXXX does client Y claim to support" would be nice indeed

Ok, I’ll try to do that in the next few days.

I’d like to help with implementing that (and other stuff) at xmpp.org

I had a look at https://docs.modernxmpp.org/client/groupchat/

and I was wondering what was the exact rule to say what is a channel and what is a group chat

by talking with pep. it seems that it's if (member_only + jid_revealed + publicly_listed) groupchat else channel

because by looking at my bookmarks I do have a few rooms that are sitting between the two definitions

I'm trying to find out if anyone cares about having MUC-PMs set to off to know if it's a private chat :x

Might members-only be the strongest indicator?

if (member_only + jid_revealed + !publicly_listed) groupchat else channel

sorry

Zash, member-only + public?

I'd still consider that a public chat. For example as a temporary measure against spam

And a public chat may choose to reveal JIDs

Conversations has a isPrivateAndNonAnonymousMuc flag

E.g. for transparency/accountability purposes

dino also had separate UI for this

If there seems to be consensus let's document it

https://github.com/iNPUTmice/Conversations/blob/master/src/main/java/eu/siacs/conversations/entities/Conversation.java#L677

i'm wondering what is the rule for Dino actually

And for dino.. https://github.com/dino/dino/blob/master/main/src/ui/avatar_image.vala#L87 ?

https://github.com/iNPUTmice/Conversations/blob/afffe0186865918f8ef637c0cdf2db92e45b4725/src/main/java/eu/siacs/conversations/entities/MucOptions.java#L206-L207

Ah there's a is_private_room function

//the term `private room` is a short hand for members-only+non-anonymous rooms

https://github.com/dino/dino/blob/master/libdino/src/service/muc_manager.vala#L189

neither seem to care about public listing

members only + non-anonymous

publicly listed should not be taken into consideration in my opinion

lovetox, why not?

you probably wanna set that when creating tho

yeah

private does not mean secret

it means only joinable by a defined list of people

That's what Conversations and poezio (!! the impromptu command) default to

What do you call a memberso-only semi-anonymous chat then?

https://lab.louiz.org/poezio/poezio/-/blob/master/poezio/core/core.py#L905 https://github.com/iNPUTmice/Conversations/blob/fa752b596d7fba41a0b62011cd91a11af84b1cd6/src/main/java/eu/siacs/conversations/generator/IqGenerator.java#L519

(it seems that I just started a nice discussion there :D)

non-members-only + non-anon = "transparent" channel?

:D

there is really no need to name all combinations

Also this is "just" a definition that modernxmpp is setting, it doesn't have to mean anything outside modernxmpp

gotta have something to do

private room means, user creates a room for his friends, or some people

and these rooms dont need to be anonymous

so members only + non-anon is this default for these private conversations

and everything else, is a channel

What would "Immutable for groupchats" mean exactly?

https://docs.modernxmpp.org/client/groupchat/

If in the end we're only matching on two of these

if we agree on that, let's set that in stone :p

I'm drafting something, but I'm curious about the "immutable" thing. I'd rather change places where it's set and use that as a sign for groupchats

pep.: it helps to look at the question opposite to how this conversation started

What ultimately matters is what the user intends the chat to be

I might want to nit on the terminology then. Something like "default", and add a description that says these options SHOULD be immutable in a configuration dialog

The idea is that the client offers to create one or the other, and the "immutable" ones are simply those that shouldn't be configurable by the user for those chats

This text doesn't necessarily assume there *is* a way to tell the difference post-creation

Ok let me try to draft something :x

Obviously in the real world we don't (currently?) have a flag to record the user intent

Hence clients using this hack instead

But I think that is one of the things I would like to fix in MUC

Will we ever? "So.. ok I will create you a room but first why do you want one? Do you: - Want to chat publicly? - Want to chat publicly and allow many to join? - Want to chat publicly and allow encryption? - Want to chat in private but allow others to see?" - .."

I don't want this :P

Fix how?

Record that boolean?

Or maybe the "I found a name for each combination" version: "Do you want: - A groupchat - A transparent room - A secret room -A channel"

muc#modernxmpp_private: bool

{xmpp:modernxmpp.org}muc#preset = "channel" | "groupchat" | <custom>

lgtm

im not sure you solve a actual problem

the problem was/is the default config when we create a room

and not afterwards to know if its a groupchat or channel

well there's both

You need to know how to detect it from other clients

So if the server locks the relevant settings while muc#preset ≠ custom

why would i need to know pep. ?

i use non-anonymous and members only, only for the notification setting

because say I'll display a different type of avatar (like dino and conversations do), I'll set a different notification setting, I'll change terminology, or I'll prevent some options from being overwritten

etc.

yeah then you do this based on the attributes we already discussed

but there is no need to make now names and rules for all 3000 configuration combinations

That's what I'm saying. You do need to be able to discover that this is a "groupchat"

no indeed

Well

That's not what modernxmpp is trying to do I think?

Somebody might want to and I'd be fine with that

I might not use it and that's it

Just to say that there's is no one-size-fits-all. "42" is a myth (sorry)

#BreakingDreams

MattJ, "I think that is one of the things I would like to fix in MUC" does this really needs fixing in MUC?

Can it not just be on modernxmpp?

It would still be standard, public, in its own NS (just like Zash did), etc. so everybody wanting to use the modernxmpp definition would match on it

> MattJ, "I think that is one of the things I would like to fix in MUC" does this really needs fixing in MUC? Yes. Creating a room today is stupidly difficult for clients. Multiple round-trips and various hacks.

Yet we've essentially settled on just two "profiles" for MUC rooms

Ah you want a <presence to="foo@bar"><create-group-chat xmlns="xmpp:modernxmpp.org"/></presence> ?

Yes and no. I was thinking <iq> 🙂

Right

But basically yes, make creating a room explicit instead of implicit, and a proper iq set/result pair to indicate success

and fix the configuration chaos at the same time

I'm happy with profiles, I don't know if that has to be in 0045 though

You'd just be enforcing more UX in the XEP

iq.set"room@muc.host"/{somethingmuc}create/{jabber❌data}form

No, I don't know if it has to be in XEP-0045 either. I think I'd rather it wasn't (isn't it Final anyway?)

No, still Draft

I remember stpeter trying to drive it to Final as one of his last achievements before retiring as Editor, and here we are 🙂

I don't personally care about Final or else, if it has to be changed.. And creating a new XEP that says "this extends it" is exactly the same to me

Sure

But I think this belongs on modernxmpp.org rather

Why isn't https://xmpp.org/extensions/xep-0307.html the creation thing?

hmm I'm still blocking on "Immutable" :/

pretend it says "fixed" or "required"?

Yes

Creating a room is stupidly hard for clients today

"fixed" or "required" doesn't help me much here

With the document as it is, are we trying to say that's what we would enforce in a modernxmpp-only world?

And so publicly-listed non-anon members-only wouldn't exist?

When lovetox was arguing for the opposite just above

I'd say if you want something else, hide it in some "Advanced" section

Zash, so it's not immutable?

Can that be changed?

I'd be happier with "default", but maybe I'm misunderstanding the original meaning

Maybe just some text text saying that for a private chat, the settings should normally be hidden away

If you say it's just a "default" then you're really opening up the door to confusion about what is/isn't a channel

The point is that a private chat would always want those settings to be the same

So clients should also match on all of these 4 options?

and I'm not even sure if it should be possible to override, at risk of making private chats accidentally public, for example

("because there's no reason these get changed")

MattJ, I agree that it doesn't help to be able to change stuff afterwards and I'm happy for modernxmpp to mandate these 4 options. I'm just observing that it's not what clients are doing

Are these clients following modernxmpp or just taking inspiration from it.. who knows :P

It's a mix of documenting what today's "correct" clients are doing, and trying to make sure everyone is on the right and sensible path :/

Looking at the options again, I do think all these options should be mandatory for private groups

I think PMs are just the cherry-on-top and it doesn't really matter, but yeah why not

It's tricky because public channels on the other hand may overlap here (e.g. temporary members-only due to spam, as mentioned earlier)

Well there isn't really an option for PMs, is there?

I think there is?

I think it's more just "don't use in-room PMs in this context"

<dinner>

Ah maybe not

I thought there was a muc#allow_pm

So maybe we should also define that

muc#roomconfig_allowpm

that

Does prosody understand it?

not

ok

patches welcome :)

One thing at a time

but ejabberd understands it

Sure. The option can still be set and we recommend clients to not use PMs

It wouldn't work every other time anyway

but in a private room

if i know the full jid

i can open a 1:1 anyway

Yes

or at least i plan that Gajim will do this in the near futur

That's what we're saying. If you know the realjid you should use realjids

False! That's what some clients (Pidgin iirc) do. It leaks the real JID of admins who initiate PMs in semi-anon MUCs

what

Right ok

Could maybe make an exception if the target is in your roster

You should use realjids when `muc#roomconfig_whois` is set to `anyone`

Just don't want lovetox to go and implement the wrong logic :)

We should document this too

I'm also adding a paragraph on this

Thanks!

good point MattJ i didnt think about that case, thanks

ah no we did think about this case :D

but was good to check again

maybe i should add a comment to the code

https://github.com/modernxmpp/modernxmpp/pull/33

shoot, I used the taboo word ("clarification")

U dun goofed

You what?

Merged

okay

Now.. we're gonna have to work on clients

hmm, *refrain from.

and various other english mistakes?

Good catch, I don't see anything else

https://github.com/modernxmpp/modernxmpp/pull/34

Merged