-
jonasw
Ge0rG: I think it is pretty clear how to send a message to a MUC.
-
Ge0rG
jonasw: but there is no way to know that it arrived :P
-
jonasw
indeed :-)
-
jonasw
uh
-
jonasw
we should try to smuggle a <feature var='muc_keeps_ids' /> in your PR
-
Ge0rG
jonasw: I tried and failed, some two years ago. I think clients that care enough just need to embed a [xep 359] tag
-
jonasw
ah clever
-
Ge0rG
jonasw: I consider it a crude hack.
-
jonasw
depends on the point of view regarding the id uniqueness per stream
-
Ge0rG
I know that XMPP is old, but it's had sufficient time and opportunity to adapt and to make reliable message routing a first class citizen
-
jonasw
will we get that with MIX?
-
jonasw
(.oO(make all <message/>s <iq/>s!)
-
jonasw
)
-
Ge0rG
and instead we've got acks, stream management, carbons, mix, stable-message-ids, which all solve partially overlapping partial problems.
-
jonasw
not sure that anything of acks, SM and Carbons is really overlapping.
-
Ge0rG
I really don't want to get started about this today. I haven't had my coffeine yet, and there is an important meeting in one hour :>
-
jonasw
:D
-
Ge0rG
jonasw: SM and acks both implement message reliability mechanisms, two faces of the same medal.
-
jonasw
but on a different scope
-
Ge0rG
jonasw: it's absolutely the same logic, just different endpoints.
-
jonasw
yes
-
Ge0rG
except one is a message attribute and the other is a nonza.
-
jonasw
that’s what I mean by differetn scope
-
jonasw
*message child element I hope
-
Ge0rG
right.
-
Ge0rG
and then we have the problem that carbons don't carbonate 0184 acks because those are "normal" messages.
-
jonasw
carbons is a mess
-
Ge0rG
I'm asking for multiple years now to replace carbons and "classic" bind with a MAM subscription mechanism.
-
Ge0rG
you authenticate, and instead of doing all the crufty "bind session, enable carbons, query MAM, send presence" just do a nice and simple bind2 with MAM subscription.
-
Ge0rG
depending on the order of the above, you'll get crazy side effecs.
-
jonasw
yeah, I got that from the bind2 xep
-
Ge0rG
but bind2 still doesn't give us MAM subscription
-
jonasw
I was also wondering about a different thing. Assuming I have a MIX in my roster and a client freshly connects to my account. Then right after the connection is established (before the client got a chance to send any disco#info requests), someone writes a message in the MIX and my client thus gets a message from somemix+someuser@mixservice. How is it supposed to know that this is a mix and show the message correctly?
-
jonasw
is MAM subscription a thing?
-
Ge0rG
so we have two different mechanisms for offline and online sync now, with different message retention properties.
-
Ge0rG
jonasw: I suppose your MIX proxy will figure out from the client's caps that it's not MIX enabled
-
jonasw
well, no, the client *can* do MIX
-
jonasw
but it hasn’t seen the account yet
-
Ge0rG
jonasw: otherwise, you're f***ed.
-
Ge0rG
jonasw: this is exactly why I'm complaining about MIX-in-roster
-
jonasw
what does this have to do with MIX-in-roster?
-
Ge0rG
jonasw: implicit join on connect.
-
jonasw
I think that’s a feature
-
Ge0rG
jonasw: until you get a message from a MIX.
-
jonasw
yes well, I need to know that it’s a MIX
-
Ge0rG
yes you do
-
Ge0rG
jonasw: you could spawn a thread to process that message, and have the thread query the domain / plus-less JID / something about what it is.
-
jonasw
thanks, but that’s insane
-
Ge0rG
jonasw: you could also just do a blocking query :P
-
jonasw
that’s not better
-
Ge0rG
jonasw: maybe your client can see that you are in somemix@mixservice from your annotated roster, and thus determine that somemix+someuser@mixservice must be a participant of that mix?
-
jonasw
that could worl
-
jonasw
*work
-
jonasw
if the roster is actually going to be annotated, that could indeed work.
-
jonasw
won’t work for mixes which are not in the roster thoguh
-
Ge0rG
In the context of auto-generated UUID-JIDs for private MUCs/MIXes, there is an interesting question of how to prevent impersonation attacks.
-
jonasw
Ge0rG: reject MIXes/MUCs with anonymous settings for that purpose?
-
jonasw
and then look up the JIDs to make sure they match
-
jonasw
uhm, I may not be so sure about your usecase anymore
-
Ge0rG
jonasw: if the MIX/MUC is on a different server than yours or your inviting contact's, the MIX/MUC can misbehave and feed you "trusted" JIDs
-
jonasw
if you assume that the service is evil, end-to-end is probably the only way out
-
Ge0rG
jonasw: I assume that my own server is not evil, but an evil third-party server might exist.
-
jonasw
still applies
-
Ge0rG
jonasw: I think there is room for a security model somewhere between "trust everybody" and "trust nobody, run e2ee everywhere"
-
Ge0rG
jonasw: something like "trust my server to properly handle MUCs and contacts, and not to lie to me about users' JIDs"
-
Ge0rG
jonasw: otherwise we are deep into sign-MUC-invitations-and-participant-lists-with-OMEMO land
-
jonasw
yes, but that’s not a way to prevent impersonation attacks; that’s a way to say "they don’t matter because those who can execute them won’t do that"
-
Ge0rG
jonasw: good point. Then we really need to sign every presence and message.
-
jonasw
indeed
-
jonasw
or use peer-to-peer MUCs :-)
-
jonasw
(although that still needs E2E)
-
Ge0rG
jonasw: the only secure way to make trusted identities is to route-to-publickeys, like Tor and similar.
-
jonasw
yeah, I do not see that happen with XMPP
-
Tobias
you can perfectly use XMPP with onion domains
-
Ge0rG
Tobias: that's completely orthogonal.
-
Ge0rG
Tobias: unless you want each user to run their own .onion xmpp server.
-
Tobias
right
-
jonasw
why not! that also gives us client-chosen identifiers in JIDs! :>
-
Ge0rG
jonasw: was it jonasw@6HbHXvQ00HcXJMWYlC5lpeU5.onion or jonasw@hC19YDLyWPC6jAFVQDlH78Lf.onion again?
-
jonasw
distributed name services!
-
jonasw
also, you would know, because your client lets you choose by public key (including meta information), not by .onion address
-
Ge0rG
Zooko called, and he wants his triangle back.
-
Ge0rG
jonasw: so I'd choose by "6HbHXvQ00HcXJMWYlC5lpeU5" vs "hC19YDLyWPC6jAFVQDlH78Lf"?
-
jonasw
no, the key with title "Jonas Wielicki" you signed when we met at CLT 2017 ;-)
-
Ge0rG
meta information can be faked.
-
Ge0rG
jonasw: but we never met at CLT 2017.
-
jonasw
now that’s tricky
-
jonasw
;-)
-
Tobias
if we get the lookup/bootstrapping problem solved it doesn't matter how cryptic the JID looks :)
-
Ge0rG
exchanging xmpp addresses is hard enough already without routing-by-publickey
-
Ge0rG
Tobias: are we putting a pubkey-routed overlay network on top of xmpp now?
-
Tobias
I'm certainly not
-
Tobias
put you probably could do serverless XMPP via DHT discovered endpoints :)
-
Tobias
everything is supposed to be serverless nowadays anyways ;)
-
Ge0rG
Tobias: right. or serverless xmpp on .onion domains, to reuse existing tech
-
jonasw
i wanted to implement serverless for fun anyways
-
Tobias
still have the bootstrapping/contact lookup problem though
-
Ge0rG
Tobias: QR codes printed with your blood onto calfskin.
-
Ge0rG
the blood provides a strong binding to your identity, via DNA
-
Ge0rG
maybe there is even some way to cryptographically hash your DNA info to make a truly-personal keypair.
-
Tobias
Ge0rG, people get cloned, then what?
-
Ge0rG
Tobias: only a large government service is able to clone people. This attack vector can be safely ignored for normal people.
-
Tobias
they cloned dolly in the 90s, didn't they..must be dead cheap by now
-
Ge0rG
Tobias: I hope you didn't intend to make that a tasteless pun. :D
-
Tobias
at first not, but now that i reread that message :)
-
jonasw
:D
-
Tobias
nyco, https://mongoose-os.com/ is not related to mongoose XMPP server, is it?
-
nyco
Nope ;-)