lovetoxim getting this error from an ejabberd on entering the wrong password
lovetoxThe response provided by the client doesn't match the one we calculated
lovetoxseems to me like a awfully developer orientied text message
wurstsalathas joined
clownscihas left
lovetoxhas left
asterixhas left
asterixhas joined
clownscihas joined
Жокирhas joined
paulhas left
paulhas joined
kikuchiyohas joined
larmahas left
larmahas joined
clownscihas left
lovetoxhas joined
lovetoxhm no sorry its prosody of course, ejabberd usually has pretty good error text
Жокирhas left
Жокирhas joined
lovetoxso is there consense what the text field of an error actually should contain?
lovetoxi know from history some server devs treat this like a debug string
defanorI 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.
ajhas joined
ajhas left
lovetoxi think you misinterpret that security recommendation
lovetoxits not recommend to send a message like "Password wrong" which means Username is correct, and so you can harvest users
lovetoxbut it does not mean you cant send a message like "Incorrect Credentials" or "Username or Password wrong"
lovetoxwhich is exactly what every service i encountered does
lovetoxha !
lovetoxand prosody handles that wrong, its possible to harvest usernames with the prosody sasl impl
defanorIndeed, I was talking about Prosody's message. A non-informative textual message should be fine.
lovetoxit aborts after <auth> if the username is no known
lovetoxit aborts after <auth> if the username is not known
lovetoxif it knows the username, it sends a challenge
flowlovetox, i'd say that <text/> should be user exposable, while encouraging impls to put detailed debug messages into something like <debug-text/>
lovetoxflow iq allows only one child or not?
flowso? subchild
lovetoxyeah k :)
lovetoxi also think it should be user exposable
lovetoxthat does not mean that every user in the world must understand what that message means
flowOnly very few places in xmpp disallow stuffing another extension element somewhere
lovetoxbut it should be something that a user can easily google or ask for
flowyep
debaclehas joined
flowbut to not allienate the user, making to text not to technical may also be a good advise
pep.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
pep.Ask in dino@ if you want
raucaook, 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
raucaobut i'll ask there then
raucaoactually, nothing to ask for. i'll just check it myself
raucaothey clearly state that MAM is supported ,and they also have it as an option in the room menu
raucaopep., are you using dino daily, or where does that knowledge come from?
pep."Message history" in the room details is muc history, not MAM
raucaoit's not message history
pep.it is.
raucaoit's literally message archiving
larmaraucao, pep. is right, dino doesn't do MAM in MUCs (dino dev here)
larmathough if you didn't recognize yet, MUC history isn't that bad it seems 🙂
larmaThe MUC configuration form is send from the server and just displayed by dino
pep.That's confusing settings
raucaomessage archiving is not message archiving?
pep.(not dino's choice)
pep.raucao, message archiving here is MUC history
raucaowaaat
raucaoguys
pep.Ah wait
pep.No, message archiving is MAM here, you're correct
raucaoof course it is
pep.That doesn't mean dino fetches it
larmaraucao, servers can add arbitrary settings there, dino just displays them without knowing what they mean
raucaowe don't allow normal history on our server
ZashMUC history is something you get when you join, unless you actively opt-out.
raucaoyes, i realize that it's the room setting
pep.That's just options your servers passes you
raucaoi know
raucaostill abysmal ux to show that and then not support it
raucaono matter where it comes from
raucaoso it must be my phone that keeps track of history
larmaraucao, I do agree to some extend, but it's hard to do anything against that
raucaoand me being usually joined in the rooms i use
raucaolarma: what's so hard about implementing mam?
raucaothat's the right thing to do
raucaoif it does it for normal conversations anyway
pep.raucao, "what's so hard about .." is probably not the way to do :p
raucaothat's a question in response to someone saying it
raucao> but it's hard to do anything against that
raucaothat's a valid question
raucaoif someone says it's hard
raucaoi'm genuinely interested in improving the situation
pep.it's slightly different then normal MAM, you have to target a MUC. You also have to special case MUC-PMs I guess
raucaobecause i'm highly technical, so if i run into this, then many people will
pep.And.. privacy concerns don't apply at the same points
pep.Though I guess that should be solved when configuring the MUC..
raucaothere are no privacy concerns for local archives
larmaa) 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
pep.raucao, "local"?
pep.muc mam is stored on the muc
raucaoyes, but your local history is stored locally
raucaowhat you mean is already the room setting
raucaoso you can choose it per room
Жокирhas left
Жокирhas joined
raucaolarma: so it's not implemented at all? i understood what pep. said as it being implemented for 1:1 chats
raucaoand it's clearly listed in https://github.com/dino/dino/wiki/Supported-XEPs
larmaIt is implemented for your local server which means it can and does fetch the history of 1:1 chats
raucaoso 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?
raucaoi added a comment on https://github.com/dino/dino/wiki/Supported-XEPs
raucaoso it's clear for people looking at that
raucaosry for being offtopic in here now. the conversations/dino setup works so well for me that i was certain it must have been implemented :)
larmathe complicated part about MAM is not fetching messages, it's about fetching the messages you need, keeping track which you already got etc
raucaoyes, but you already solved that
raucaoobviously
larmait becomes more complicated if you have multiple data sources
raucaoyou only have one, no? the muc server's source
larmawell for the sync process I have mine and all the MUCs I am joined to
raucaoyes, of course
raucaobut that's only one variable
larmait's not *that* simple
larmaI am not saying we are not going to implement it
larmait's on the todo for 0.2 😉
raucaocool
larma(but it took more than 3 years from 0.0 to 0.1, so not sure what that means)
kikuchiyohas joined
larmait's a requirement for reactions which is also planned for 0.2 😉
raucaoi would say it's a requirement for all usage of a modern chat app
raucaomessage history is a basic feature, which users of other chat apps do expect IMO
Jeybehas left
Jeybehas joined
raucaonot just 20 messages "xmpp history", but i mean seamless archives with no holes
larmayou still have the local history, so it's not like things don't work properly
raucaolocal history doesn't give you missing messages
raucaoto me it's broken
larmait's just that if the server does not provide the necessary muc history to give you the missing messages that you have missing messages
raucaono server will give you 1000 messages
larmathat's probably why you didn't even notice yet that there is no MAM in MUCs
raucaoespecially not as default config
raucaofor normal history
raucaobecause it's wildly inefficient
larmayou also usually don't look back 1000 messages in a history
raucaono, but more than 20 for sure
raucaothe reason i didn't notice is that i usually don't leave rooms
larmaI am not saying it's perfect, but it's good enough for many
larmawell, if you leave a room you don't get its messages
larmayou are not supposed to
raucaoi think that's a very counterproductive opinion if you wants users to switch from telegram et al
raucaobut you're entitled to it, of course
kikuchiyohas left
larmaif you leave a signal or whatsapp group and join again later, you won't be able to read the messages in between
raucaoi didn't say signal or whatsapp. those are usually not used with larger groups as chat channels
raucaomore like small group of friends
larmasame for IRC
raucaohahaha
larmaor Matrix depending on channel configuration
raucaosaying it's as bad as IRC is not a good thing
raucaodiscourse, slack, etc. are the competitors in this use case
larmaslack, the thing where you can only read the latest 5000 messages in the free version?
raucaothey all have seamless history, because otherwise you can't work with people properly
raucaoyes, that thing. people do pay for it. that should tell you that it's valuable to have the history
raucaopeople literally pay money for chat history
raucaoit's hilarious, but that's proving how important it is for work
raucaoalso gitter, mattermost, rocket.chat and all the other ones focused on public rooms
raucaoor work rooms
larmaI 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