jdev - 2024-03-07

The number one reason of my friends stopping to use Jabber: They forget their password! Is there any XEP for adding an email address/phone number for password reset/recover via mail/SMS? So that it works with IBR, without the hassle of web registration. ✏

IBR already supports extra fields, just that many clients don't implement it

Also get them a password manager

adding an email or phone number is easy, and supported by ibr for sure. But servers would also need to implement a password recovery flow.

Well as long as there's a mail/phone number registered somewhere, admins can at least do something with that manually. Sure it can be automated too but that's a first step

I think a lot of public server admins feel they don't want the security hole that comes from password resets. but it's tough for sure. we have to do full jabber id migrations for customers sometimes because they forget their password and their provider won't recover

I understand the desire for it but also wish more people understood that password recovery being possible at all is, indeed, a security hole

I guess it's pretty common to have only one device though, and devices fail

Password recovery without a mail address is even worse, and it's a thing..

looks like prosody has an un/under documented option additional_registration_fields and the data is at least stored if provided

I totally agree, that password recovery is a *huge* security hole. But it is hard enough for me to convince friends to use Jabber and I will absolutely not teach them about IT security and password managers. There are easier ways to get rid of friends, but no faster ways.

I have two friends and one family member (interestingly all on iOS) who have their third/fourth Jabber account now.

password manager doesn't help anyway if the manager is on your phone and the jabber client is on your phone and you drop your phone in a lake

debacle: maybe you should run a snikket instance and put them all on that so you have the power to reset their passwords ;)

I don't have any non technical friends or family on servers where I can't do password resets for them myself

singpolyma Yes, that is what I will do (not Snikket, but bare prosody plus invitations). But I *hate* to run a service for friends and family and I typically do not recommend it. Worst privacy problems are (contrary to geek mythology) not problems with CIA or what not, but with family members, partners, ex-partners etc.

Get a password manager or don't bother me with your self inflicted problems imho :P

moparisthebest Yes, I can tell them that. Fast way to get rid of friends or at least fast way to get them off Jabber.

XMPP is the least of their problems, without a password manager they'll also be losing access to their email and bank and "getting hacked" etc etc

I can't imagine having family members on public servers. But I agree public servers should consider optionally collecting anything as part of ibr

Friends don't let friends use "hunter2" as a password across all services

yeah, I don't know how people handle password resets on email...

bank they totally forget all the time and have to go into branch

Those people just get a new email constantly I think

well, but if you get a new email you have to get a new *everything*

moparisthebest Somehow they seem to manage that. They have probably services with email or SMS password reset. Jabber is probably the only one without that function.

If a friend kept burning their house down I'd be oddly insistent they get a fire extinguisher and learn to use a stove, idk

the one-device thing is real

> contrary to geek mythology debacle: could've also just said "having never experienced intimate partner violence or stalking"

I'm not sure if ejabberd supports other fields on ibr or not, I don't see in docs but neither did I for prosody but the prosody source is easier for me to read heh

Sure one device but everything is on Google or Apple's cloud no?

moparisthebest: maybe? except that's tied to an email they can't get into either

singpolyma I'm not sure how I can guarantee a functioning service with a lorry factor of *one*. I'm an urban cyclist and like to have friends and family coordinate my burial party over Jabber.

people like this do indeed burn emails constantly

used to have them as clients

debacle: oh yeah, when I die things might be bad. but I'll be dead by then

wgreenhouse That! Stalking, abuse, violence etc. are real problems and typically are *inside* families.

singpolyma What about *your* burial party then? Organized over WA? :-)

Your server isn't gonna turn off when you die

How long are your arrangements gonna take

indeed, as long as the bills are paid it shouldn't stop working

Hopefully my kids are running the server by then...

You never know. Bad luck and Murphy and so on. ✏

I'll probably move them to my own server anyway, but I do really, really do not like that.

Fortunately, most of my Android using friends use Quicksy.

> singpolyma What about *your* burial party then? Organized over WA? :-) hopefully they'll be sensible and not have one

> Fortunately, most of my Android using friends use Quicksy. does it have password recovery?

People should dance on my grave ;-) Yes, because your phone number is your Quicksy JID local part, you can reset your password by SMS as long as you have the same phone number, AFAIK. If you lost your device, you probably can get a new SIM with the same number from your provider, so that works.

debacle: yes, this is how we ended up with the very horrible "phone numbers as authentication" antipattern

so we need to (a) find out if ejabberd supports more ibr fields (b) write best practises for public servers to add ibr fields for email and/or tel (c) actually implement some automated reset stuff

wgreenhouse Unfortunately, it is the best working scheme XMPP has to offer right now.

debacle: no, it's not. it's good in _only_ this respect

account recovery at any cost

As we all know phone numbers prove identity and humanity and can never be stolen

😓

unless they are voip!!!

Yes, phone number ids are horrible, but there seems to be no standard strategy (XEP) for password recovery. I agree with the a/b/c by singpolyma. Maybe there is a better way than the simple "I can get your email, so it's safe". Ideas welcome!

I'm not sure why there would be a XEP for it, does anything have a standard for password recovery?

Websites don't and people don't have a problem, why is this different

automated account recovery always requires either a secondary auth mechanism ("recovery phrase" or whatever) or a contact mechanism

recovery phrases are even more likely to get lost than passwords

so contact is the way to go IMHO

we *might* need a xep because with sasl-non-plain there is no way to have multiple passwords. but maybe we can re-use fast for the recovery tokens or have another sasl mech or whatever we want to do to select auth via a token that isn't my main password

moparisthebest A standard is only necessary, if some interaction between server and client is necessary for password reset or recovery. I'm not sure, if that will be necessary.

singpolyma Will that help in the "lost my only device" scenario?

unless we use recovery https links for the resets. which I'm obviously against because xmpp servers should not contain a web server. but no one else seems to agree hehe

I do, singpolyma ;-)

debacle: sure, because you get emailed or sms'd a token and then you fill it in to your client somehow (or it's an xmpp uri you tap) to trigger account recovery

I mean if they can't remember the password why would they remember the domain part of their JID ?

moparisthebest Because *I* can tell them.

indeed. I have had several people tell me they "gave up on xmpp because they could never remember what server they used"

I know the JIDs of my contacts, they are in my roster.

which seems like a branding problem or something to me, but I'm not sure

debacle: yes, sure, that's true

Give them a password to use too, store it in your password manager lol

Maybe I should just ask all my friends to hand me over their Jabber passwords.

I'm not sure that's more safe than you running their server ;)

moparisthebest Same idea ;-)

I'm not sure, if that's a good idea, just loud thinking: $USER lost their device. They ask for password recovery on the server. At least [1, 2, 3] people in their roster must somehow "agree" for the act of recovery. They are supposed to be informed oob by $USER, of course. Kind of WoT.

set your recovery jid to bob's jid, you trust bob

I think you just invented Bitcoin multisig

debacle: so now 3 of my friends know I put my phone in the toilet?

wgreenhouse: new phone, who dis?

true, that is a classic for a reason

wgreenhouse $USER will invent three different excuses for three friends ;-)

Problem is: Never heard of anyone having problems with their signal or whatsapp or telegram id. Only Jabber makes such a mess :-( Don't remember what Matrix does, though.

I mean, my grandma has three or four facebook accounts and 6 google accounts so it definitely is not just us

but I agree we need a nonzero account recovery story especially on public servers

My mom asks me for a new XMPP password whenever she gets a new phone

public servers shouldn't exist, only small single or family sized ones, problem solved (in some future utopia hopefully...)

moparisthebest I strongly disagree, because of forementioned reasons (domestic violence, family quarrels, etc.) There are people who would trust even Mark Z. and the whole NSA more than their own family.

But yea for the crappy current time period, an email recovery form on a website seems to be good enough for everything else... Servers can do that now, I think some do?

moparisthebest Yes, it works with some servers, if you create the account via web page. But not via IBR, AFAIK, at least I'm not aware of any.

debacle: woah, are you saying domestic violence exists so family servers shouldn't? That seems like a crazy overreaction

If people are in those kind of relationships they should get out, I don't think an XMPP server will make a difference in any way

moparisthebest No, I don't say family servers should not exist, but I say, that it is not the best option for some/many families.

And because of lorry factor, family servers are not an option for the many "zero-to-one-geek families".

I mean, most public servers are bus factor 1 or 2 also

I think it's the best for all families, ones that are violent or whatever just shouldn't be families anymore

But I don't necessarily mean family in the traditional sense, groups of friends, apartment buildings, neighborhoods whatever

singpolyma That is true, unfortunately, but at least some servers are run by companies, clubs or cooperatives with at least a plan in case of dead admin.

Large public servers are bad in numerous ways, not sustainable, scalable, huge single points of failure etc etc etc

I don't think, that the discussion about public servers vs. small/private ones is very productive in the context of password recovery/reset (or lack of). The problem does not exist on small servers, true, but IRL there are too many valid reasons, why they don't exist for everyone. (In my case also: I do not *want* to have that addional work and responsibility.)

0077 defines fields for email, phone number etc. How would I need to setup a server (ejabberd, prosody), that the fields are used and actually stored? Which clients do support the additional fields?

prosody has a setting for it

ejabberd I am not sure

so that's a question that needs to be asked

Could other additional fields be used for "proof" of identity? I.e. password reset via email, but user has to enter their ZIP and date of birth?

Not so secret, not good against targetted attack, but at least relatively safe in case of random hacker from the internet.

That means servers would need to store that too :/

maybe. I mean banks do that :P

moparisthebest: optionally yes

Social security number, mother's maiden name

you can choose to not give the server anything but then no recovery for you. that's a choice you made at that point

moparisthebest All that information should be optional. E.g. *I* know how to use `pass` and will not give that information to any random server.

Will the server store it hashed at least :'(

depends what it's being used for

moparisthebest As an admin, I would not use a server that does not hash that information. Too much responsibility.

I thought it was being used for recovery

hash of zip code is the same as zip code anyway ;)

Same for birthday, I guess.

Indeed, also dob

And phone number.

email slightly less so, but realistically also easy to bruteforce in practise

See all of this has terrible consequences and considerations

If you are requiring *all* of email/dob/zip code you could concatenate and hash them, would be better anyway...

not requiring any of them

Btw. I share a secret now: I use a "standard birthday" which is not my real one for all services which ask for it, but are not linked to my id card or similar ;-)

I mean, requiring all of the ones entered for recovery

oh sure, I have a "city where I was born" and such also

But I use always the same fake dob, otherwise I would not know it ;-) ✏

> Problem is: Never heard of anyone having problems with their signal or whatsapp or telegram id. Only Jabber makes such a mess :-( Don't remember what Matrix does, though. debacle: whatsapp actually is a context where I see this constantly, even though I only talk to like 3 people there one is constantly destroying their phone. they can still log in, but their e2e key changes always

moparisthebest Hashing all fields together sounds good. That can even be possible without requiring them all.

wgreenhouse At least they don't lose all their contacts. OMEMO keys would be lost, too, in case of lost device.

can't do hashes for stuff you want to use for contact though

singpolyma Sure.

It's still not foolproof, just better than nothing

I think the best sites let you specify questions and answers

I expect this kind of user has bigger problems than if server operator knows their current phone number

Answers are just like extra passwords

yes

Phone number for SMS recovery has the drawback of cost. Daniel is pretty annoyed by having to pay a lot for Quicksy SMS.

And stored like them, not a quick hash, an expensive one

cost per message is pretty low. but yeah it's not free

scrypt or whatever the kids are using these days

argon

afk for now, but I'll probably dream of password recovery tonight ;-)

nightmares...

Oh no sorry debacle

moparisthebest No worries ;-)

debacle: https://modules.prosody.im/mod_password_reset.html could be used for what you have in mind.

wgreenhouse, moparisthebest, I also run a full ArchLinuxARM on a OnePlus 6T phone, no chroot needed since the hardware is well-supported in mainline. :) ✏

Only camera is still missing reverse engineering.

is there plans to support multilingual rooms in MUC? reading the MUC xep it seems to say that one room can be only in one language ``` <field var='muc#roominfo_lang' type='text-single' label='Natural Language for Room Discussions'/> ```

Just return text-multi with two values and see what breaks

heh

well it was tested and doesnt seem to work in gajim. if you have only "en" it says English. if you add "en,fr" it says just "en,fr" with nothing else

so stuff already breaks

im just wondering if its something we plan to fix

from what i understand MIX already handles this: > MIX allows specification of a number of human readable strings associated with a MIX channel, in particular the name and description information of a MIX channel. These strings MAY have language set using an xml:lang attribute, and multiple values MAY be set provided that each one is distinguished using xml:lang.

Whad do you mean it says en,fr? Is sees both values?

It sees them but does not interpret them

^

I'm just confused by the comma

whereas "en" appears as "English" and "fr" appears as "French"

gajim is not clear how i should put two languages there

and Kris saw that the xep actually doesnt account for two languages to exist there to begin with

hence why i am here asking

Does it really show a comma? ✏

> When MSavoritias changed it, Gajim displayed it as “en, fr” instead of original “English”.

> Gajim detects MSavoritias' change as “en, fr”, but not “English, French”.

> Yes, I know. When I set it to “zh”, Gajim detects and displays it as “Chinese”, not wrong.

So you didn't put a comma anywhere and gajim read two values with no comma and displayed them comma separated?

i did put a comma. i added "en,fr" in the language box

Oh. That's not two values then

That's one value with a comma

that comment then made me check and ask here > Xep-0045 speaks of language in singular and the example is only one language

> That's one value with a comma hmm let me try

They won't have UI for two values i assume, I was speaking at a protocol level

doesnt work > “en fr”

ah right

but the xep says seem to account for two language at all no?

Did you put a space that time?

yep

at least its not as explicit as MIX

Right. So still not two values

I strongly suspect that if the server returns two values most clients will just show the first one

hmm probably. would it be backwards incompatible to add it to MUC?

so that it can have mutlilingual rooms

as in an arbitary number of languages returned for a room

You mean to change the field type in the xep? That's a council question i guess

I expect implementation doing it to not break much, but would need testing

yeah. change were it says: ``` <field var='muc#roominfo_lang' type='text-single' label='Natural Language for Room Discussions'/> ```

ideally to what MIX has

But text-multi will likely be treated as a single value too

I mean two <value/>

Right, but text-multi isn't quite "multiple pieces of text" - it's defined as a single multi-line value

It's a bit weird that way

Yes, true. I was thinking of open but with language actually list-multi with <open/> would be more right anyway

Just specify it as a comma/space separated list and be done :)

it shouldnt be just two. it should be multiple languages

😬

The format isn't specified at all right now afaik

It's just one of those "examples" in the room config form

also it would be nice to have mutliple descriptions by language imo

now its one description

along with showing presence from offline users

Is it just an example or a registered field?

Yeah

oh

It's registered with the FORM_TYPE

So it's normative

I add something that splits on coma or space and maps it to languages

Add a issue on the Gajim tracker if you like

It currently expects one language code and if it does not map to anything as a fallback we simply show the string

Splitting on comma when we have list types in the language seems... Not awesome ✏

agreed

It really doesn't bother me. It only bothers me that it's underspecified.

<field var='muc#roomconfig_lang' type='text-single' label='Natural Language for Room Discussions'/>

whats wrong with this?

it gives the user a field to write into it whatever he wants

why would we replace this with something more complicated like multiple value field

fair. but then gajim needs to improve the implementation

and speficy how to list mutliple languages there

im pretty sure we give you a field where you can write into whatever you want

just write into it "German, English and some others"

you do. but gajim: 1. shows different things depending on what is written. en -> English but en,fr -> en,fr instead of English,French 2. the example on the left is wrong

if you can't add Klingon, it's not worth it :P

also as i wrote we dont speficify how to actually write multiple values currently

you can't, is how

There can be only one!

its a free text field

you have to ask yourself the question why did you think you can write language codes into it?

gajim told me :D

and also i assume search engines use it to search by language

ah you mean the server told you via config form help text?

ah its the server that shows the message?

https://share.hoerist.com/philipp/YFUM6iJVcWxvSPIs/bf9e81c3-64b0-429e-8d5c-6986db4c11e2.png

so its a misleading help text of the prosody muc config form :D

it says language tag for room (en,fr,etc)

ah its all prosody's fault!

never mind then

we can now follow up and ask why prosody devs think this filed needs to be filled with a "language code"

or tag

rather then a free text field

ejabberd just says Natural language for room Discussions

which is wrong but more right than prosody

but i still dont understand why gajim changes en to English instead of just mirroring what the text field says

its funny that as i often use prosody always, didnt check this, and assumed the spec says it needs to be filled with a language code

and implemented the code for mapping the codes to names

:D

ah ok fair fair :P

i think because historically because of that prosody text, many mucs added a language code

and to make this more pretty i implemented the mapping for *one* lang code

I don't remember why, but the field does indicate that its type is the RFC 5646 format.

And MattJ added text that says it's meant to be the primary language of the room

> and to make this more pretty i implemented the mapping for *one* lang code XD

a search in the muc xep doesnt mention 5646 rfc at all

Could have something to do with https://search.jabber.network/ so it can parse the language code and e.g. translate the name of the language to whatever display language is used

If you want free form info, put it in the description.

it makes more sense not to use language codes then. so i will go with that

If it is a valid language code, it can be used as xml:lang attribute

Zash, that help text was there way before jabber.network existed

i dont know that really, its just a guess, and i would be shocked if not :D

I meant https://hg.prosody.im/trunk/rev/1c709e3d2e5e#l4.1 - the bit about "the primary language" ✏

i mean from a technical perspective language codes make more sense than free text, obviously for any other further computer processing of that field

the MUC search thing has commits going back to May of 2018, around the same time as the language field was added to Prosody itself (tho there had been a 3rd party addon earlier)

> If it is a valid language code, it can be used as xml:lang attribute in what sense? translations of messages?

if it has a usecase as an xml:lang attribute then sure i am all for codes

ah yes https://hg.prosody.im/trunk/rev/9c90cd2fc4c3 https://issues.prosody.im/1149

Hah, ejabberd enforces the language tag syntax?

What are you all complaining about Prosody for then‽

oh jesus. so ejabberd is wrong then in the description

it should say to add language tags

codes*

specifically

> (tho there had been a 3rd party addon earlier) oh, no, that was made at the same time, for earlier prosody versions

I'd love to have a way to specify multiple languages, but XEP-0004 makes it awkward. ✏

i want multiple languages, descriptions, and synopsis if that helps :)

But now there's only one title and one description so only one language makses sense

yeah. which goes to my original question here: can we add that to MUC

Yes We Can

But how?

let me rephrase that: do we want to?

is it backwards compatible

and how awkward would that make the UIs?

from reading the xep it seems we need to do something here: ``` <field var='muc#roomconfig_roomname'> <value>A Dark Cave</value> ```

at least thats what MIX is doing. its basically multiple values its one prefixed with xml:lang > MIX allows specification of a number of human readable strings associated with a MIX channel, in particular the name and description information of a MIX channel. These strings MAY have language set using an xml:lang attribute, and multiple values MAY be set provided that each one is distinguished using xml:lang.

> and how awkward would that make the UIs? you can can keep it exactly as today. you just add a button under the description or next to it that says "add another language" or something

or keep it english in international rooms and be done with it

No thanks

yeah this is a protocol bug imo. and should be fixed

its about time we start using xml:lang more anyways

> If you want free form info, put it in the description. This ↺

xml:lang is a huge anti-feature, neat in theory for protocol nerds, horrific in practice for real world use

*especially* in a multi-user chatroom

you mean multiple languages in a room?

No multiple languages in a room is fine and normal, I'm in quite a few such rooms without problems

If people started declaring the language they were using at the protocol level these rooms would become unusable

Would I start not seeing non-english messages? Would the Spanish speakers not see mine? What about all the messages with both languages? Etc etc

why

that sounds like a ui issue

Most people write messages in both languages, now you gotta flip a toggle each time? That's insanity

It works perfectly as is

MSavoritias (fae,ve): the only question is if we can keep using the same var with a different type, really. I suspect it would break almost nothing and degrade to showing just the first language, but of course the safest would be a new var. No protocol changes are needed though and so long as clients are using a generic form render no client changes either. Well, we may want to get support for <open/> in gajim, I want that anyway

moparisthebest, I'm pretty sure a lot of XMPP implementations (surprisingly) already use xml:lang correctly

Well, as correct as they can (I'm not sure that any actually ask the user what language they are typing a message in)

But translated data forms, etc. work

Yes and that's a use case it's good for

But not sending messages between humans

> Most people write messages in both languages, now you gotta flip a toggle each time? That's insanity If you have spell checking enabled, you'd probably want to have that switch. ↺

I only ever saw multi-language spell checking in Nokia devices from over a decade ago

I used to be enthusiastic about offering stuff in multiple languages simultaneously, but these days I'm less sure (i.e. not sure that what MIX defines is the right way to go)

i plan to ask the languages a person knows when they start using the app

At best it's confusing, at worst it's a security issue

so thats how i will "know"

and then inherit the xml:lang from the message replied to or the person has to change the language manually yeah

idk if i can detect it automatically

There are language-detection tools, though of course they aren't 100% reliable, especially on shorter text

yeah so better manually probably

I would expect that 90% of the time, it stays the same per chat/contact

probably. but i am giving the option :)

But then what I observe is that in multilingual rooms, the conversation can flip/flop between multiple languages organically

same way i plan to make xml really accesible to look at. even though its going to be seen rarely

I think that's fine, people can do what they want to do, the protocol doesn't need to make that more work for them

yeah. it would be nice to have the option. if people use it or not its up to them

I would observe that many posts on Mastodon are language-tagged with the wrong language, probably where the author forgot to change the default.

true sometimes its annoying.

> But then what I observe is that in multilingual rooms, the conversation can flip/flop between multiple languages organically This is 100% what happens ↺

roughly I think xml:lang in human-to-human chat is pretty much always an attack, there is no use-case for it that isn't

data-forms yes, announcements or the like yes, chat, no

all XMPP libraries I've seen and I'm guessing most clients have a `getBestBody(lang)` function, because we are protocol nerds, and this is easy, but it's wrong to use in chats

Generally server-to-user communication (e.g., error messages).

a usecase could be simpler ui

because you can show only the descriptions/titles the person can actually read

and when you add threads there the situation can get much more interesting

and filtering languages can help if there are a lot of languages and you just cant read some of them

example: I'm a troll, I join #poezio where I know all the mods are french, I send: <message> <body lang='fr'> poezio is really nice software, thanks for everyone who made it! </body> <body> everyone in here is a scumbag with a dog for a mother!!!!!! </body> </message>

the more people you have in a chat the more the chances that some people speak a language other people dont

you can troll like that right now and chances are the mods will never see it, pretty great feature of XMPP right?

and?

also your idea of "what languages do you speak" doesn't really work either, I would never say I speak spanish, but I'm in rooms where most of the conversation is spanish, and I can glean enough to get by, I wouldn't want to *not* see those

my app is a f2f network

so in that context it makes sense :)

> and? therefore xml:lang is an anti-feature in human-to-human chat ↺

what's f2f

friend to friend. you can call it also consent network

sometime it would be nice to have AFK language Accept headers

> also your idea of "what languages do you speak" doesn't really work either, I would never say I speak spanish, but I'm in rooms where most of the conversation is spanish, and I can glean enough to get by, I wouldn't want to *not* see those and you can easily add any languages you want or see all messages. it doesnt make sense to forbid people from controlling their space

their space = the app a person is using

so you can't use this network to make new friends? sounds sad and boring

thats besides the point. my point was that the trolls are drastically reduced there

but anyway. i will leave it here. since we are going into other topics

and accounts magically never get hijacked there? you can never make assumptions about remote parties on the internet no matter what

tl;dr clients should always show all language tags in chats like this, and even 1:1, because any more than 1 is probably an attack

... oh i forgot in my database layout, multiple bodys

And multiple subjects probably

And multiple html? Has anyone ever done that?

complexity explosion?

I would probably just store the stanza for such things

Not everything needs to be a column