jdev - 2020-03-14

im getting this error from an ejabberd on entering the wrong password

The response provided by the client doesn't match the one we calculated

seems to me like a awfully developer orientied text message

hm no sorry its prosody of course, ejabberd usually has pretty good error text

so is there consense what the text field of an error actually should contain?

i know from history some server devs treat this like a debug string

I think providing such a message at all may be risky and unnecessary: as the RFC mentions, "In order to discourage directory harvest attacks, no differentiation is made between incorrect credentials and a nonexistent username.", while this points at incorrect credentials. Although even if it wasn't for a textual message, the number of challenges (with SCRAM, for instance) would give it up.

i think you misinterpret that security recommendation

its not recommend to send a message like "Password wrong" which means Username is correct, and so you can harvest users

but it does not mean you cant send a message like "Incorrect Credentials" or "Username or Password wrong"

which is exactly what every service i encountered does

ha !

and prosody handles that wrong, its possible to harvest usernames with the prosody sasl impl

Indeed, I was talking about Prosody's message. A non-informative textual message should be fine.

it aborts after <auth> if the username is not known ✏

if it knows the username, it sends a challenge

lovetox, i'd say that <text/> should be user exposable, while encouraging impls to put detailed debug messages into something like <debug-text/>

flow iq allows only one child or not?

so? subchild

yeah k :)

i also think it should be user exposable

that does not mean that every user in the world must understand what that message means

Only very few places in xmpp disallow stuffing another extension element somewhere

but it should be something that a user can easily google or ask for

yep

but to not allienate the user, making to text not to technical may also be a good advise

the standard is weird

https://tools.ietf.org/html/rfc6120#section-6.5.10

so not-authorized is allowed to be sent in response to <auth> and <response>

if i send it in repsonse to <auth> its evident that the username is not existent

because thats the only thing i send in a auth

but you don't have to send it right after auth

also, it is sasl mechanism specific what is send in auth

yeah but i doubt any sever impl, now does a random challenge

for a non existent user

to fake it

yeah im talking about PLAIN, and SCRAm

scram also puts a bit more in the auth, but nothing that would trigger a not-autorized if i do it wrong

hm after auth was successful

and there is a stream restart, is there a order of events

like must the server first send the new stream header

or does it not matter and i can fire it even if i didnt yet receive the server stream header

hi. i requested to get an account for the wiki a while back and was told to wait for someone with admin privileges...

just wanted to check in again

raucao, hey, you should stick around. Not everybody with rights is there everywhere, and they need your email iirc

Ge0rG, Guus ^

oh, could it that there's no message archive for this room?

There is yeah but I don't know if everybody reads everything :)

(I think there is?)

looks like i have a hole in my history from when i wasn't joined

unless there weren't any messages for 7 days

ah, seeing the log link in the topic now. never mind

yeah, looks like MAM is not working for me in this room

(dino.im)

dino doesn't support muc mam

are you sure about that? i'm using it daily in many rooms

what would even be the difference between muc mam and just mam?

is it a different XEP than https://xmpp.org/extensions/xep-0313.html ?

muc mam is just mam on muc :)

And yes dino doesn't do that

it does normal muc history

certainly does not do "normal muc history". have that turned off in my rooms and using MAM

and dino works with it

unless i missed it not working for the last 12 months or so

normal history is just receiving a bunch of messages upon announcing presence, correct?

normal muc history is probably provided by your MAM module

https://github.com/dino/dino/wiki/Supported-XEPs

MUC join is you sending a join presence, you receiving all other occupants' presences, your receive a self presence, then you receive historical messages if there is any, then subject, then live messages

Ask in dino@ if you want

ok, well. i just told you that it works in all of the other many rooms i'm using and that i noticed it only for this room just now

but i'll ask there then

actually, nothing to ask for. i'll just check it myself

they clearly state that MAM is supported ,and they also have it as an option in the room menu

pep., are you using dino daily, or where does that knowledge come from?

"Message history" in the room details is muc history, not MAM

it's not message history

it is.

it's literally message archiving

raucao, pep. is right, dino doesn't do MAM in MUCs (dino dev here)

though if you didn't recognize yet, MUC history isn't that bad it seems 🙂

raucao, sorry I'm not trying to play you

so it lets you enable it but doesn't do it?

that's very not great

https://xmpp.kosmos.org:5443/upload/791c7ed148e453f934ef56e1a4acb79a30845f0f/Eu5C2s84i7IGyDNlMGd1W6YYwrRb1TBxaHlih8MH/Screenshot_from_2020-03-14_18-34-54.png

raucao, enable?

the room options

that's not MAM

for room settings

The MUC configuration form is send from the server and just displayed by dino

That's confusing settings

message archiving is not message archiving?

(not dino's choice)

raucao, message archiving here is MUC history

waaat

guys

Ah wait

No, message archiving is MAM here, you're correct

of course it is

That doesn't mean dino fetches it

raucao, servers can add arbitrary settings there, dino just displays them without knowing what they mean

we don't allow normal history on our server

MUC history is something you get when you join, unless you actively opt-out.

yes, i realize that it's the room setting

That's just options your servers passes you

i know

still abysmal ux to show that and then not support it

no matter where it comes from

so it must be my phone that keeps track of history

raucao, I do agree to some extend, but it's hard to do anything against that

and me being usually joined in the rooms i use

larma: what's so hard about implementing mam?

that's the right thing to do

if it does it for normal conversations anyway

raucao, "what's so hard about .." is probably not the way to do :p

that's a question in response to someone saying it

> but it's hard to do anything against that

that's a valid question

if someone says it's hard

i'm genuinely interested in improving the situation

it's slightly different then normal MAM, you have to target a MUC. You also have to special case MUC-PMs I guess

because i'm highly technical, so if i run into this, then many people will

And.. privacy concerns don't apply at the same points

Though I guess that should be solved when configuring the MUC..

there are no privacy concerns for local archives

a) it's hard to implement MAM, especially with MUCs b) it's hard to filter room settings to not display settings that could be confusing because they don't affect dino

raucao, "local"?

muc mam is stored on the muc

yes, but your local history is stored locally

what you mean is already the room setting

so you can choose it per room

larma: so it's not implemented at all? i understood what pep. said as it being implemented for 1:1 chats

and it's clearly listed in https://github.com/dino/dino/wiki/Supported-XEPs

It is implemented for your local server which means it can and does fetch the history of 1:1 chats

so for MUCs it would have to ask the MUC server is the main difference, aside from slightly different message, due to sender being the muc jid, right?

i added a comment on https://github.com/dino/dino/wiki/Supported-XEPs

so it's clear for people looking at that

sry for being offtopic in here now. the conversations/dino setup works so well for me that i was certain it must have been implemented :)

the complicated part about MAM is not fetching messages, it's about fetching the messages you need, keeping track which you already got etc

yes, but you already solved that

obviously

it becomes more complicated if you have multiple data sources

you only have one, no? the muc server's source

well for the sync process I have mine and all the MUCs I am joined to

yes, of course

but that's only one variable

it's not *that* simple

I am not saying we are not going to implement it

it's on the todo for 0.2 😉

cool

(but it took more than 3 years from 0.0 to 0.1, so not sure what that means)

it's a requirement for reactions which is also planned for 0.2 😉

i would say it's a requirement for all usage of a modern chat app

message history is a basic feature, which users of other chat apps do expect IMO

not just 20 messages "xmpp history", but i mean seamless archives with no holes

you still have the local history, so it's not like things don't work properly

local history doesn't give you missing messages

to me it's broken

it's just that if the server does not provide the necessary muc history to give you the missing messages that you have missing messages

no server will give you 1000 messages

that's probably why you didn't even notice yet that there is no MAM in MUCs

especially not as default config

for normal history

because it's wildly inefficient

you also usually don't look back 1000 messages in a history

no, but more than 20 for sure

the reason i didn't notice is that i usually don't leave rooms

I am not saying it's perfect, but it's good enough for many

well, if you leave a room you don't get its messages

you are not supposed to

i think that's a very counterproductive opinion if you wants users to switch from telegram et al

but you're entitled to it, of course

if you leave a signal or whatsapp group and join again later, you won't be able to read the messages in between

i didn't say signal or whatsapp. those are usually not used with larger groups as chat channels

more like small group of friends

same for IRC

hahaha

or Matrix depending on channel configuration

saying it's as bad as IRC is not a good thing

discourse, slack, etc. are the competitors in this use case

slack, the thing where you can only read the latest 5000 messages in the free version?

they all have seamless history, because otherwise you can't work with people properly

yes, that thing. people do pay for it. that should tell you that it's valuable to have the history

people literally pay money for chat history

it's hilarious, but that's proving how important it is for work

also gitter, mattermost, rocket.chat and all the other ones focused on public rooms

or work rooms

I guess you miss my point. I am not saying we don't want to implement MAM in MUCs, just that there are many occations where it is not wanted the way you are envisioning it