jdev - 2025-05-14

i can do one better

setting your password as the email

>> some are moving to passkeys which only work on proprietary OS's which is obviously worse > passkeys work just fine for me on linux so that's moot iOS and Windows and only Android with Google play services, not Android without Google play services, support the "secure" identifier proof thing some websites require ↺

> State of the art is to set your password to 12345 but then forget you added the 5 so do email password reset every time Exactly, xmpp works really hard to hide this from the server for no reason ↺

Also you sent it in plaintext to the server upon registration lol, literally security theater

absolutely good thing for us to replace a good thing with a proprietary solution

what if i cut off my fingers one day

do i just lose access to the stuff i have online?

> Also you sent it in plaintext to the server upon registration lol, literally security theater unless of course.............. the server doesn't store it after that ↺

moparisthebest: it's only between you and the server

> what if i cut off my fingers one day try superglue

my government scan eyeballs now so loosing fingers are fine

why didn't i see this before

quite literally

i wanna scan my eyes to use XMPP

>> Also you sent it in plaintext to the server upon registration lol, literally security theater > unless of course.............. the server doesn't store it after that are you trusting the server or not? If you trust it then why hide your password at all? If you don't why are you using it ↺

trusting it once (upon registering) is different from trusting it always (upon every single time you log in, and even when you're not online) ✏

jokes aside, i think trust is a slide scale, not a boolean. I trust it to exchange encrypted messages and do authentication for convinenency but beyond that which is data is not to be trusted and password is data.

biometric are also data which i think my government store it in the ID card that can do NFC =]]]]

therefore it shouldn't be used as a form of locking things?

i think both has advatange and disadvantage

true

it so happens that my threat model includes the gov, so maybe it wouldn't apply to everyone else

>>> Also you sent it in plaintext to the server upon registration lol, literally security theater >> unless of course.............. the server doesn't store it after that > are you trusting the server or not? If you trust it then why hide your password at all? If you don't why are you using it I don't trust my connection to my server ↺

> trusting it once (upon registering) is different from trusting it always (upon every single time you log in, and even when you're not online) Goot the ticklegoblin!: How ↺

if you don't trust the server with a copy of your password

what do you mean how

you could hash the password before you send or register it

>> are you trusting the server or not? If you trust it then why hide your password at all? If you don't why are you using it > I don't trust my connection to my server Then how can you use XMPP? TLS is what enables this trust ↺

TLS is insufficient, as has been shown multiple times by various MITM attacks

>> trusting it once (upon registering) is different from trusting it always (upon every single time you log in, and even when you're not online) > Goot the ticklegoblin!: How Goot the ticklegoblin!: You said it's different, how is it different, what is your threat model ? ↺

> TLS is insufficient, as has been shown multiple times by various MITM attacks Then you probably can't use anything on the internet ↺

singpolyma: you could go through an anonymizer layer like tor

and have the XMPP service hosted over tor

SASL and scram certainly don't help with the "I don't trust TLS" threat model

that way, the public key is literally stored within the domain, and no MITM attack to fear of because no CA or whatever

> SASL and scram certainly don't help with the "I don't trust TLS" threat model ... that's what they were designed for ↺

scram specifically. nothing to do with sasl

sasl is just detection

you can have scram without sasl and vice versa

> Goot the ticklegoblin!: You said it's different, how is it different, what is your threat model ? out of every time the server receives the password, it only has to be untrustworthy once ↺

if it only receives the password once (upon registering) then that is only 1 chance to store it, steal it, etc

y'know if the server is compromised

it literally doesn't need to steal your password

just change the user's password

that assumes that the attacker has write access

even if the attacker has read access only, it's still a long way to go

(also the attacker needs write access to even affect the server's configuration)

if the attacker has the ability to affect the XMPP server and its behavior, they can already do what they need to do

not necessarily

in what case?

xmpp do omemo and pgp so that's not the whole picture i think

if you have the ability to affect the code of the XMPP service or even the network

then do you really need to steal people's passwords at login?

probably not

anyway i'd think SASL pubkey would be good for this

it does depend upon what "affect the XMPP server and its behavior" means; technically, every interaction with a server affects it in some way (even in the trivial sense of "spends a few CPU cycles and bandwidth to route a message somewhere")

i think passwords or biometric should be hidden from service operator tho.

that would be ideal

how would you hide them?

> anyway i'd think SASL pubkey would be good for this yes. agree very much to have a ssh log-in mechanism

don't get a shell obviously but for xmpp access

>> SASL and scram certainly don't help with the "I don't trust TLS" threat model > ... that's what they were designed for With what threat model? "Sure the attacker can read all my messages, filter out the ones they don't want me to see, and inject any fake ones they like, but maybe they won't see my password !!!!!" Frankly that's the dumbest threat model I've ever heard ↺

i doubt biometrics is as private as a password tbh

moparisthebest: at that point, go use tor or some network layer that has verifiable keys

TLS is fine

then you wouldn't have to worry about malicious CAs or whatever

Don't have to worry about malicious CAs with Dane and/or public key pinning

no browser will ever implement DANE (try to imagine who's been trying to "convince" browser makers)

therefore won't be widely implemented

There are plugins (:

Browsers used to implement public key pinning but removed it 😭

i think tor's strategy is much feasible because the public key IS the identity of the website

although this leads to a very long domain

The concept of CA is the worst idea imaginable tbh

The need to trust some random company to act fairly and not issue fake certs for my domains is laughable

Luckily dane lets us move past that as well. We have a lot of the tools we need to improve things a lot, it's just the slog of getting everything done takes time, but progress is happening

> The need to trust some random company to act fairly and not issue fake certs for my domains is laughable Not some random company, thousands of them equally ↺

>> ... that's what they were designed for > With what threat model? "Sure the attacker can read all my messages, filter out the ones they don't want me to see, and inject any fake ones they like, but maybe they won't see my password !!!!!" Is this really the point of sasl? I always wondered what the point was.

No, that's unrelated to sasl

It's one sarcastic way to describe scram perhaps

they really go together but sure

The point of sasl is to find out what kind of credentials he server accepts (password, token, certificate, oauth, etc)

> they really go together but sure I don't see how? You can use scram without sasl and sasl without scram. They only go together if you want them to ↺

both go into the "no reason to exist in 2025" bucket together 🙃

D Dhat

Lol

I think you just don't know what sasl is or something?

More reason to exist than ever since we keep adding new ways to authenticate

ok, what's the point of scram then?

SCRAM is for if you use a password, it means if you get a MITM they still don't know your password and can't authenticate as you for a second connection (or on another service if you reuse passwords like most do). If you use scram-plus (with TLS 1.3) then it also means authentication will completely fail if there is an MITM so the MITM will fail and no session will be established and they get nothing.

Eventually this will be replaced with OPAQUE which has those same properties but also prevents the server from ever knowing your password to begin with

So if XMPP uses XML, and Matrix uses JSON... but JSON is more compact & simple.. then why is XMPP faster or performs better than Matrix?

Because it's not linked to that

what is the performance reason?

The big difference isn't the way the protocol is transferred, but in that Matrix requires everyone to copy everything-everywhere-all-the-time

ohh, so like in this group chat, it would have to go to all of your home servers

also a markup being "simple" as in lacking of syntax doesn't relate to implementing a library being "simple"

French is a simple language, it only uses the latin alphabet and a few other punctuation points :p

XMPP in general is designed better than Matrix

everytime i use Matrix, it feels like it's held together with duct tape

even Discord (the platform i hate the most) is designed better than Matrix

Which clients support x-roomuser-item so I can test it?

(Reserved nicknames) I'd assume you just need a server with support, not another client?

> 2025-05-14T15:45:49Z - theTedd: > The big difference isn't the way the protocol is transferred, but in that Matrix requires everyone to copy everything-everywhere-all-the-time And it's worth it, HSs might eventually die, the history remains. This is merely a concern for XMPP only because: 1) the dominating E2EE is OMEMO with PFS, which makes MAM useless for long-term storage; 2) most servers have quite limited MAM storage time anyway. While that, Matrix rooms live quite well for years and remain preserved. ↺

> 2025-05-14T16:00:45Z - theTedd: > (Reserved nicknames) I'd assume you just need a server with support, not another client? I'm looking for implementing it in my component, and thus I need a client to test it (if it's worth to be implemented at all). ↺

> 2025-05-14T16:00:45Z - theTedd: > (Reserved nicknames) I'd assume you just need a server with support, not another client? > merely * barely ↺

Okay, Exodus seems to, why didn't I ever see it, huh.

And Converse.JS, and Tigase, and Vacuum which installation is broken now because I removed Qt4 from my system. Meh.

jabber.el does it but not with a UI such that you'd notice unless you knew to look ("Register with service" directed at whatever conference component's jid)

which pops up a dataform to register a nick

I appreciate everyone giving me solid insight into Matrix's failure. I try to convince people to use XMPP, but they keep talking about SimpleX. Do you guys have an opinion on SimpleX?

SimpleX is pretty nice

it's like Signal but fully open-source, no telephone number, etc.

it seems overall positive, only negative thing I've seen documented is that it defaults you onto a public server with content filtering

there are many independent servers operated by others, though

content filtering?

Cynthia: yes, they supposedly have some kind of irreversible hash to take down forwarded copies of content that's been reported to them as illegal

and apply this across the servers run by the dev team

how is that even possible

`if (content_reported_as_illegal) { take_it_down(); }`

i mean like, i assume by forwarding, the client will reencrypt the content with its own key

causing a different hash

Is this true only for public group chats, or if someone is reporting a given URL user

it doesn't make sense

unless it's a client-side thing

They provide the client, so it's enforceable as long as everyone is using that

But this is only for public groups?

https://simplex.chat/blog/20250114-simplex-network-large-groups-privacy-preserving-content-moderation.html

apparently if someone reports illegal (encrypted) shit stored on their file servers, they look into it and then wipe out the files from their servers if it's valid

But how do they validate it the report is not a fake?

the user gives them a group link

> The big difference isn't the way the protocol is transferred, but in that Matrix requires everyone to copy everything-everywhere-all-the-time it's the federation & storage models, rather than the data model ↺

> `if (content_reported_as_illegal) { take_it_down(); }` but this code is in the client? Why can't they just kill it on the dev's server? who cares if you downloaded it locally ↺

> it's the federation & storage models, rather than the data model ok thank you! ↺

What advantage does XML give XMPP? radically different clients can communicate?

It is just what was around the time it got invented and works for the goal

Easy to make the eXtention in xmpp with it

> What advantage does XML give XMPP? radically different clients can communicate? none ↺

How do I avoid repeating the last message history when rejoining a MUC? The have the same IDs, I also added XEP-0359 tags, and nevertheless it doesn't help, they're repeated in clients on every reconnect.

Would XMPP ever switch to JSON?

Would need to be not just JSON. But also no

> 2025-05-14T20:18:11Z - hello!: > Would XMPP ever switch to JSON? BOSH exists, why also not. (doesn't such a mapping even exist already?) ↺

It's kind of possible. There is a fun xep and a real xep

It's only not actually beeing better at anything as far as I heard.

So no reason to bother

> How do I avoid repeating the last message history when rejoining a MUC? The have the same IDs, I also added XEP-0359 tags, and nevertheless it doesn't help, they're repeated in clients on every reconnect. https://xmpp.org/extensions/xep-0045.html#enter-managehistory You can indicate how much history you'd like to receive ↺

> 2025-05-14T21:10:56Z - theTedd: > https://xmpp.org/extensions/xep-0045.html#enter-managehistory > You can indicate how much history you'd like to receive History sender-wise, I mean. The client cannot even know if new messages appeared or not. ✏ ↺

The client can know how long they were disconnected and request "the last 385 seconds"; arguably the server also knows that if they track members; but generally the server shouldn't care - the client asks for what they need, which is often 0 if they use MAM instead ✏

> 2025-05-14T21:20:57Z - theTedd: > The client can know how long they were disconnected and request "the last 385 seconds"; arguably the server also knows that if they track members; but generally the server shouldn't care - the client asks for what they need, which is often 0 if they use MAM instead MAM is not supported there, and clients might know about that if they query features. ↺

So then they should request what they need, and yes that may mean some overlap with what they already have ✏

> 2025-05-14T21:22:46Z - theTedd: > So then they should request what they need, and yes that may mean some overlap with what they already have The problem is that they dealt with such overlaps somehow. I used Jabber MUCs actively on a poor connectivity with frequent reconnects in early 10s, before MAM was introduced, and good clients avoided the history reduplication, even though they were getting the same number of messages every time. Did it get worse since that and they rely on MAM more now? ↺

Either they receive the duplicate messages and filter them out (so they're not displayed to the user), or they request "messages since time I disconnected"

(better: "messages after last message I received")

Pff, indeed https://dev.gajim.org/gajim/gajim/-/commit/d7c0852f9498bab03230af4c0b9e1905920bf1f6

O\

That's unfortunate

There's a fallback at least, just need to support timestamps too then https://dev.narayana.im/narayana/anotherim/blame/branch/master/src/main/java/eu/siacs/conversations/services/XmppConnectionService.java#L3346

But what to do with Gajim then, meh. Some server-side database only then.

I'm afraid to implement a complete MAM support yet, as some clients might trigger a full history retrieval and thus induce rate limits or even bans.

(some old versions of Dino behaved this way, possibly even still relevant)

Actually, yay, a limit might work there.

Just because they request it, doesn't mean they have to receive it (or that it's even available) ✏

There's a limit for the !history command anyway too already, no more than 1000 last messages.

It still might have unwanted side effects though, for example, ruining the edit history preservation (as old messages might get overwritten with their newest versions when MAM is fetched).

If there is limited history then there will be holes and missing messages - there's no way around that. Arguably, if a message edits a missing message, you can just throw it away

Eh, but if so, why would Gajim show duplicates of the messages with the same id and even the same stanza-id in the first place though.

🐞

> 2025-05-14T21:44:03Z - theTedd: > If there is limited history then there will be holes and missing messages - there's no way around that. Arguably, if a message edits a missing message, you can just throw it away I mean that editing existing messages might actually be unwanted. ↺

If messages can be edited then existing messages are already edited?

> 2025-05-14T21:46:49Z - theTedd: > If messages can be edited then existing messages are already edited? See, historically, edits on Telegram side were reflected as separate messages. Which might be useful for "preserving important conversations"™. I still keep an option for that, and also I still use this approach for editing non-last messages all the time (as XEP-wise it would be an UB, even though some clients already support this). When ids were introduced, I just set the Telegram ID for usual messages (even though it violates the unpredictability), and an e-prefixed ID for edits. With mapping IDs this way via MAM, there appears a chance than messages already recorded by a client might get overwritten even with this option. ↺

Is a double-edited message ee-prefixed?

Is there a reason not to use random IDs?

> 2025-05-14T21:57:11Z - theTedd: > Is a double-edited message ee-prefixed? Nope, and that's a downside actually. It would ruin stanza-ids, need to think about it now. ↺

> 2025-05-14T21:57:27Z - theTedd: > Is there a reason not to use random IDs? Ease of message mapping merely. There's a database for origin IDs anyway already, but it's not something to be relied upon really. ↺

Earlier there was no id at all, I introduced it specifically for the reason of parsing. Might introduce some random attachment indeed though which can be predictably cut off.

Message stanzas don't mandate IDs, but obviously modern features rely on them now

BTW, how does MAM deal with replaced messages currently? Different versions of a message might come on different fetches? AFAIR, I specifically commented out the code for preserving an id of the message replacement, as it turned out that it's not needed and further replaces still use the original ID.

> 2025-05-14T22:05:09Z - theTedd: > Message stanzas don't mandate IDs, but obviously modern features rely on them now I wonder if it's an acceptable idea to leave some messages without stanza-id if the chat announces them. ↺

you need to store all message ids, original and corrections, we discussed this on the list lately

MAM just replays all of the messages in order (without replacing) - 'replacement' is done by the receiving client (keeping edit history is a desirable feature)

for example reactions, retractions, moderations etc can reference message ids, and they are not necessarily reference always the original message id

I am having trouble loading btc it keeps canceling on the site.