Ge0rG: I think it is pretty clear how to send a message to a MUC.
danielhas joined
Guushas left
Guushas joined
danielhas left
danielhas joined
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
sonnyhas joined
kalkinhas left
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
kalkinhas joined
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.
Manchohas left
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
nicolas.veritehas left
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
danielhas left
jonasw
well, no, the client *can* do MIX
jonasw
but it hasn’t seen the account yet
Ge0rG
jonasw: otherwise, you're f***ed.
danielhas joined
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
nicolas.veritehas joined
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
suzyohas left
xnyhpshas left
Valerianhas joined
suzyohas joined
sonnyhas joined
jubalhhas joined
uchas left
Tobiashas joined
Tobiashas joined
devnullhas left
devnullhas joined
ralphmhas left
uchas joined
danielhas left
danielhas joined
goffihas joined
kalkinhas left
suzyohas left
kalkinhas joined
mhterreshas joined
Martinhas joined
Steve Killehas left
Steve Killehas left
Flowhas joined
Steve Killehas joined
Piotr Nosekhas left
Steve Killehas left
danielhas left
danielhas joined
danielhas left
danielhas joined
jubalhhas left
kaboomhas joined
danielhas left
danielhas joined
blipphas left
tim@boese-ban.dehas joined
danielhas left
danielhas joined
Ge0rGhas joined
Manchohas left
suzyohas joined
vurpohas left
sonnyhas joined
kalkinhas left
kalkinhas joined
vurpohas left
vurpohas joined
sonnyhas joined
Lancehas left
uchas left
uchas joined
Ge0rGhas left
xnyhpshas left
danielhas left
danielhas joined
sonnyhas joined
kaboomhas left
Valerianhas left
Valerianhas joined
danielhas left
danielhas joined
sonnyhas joined
Alexhas joined
Yagizahas left
kalkinhas left
jerehas joined
jerehas left
jerehas joined
Valerianhas left
jerehas left
jerehas joined
Alexhas left
kalkinhas joined
danielhas left
Ge0rG
In the context of auto-generated UUID-JIDs for private MUCs/MIXes, there is an interesting question of how to prevent impersonation attacks.
waqashas joined
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
jerehas joined
jerehas joined
blipphas left
blipphas joined
Martinhas left
Martinhas joined
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
Yagizahas joined
Ge0rG
jonasw: I assume that my own server is not evil, but an evil third-party server might exist.
jonasw
still applies
Valerianhas joined
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)
nicolas.veritehas left
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
sonnyhas left
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 :)
Alexhas joined
Piotr Nosekhas joined
jonasw
:D
Guushas left
suzyohas left
Guushas joined
jerehas joined
jerehas joined
danielhas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
danielhas left
danielhas left
winfriedhas joined
Ge0rGhas joined
Martinhas left
sonnyhas joined
Martinhas joined
sonnyhas joined
Guushas left
Guushas joined
Alexhas left
Ge0rGhas left
Guushas left
vurpohas left
vurpohas joined
Guushas joined
sonnyhas joined
Zashhas joined
danielhas left
danielhas left
sonnyhas left
sonnyhas left
sonnyhas left
vurpohas left
vurpohas joined
sonnyhas joined
Alexhas joined
tim@boese-ban.dehas joined
Piotr Nosekhas left
Guushas left
Guushas joined
danielhas left
danielhas left
Tobias
nyco, https://mongoose-os.com/ is not related to mongoose XMPP server, is it?