XSF Discussion - 2017-03-06

Ge0rG: I think it is pretty clear how to send a message to a MUC.

jonasw: but there is no way to know that it arrived :P

indeed :-)

uh

we should try to smuggle a <feature var='muc_keeps_ids' /> in your PR

jonasw: I tried and failed, some two years ago. I think clients that care enough just need to embed a [xep 359] tag

ah clever

jonasw: I consider it a crude hack.

depends on the point of view regarding the id uniqueness per stream

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

will we get that with MIX?

(.oO(make all <message/>s <iq/>s!)

)

and instead we've got acks, stream management, carbons, mix, stable-message-ids, which all solve partially overlapping partial problems.

not sure that anything of acks, SM and Carbons is really overlapping.

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 :>

:D

jonasw: SM and acks both implement message reliability mechanisms, two faces of the same medal.

but on a different scope

jonasw: it's absolutely the same logic, just different endpoints.

yes

except one is a message attribute and the other is a nonza.

that’s what I mean by differetn scope

*message child element I hope

right.

and then we have the problem that carbons don't carbonate 0184 acks because those are "normal" messages.

carbons is a mess

I'm asking for multiple years now to replace carbons and "classic" bind with a MAM subscription mechanism.

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.

depending on the order of the above, you'll get crazy side effecs.

yeah, I got that from the bind2 xep

but bind2 still doesn't give us MAM subscription

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?

is MAM subscription a thing?

so we have two different mechanisms for offline and online sync now, with different message retention properties.

jonasw: I suppose your MIX proxy will figure out from the client's caps that it's not MIX enabled

well, no, the client *can* do MIX

but it hasn’t seen the account yet

jonasw: otherwise, you're f***ed.

jonasw: this is exactly why I'm complaining about MIX-in-roster

what does this have to do with MIX-in-roster?

jonasw: implicit join on connect.

I think that’s a feature

jonasw: until you get a message from a MIX.

yes well, I need to know that it’s a MIX

yes you do

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.

thanks, but that’s insane

jonasw: you could also just do a blocking query :P

that’s not better

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?

that could worl

*work

if the roster is actually going to be annotated, that could indeed work.

won’t work for mixes which are not in the roster thoguh

In the context of auto-generated UUID-JIDs for private MUCs/MIXes, there is an interesting question of how to prevent impersonation attacks.

Ge0rG: reject MIXes/MUCs with anonymous settings for that purpose?

and then look up the JIDs to make sure they match

uhm, I may not be so sure about your usecase anymore

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

if you assume that the service is evil, end-to-end is probably the only way out

jonasw: I assume that my own server is not evil, but an evil third-party server might exist.

still applies

jonasw: I think there is room for a security model somewhere between "trust everybody" and "trust nobody, run e2ee everywhere"

jonasw: something like "trust my server to properly handle MUCs and contacts, and not to lie to me about users' JIDs"

jonasw: otherwise we are deep into sign-MUC-invitations-and-participant-lists-with-OMEMO land

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"

jonasw: good point. Then we really need to sign every presence and message.

indeed

or use peer-to-peer MUCs :-)

(although that still needs E2E)

jonasw: the only secure way to make trusted identities is to route-to-publickeys, like Tor and similar.

yeah, I do not see that happen with XMPP

you can perfectly use XMPP with onion domains

Tobias: that's completely orthogonal.

Tobias: unless you want each user to run their own .onion xmpp server.

right

why not! that also gives us client-chosen identifiers in JIDs! :>

jonasw: was it jonasw@6HbHXvQ00HcXJMWYlC5lpeU5.onion or jonasw@hC19YDLyWPC6jAFVQDlH78Lf.onion again?

distributed name services!

also, you would know, because your client lets you choose by public key (including meta information), not by .onion address

Zooko called, and he wants his triangle back.

jonasw: so I'd choose by "6HbHXvQ00HcXJMWYlC5lpeU5" vs "hC19YDLyWPC6jAFVQDlH78Lf"?

no, the key with title "Jonas Wielicki" you signed when we met at CLT 2017 ;-)

meta information can be faked.

jonasw: but we never met at CLT 2017.

now that’s tricky

;-)

if we get the lookup/bootstrapping problem solved it doesn't matter how cryptic the JID looks :)

exchanging xmpp addresses is hard enough already without routing-by-publickey

Tobias: are we putting a pubkey-routed overlay network on top of xmpp now?

I'm certainly not

put you probably could do serverless XMPP via DHT discovered endpoints :)

everything is supposed to be serverless nowadays anyways ;)

Tobias: right. or serverless xmpp on .onion domains, to reuse existing tech

i wanted to implement serverless for fun anyways

still have the bootstrapping/contact lookup problem though

Tobias: QR codes printed with your blood onto calfskin.

the blood provides a strong binding to your identity, via DNA

maybe there is even some way to cryptographically hash your DNA info to make a truly-personal keypair.

Ge0rG, people get cloned, then what?

Tobias: only a large government service is able to clone people. This attack vector can be safely ignored for normal people.

they cloned dolly in the 90s, didn't they..must be dead cheap by now

Tobias: I hope you didn't intend to make that a tasteless pun. :D

at first not, but now that i reread that message :)

:D

nyco, https://mongoose-os.com/ is not related to mongoose XMPP server, is it?

Nope ;-)