XSF Discussion - 2018-03-18

For info: https://dev.gajim.org/gajim/gajim/blob/gajim-1.0.0/ChangeLog

Dave Cridland hi :)

Where do I vote for having Dave be put in charge of naming things?

Try the having-vote-place.

So I just put "Dave gets to name things" on a blank vote in the coming general elections?

:D

I wasn’t sure whether he was drunk and whether I should really merge that :-)

https://news.ycombinator.com/item?id=16611579

Pigeon, one of the two big players in xmpp.

looking at my roster, its still widely used :(

tim@boese-ban.de: I've heard of a client called Pidgin, which has a pigeon logo.

Ge0rG, I think the author wanted to say pidgin

I've also heard about it

tim@boese-ban.de: I don't know. Maybe. But even then, claiming that pidgin and empathy, of all, are the important clients, is a very wide stretch

Ge0rG: ah ah

gaim :D

It's like I would use my HN karma to advertise yaxim, which nobody has ever heard of.

http://www.tuteurs.ens.fr/logiciels/gaim_1.png

,oO( https://du7ybees82p4m.cloudfront.net/5710e5c78b7945.23147303.jpg?width=910&height=512 )

Miam

Ge0rG: The are or have been shipped by major distros as The Default, so it's safe to assume that they are widely used.

That sounds like the Internet Explorer argument.

Ge0rG: I suppose "important" isn't the right word

But something

The IE situation is not too far off tho.

The new bookmarks looks like a sensible cleanup of the old mess, but it's not going far enough in my eyes. It would be nice to have some kind of per device / per device class autojoin, and the nickname should be stored either centrally or in each bookmark to prevent conversations from automatically using my local part

There's a XEP for that

The Centralized Canonical Nickname

-xep user nickname

Zash: User Nickname (Standards Track, Draft, 2012-03-21) See: https://xmpp.org/extensions/xep-0172.html

So all the user's clients should subscribe to the pep node.

Ge0rG: that sounds good, I have mucs I want to autojoin everywhere but also mucs I only want to autojoin from the desktop

but this seems a bit complicated to me

how would you identify the devices?

with resource seems a bit flaky

I think clients should just keep their own overrides

trying to categorise clients is too complex

yeah so if you bookmark a channel from your phone, and you have a checkbox "autojoin only from this device", the client should set autojoin=false to pep, and save a override for this bookmark localy in the db

so this works also now, no need to add anything to the xep

Yep

and clients don't have to support this if they don't want to, so it keeps the protocol simple

so how far are we in prosody with publish options and persistence support?

persistence is in trunk, if you enable mod_pep_plus (this is still considered 'beta', and will be merged into mod_pep after more people have tested it)

publish-options is in progress, mostly done I think, I just need to test it

what i also thought when ready the new xep, would it not be easier to let the server just set the correct node config for the new bookmark namespace

instead of hoping that every dev reads the xep and applies publish options

*read

Then again the client dev can't just blindly publish bookmarks hoping the server will do that.

if its written in the xep that the server must do this ..

It's not today.

Ah the new one.

its also not mentioned there

but there is something in there, that the server has to merge items or stuff

so server has to do something for this xep anyway

oh really?

I'd better read it then...

When a client publishes a new item, the server MAY collate all items, casting them into the 'storage:bookmarks' namespace and setting the jid attribute to the item id in each case.

but yeah all optional

Dave Cridland, what are the "security reasons" mentioned for the password field? Is it because you don't want that to be clear on the server? Or on the client? (or both)

Also SamWhited ^

i find this a bit overboard to remove password from the xep

same

only because the admin of the server can read the password?

so what nobody cares

regular people just set the password to hinder other regular people to join the channel

not to protect super secret information from bad server admins

its probably easier for the admin to just read the logs

If you're protecting from the admin, they can just reset your password and log in as you and join a members-only room anyway

also the description: Unencrypted string for the password needed to enter a password-protected room.

it would not help in any way if the password would be unkown to the admin

There's technically sasl for MUC, but I think Prosody is the only implementation, don't think any clients implement it.

admin can do what he wants

But as MattJ said, admins can usually reset passwords, and often just modify the server if they want to

so i even question the "not recommended"

i think this stems from a time, where xmpp connections where not TLS secured

or it was not that common

*were

but then an attacker would see the password when you send it to the room anyway...

and so would the server admin :)

mod_log_room_passwords would be trivial :)

so yes, I don't think this is really protecting anyone from anything

no i meant the warning about sending passwords unencrypted stems from a time where TLS was not common

Right

today i see no problem with it because we can assume everything is TLS

and we cant do anything against admin anyway

The only other thing you might be protecting against is someone who gains access to your account

If passwords are not in bookmarks, a new device has to ask for passwords for autojoin MUCs on initial use

first thing that will happen if we dont sync passwords, people will come and ask for password sync xep :D

MattJ, I think at this point you've pretty much lost already

I wouldn't worry about some random MUC's passwords

The MUC owner may :)

You can just change the password..

is there any client that has some cool concept for message type "normal" ?

I think psi has a different view for them

gajim now opens a single email like window, where you can answer and prev message is quoted

lovetox: will that window steal focus?

MattJ, one issue I can see is another user gaining access to the muc, and then mam_muc

Ge0rG, depends, default you get only a notification and if you open the notification the window opens

Not sure what to do exactly for this, but I don't think the issue is the password

so no, its not that horrible

Ah, that's okay I suppose

:D

i mean i could make a window like a email client

that looks like a inbox

and all messages go in there

but this really feels weird, like if you want email just use email

lovetox: and are there still dialogs in 1.0 where the JID is split into two input fields for local part and host?

lovetox: and are there still dialogs in 1.0 where the JID is split into two input fields for local part and host?

lovetox: and are there still dialogs in 1.0 where the JID is split into two input fields for local part and host?

Sigh. I really need to fix this race condition.

wow you sent this message 3 times

:D

am yes i know its a wish of yours, but account creation assistent has not been reworked

but i guess its a good idea to add for the gajim 1.1 milestone

lovetox: I wrote it during a stream resume, so it was first delivered normally but didn't count for the stanza counter, then it was delivered again by 0198 and then again by the sync after connect code. It's a nasty race condition I really need to fix

Ge0rG, at least you're not losing the message :-°