jonaswGe0rG: I think it is pretty clear how to send a message to a MUC.
danielhas joined
Guushas left
Guushas joined
danielhas left
danielhas joined
Ge0rGjonasw: but there is no way to know that it arrived :P
jonaswindeed :-)
jonaswuh
jonaswwe should try to smuggle a <feature var='muc_keeps_ids' /> in your PR
sonnyhas joined
kalkinhas left
Ge0rGjonasw: I tried and failed, some two years ago. I think clients that care enough just need to embed a [xep 359] tag
jonaswah clever
Ge0rGjonasw: I consider it a crude hack.
jonaswdepends on the point of view regarding the id uniqueness per stream
Ge0rGI 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
jonaswwill we get that with MIX?
jonasw(.oO(make all <message/>s <iq/>s!)
jonasw)
Ge0rGand instead we've got acks, stream management, carbons, mix, stable-message-ids, which all solve partially overlapping partial problems.
jonaswnot sure that anything of acks, SM and Carbons is really overlapping.
Ge0rGI 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
Ge0rGjonasw: SM and acks both implement message reliability mechanisms, two faces of the same medal.
jonaswbut on a different scope
Ge0rGjonasw: it's absolutely the same logic, just different endpoints.
jonaswyes
Ge0rGexcept one is a message attribute and the other is a nonza.
jonaswthat’s what I mean by differetn scope
jonasw*message child element I hope
Ge0rGright.
Ge0rGand then we have the problem that carbons don't carbonate 0184 acks because those are "normal" messages.
jonaswcarbons is a mess
Ge0rGI'm asking for multiple years now to replace carbons and "classic" bind with a MAM subscription mechanism.
Manchohas left
Ge0rGyou 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.
Ge0rGdepending on the order of the above, you'll get crazy side effecs.
jonaswyeah, I got that from the bind2 xep
Ge0rGbut bind2 still doesn't give us MAM subscription
nicolas.veritehas left
jonaswI 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?
jonaswis MAM subscription a thing?
Ge0rGso we have two different mechanisms for offline and online sync now, with different message retention properties.
Ge0rGjonasw: I suppose your MIX proxy will figure out from the client's caps that it's not MIX enabled
danielhas left
jonaswwell, no, the client *can* do MIX
jonaswbut it hasn’t seen the account yet
Ge0rGjonasw: otherwise, you're f***ed.
danielhas joined
Ge0rGjonasw: this is exactly why I'm complaining about MIX-in-roster
jonaswwhat does this have to do with MIX-in-roster?
Ge0rGjonasw: implicit join on connect.
jonaswI think that’s a feature
Ge0rGjonasw: until you get a message from a MIX.
jonaswyes well, I need to know that it’s a MIX
Ge0rGyes you do
Ge0rGjonasw: you could spawn a thread to process that message, and have the thread query the domain / plus-less JID / something about what it is.
jonaswthanks, but that’s insane
Ge0rGjonasw: you could also just do a blocking query :P
jonaswthat’s not better
nicolas.veritehas joined
Ge0rGjonasw: 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?
jonaswthat could worl
jonasw*work
jonaswif the roster is actually going to be annotated, that could indeed work.
jonaswwon’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
Ge0rGIn the context of auto-generated UUID-JIDs for private MUCs/MIXes, there is an interesting question of how to prevent impersonation attacks.
waqashas joined
jonaswGe0rG: reject MIXes/MUCs with anonymous settings for that purpose?
jonaswand then look up the JIDs to make sure they match
jonaswuhm, I may not be so sure about your usecase anymore
jerehas joined
jerehas joined
blipphas left
blipphas joined
Martinhas left
Martinhas joined
Ge0rGjonasw: 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
jonaswif you assume that the service is evil, end-to-end is probably the only way out
Yagizahas joined
Ge0rGjonasw: I assume that my own server is not evil, but an evil third-party server might exist.
jonaswstill applies
Valerianhas joined
Ge0rGjonasw: I think there is room for a security model somewhere between "trust everybody" and "trust nobody, run e2ee everywhere"
Ge0rGjonasw: something like "trust my server to properly handle MUCs and contacts, and not to lie to me about users' JIDs"
Ge0rGjonasw: otherwise we are deep into sign-MUC-invitations-and-participant-lists-with-OMEMO land
jonaswyes, 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"
Ge0rGjonasw: good point. Then we really need to sign every presence and message.
jonaswindeed
jonaswor use peer-to-peer MUCs :-)
jonasw(although that still needs E2E)
nicolas.veritehas left
Ge0rGjonasw: the only secure way to make trusted identities is to route-to-publickeys, like Tor and similar.
jonaswyeah, I do not see that happen with XMPP
Tobiasyou can perfectly use XMPP with onion domains
sonnyhas left
Ge0rGTobias: that's completely orthogonal.
Ge0rGTobias: unless you want each user to run their own .onion xmpp server.
Tobiasright
jonaswwhy not! that also gives us client-chosen identifiers in JIDs! :>
Ge0rGjonasw: was it jonasw@6HbHXvQ00HcXJMWYlC5lpeU5.onion or jonasw@hC19YDLyWPC6jAFVQDlH78Lf.onion again?
jonaswdistributed name services!
jonaswalso, you would know, because your client lets you choose by public key (including meta information), not by .onion address
Ge0rGZooko called, and he wants his triangle back.
Ge0rGjonasw: so I'd choose by "6HbHXvQ00HcXJMWYlC5lpeU5" vs "hC19YDLyWPC6jAFVQDlH78Lf"?
jonaswno, the key with title "Jonas Wielicki" you signed when we met at CLT 2017 ;-)
Ge0rGmeta information can be faked.
Ge0rGjonasw: but we never met at CLT 2017.
jonaswnow that’s tricky
jonasw;-)
Tobiasif we get the lookup/bootstrapping problem solved it doesn't matter how cryptic the JID looks :)
Ge0rGexchanging xmpp addresses is hard enough already without routing-by-publickey
Ge0rGTobias: are we putting a pubkey-routed overlay network on top of xmpp now?
TobiasI'm certainly not
Tobiasput you probably could do serverless XMPP via DHT discovered endpoints :)
Tobiaseverything is supposed to be serverless nowadays anyways ;)
Ge0rGTobias: right. or serverless xmpp on .onion domains, to reuse existing tech
jonaswi wanted to implement serverless for fun anyways
Tobiasstill have the bootstrapping/contact lookup problem though
Ge0rGTobias: QR codes printed with your blood onto calfskin.
Ge0rGthe blood provides a strong binding to your identity, via DNA
Ge0rGmaybe there is even some way to cryptographically hash your DNA info to make a truly-personal keypair.
TobiasGe0rG, people get cloned, then what?
Ge0rGTobias: only a large government service is able to clone people. This attack vector can be safely ignored for normal people.
Tobiasthey cloned dolly in the 90s, didn't they..must be dead cheap by now
Ge0rGTobias: I hope you didn't intend to make that a tasteless pun. :D
Tobiasat 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
Tobiasnyco, https://mongoose-os.com/ is not related to mongoose XMPP server, is it?
XSF Discussion - 2017-03-06