XSF Discussion - 2020-03-24

07:10:43 pollo> TIL jitsi meet is mainly an XMPP frontend 07:11:01 pollo> I find it very amusing, since I felt XMPP was kinda dead

am I seeing this correctly that we don’t actually have a spec for multi-user A/V calls?

if so: does anyone have contacts to the Jitsi Meet folks so that we can get them to spec their stuff?

jonas’, Jitsi people wrote CoLiBri, which is what Jitsi Meet is using, AFAIK.

Link Mauve, where is that?

In some XEP I don’t remember the number.

ah!

340

It describes jicofo.

As well as COIN.

that’s it, yes

thanks

Another XEP.

https://xmpp.org/extensions/xep-0340.html

https://xmpp.org/extensions/xep-0298.html

Those.

thanks

I don’t know how different the implementation is nowadays, though.

It may have significantly diverged, or not.

I believe it has diverged a lot and there was not much interest in fixing that

that is my understanding too

Is muc 333 supposed to be alone in an unsubscribe message?

https://xmpp.org/extensions/xep-0045.html#service-error-kick

I have somehow the feeling that this was the intention, to keep backwards compatiblity

but then I saw this: https://github.com/igniterealtime/Smack/pull/374

xep45 is not really clear on that (beside the examples showing 333 never alone)

jonas’, ^

s/unsubscribe/unavailable/ ?

flow, hmmmm?

flow, 333 is an additional code which specifies which type of kick it was, using it alone doesn’t make much sense IMO.

Agreed

Zash, correct

jonas’, but is it required to never appear allone?

IMHO, if so, xep45 should spell it out explicitly

I wouldn’t say it’s required

I would say currently there is no specified case where that happens

well allowing 333 standalone has backwards compatiblity issues

Zash, MattJ, since the bug report come from the jitsi folks, I'd assumed that it was potentially prosody producing those unavailable presence stanzas. Is this the case?

Ah, now I remember

this whole discussion

I'm confused, what's the bug on the Smack side?

Not treating unavailable presence as "client left the room"?

status codes are colour on top of that

yup, 333 without anything should be treated as "client left normally" by any entity not knowing 333

There was some discussion about whether 333-type leaves should be parts or kicks

The argument is that they are kicks because the user didn't request to leave

I totally aggree that status codes are additional metainformatino and that unvaialble presence means that a participant has left the room

I distinctly remember some client having a bug with multiple status codes

While the inverse argument is that it's not a moderation thing, and kicks are noisy

The question is about allowing 333 standalone in an unavailble presence

I think allowing 333 standalone causes backwards compatiblity issues and hence should not be allowed

What problems does it cause?

MattJ, basically smack assumes that if the unavailable presence contains any status codes, one of those codes it at least one that has been there from the very beginning of xep45

flow, I think that assumption is flawed

I think that's definitely a flawed assumption

status codes are a registry

jonas’, potentially, but I could imagine that other libs do the same

then other libs are also flawed

Well so far we haven't found any

Also this is why the status codes likely aim to follow the HTTP style of buckets

I am also not convinced that this assumption is really flawed

all the 3xx status codes are about an occupant leaving, afaik

I mean I see your point

This would have been done initially to make status codes extensible

Not that I see much point in this case

but adding additional causes that do not refine existing causes seems like a bad approach

flow, unless you can find a piece of text in XEP 0045 which says that on an unavailable presence, there must be no status code or one of these X status codes, your assumption is flawed

and in this case 333 seems to simply refine an existing cause ('kicked')

Actually no, in this stanza before Prosody added 333 there would have been no status codes

flow, a future status code could be refining the voluntary client leave, for example "leaving forever not going to come back"

So we went from nothing -> 333

the library still needs to be able to deal with that

333 was just additional colour for the leave

(iirc trunk nightly builds may have used a kick status code for a while, before 333 was introduced - but I don't think that was ever in a released version)

Either way, it should be explicitly spelled out in xep45 what clients to can expect

flow, I think it’s already pretty clear

there are some requirements about status codes which MUST be present

but there’s no wording on which are not going to be present

so you’ve got to deal with that

(just like there’s no wording on the order of status codes, you need to deal with any ordre)

I would at least suggest to add an example where 333 appears standalone

why?

there’s currently no defined use-case for that

then why does prosody do it?

https://issues.prosody.im/939#comment-14

MattJ, thanks for the link :)

(and discussion before/after)

fun

MattJ, make a PR against '45 then, because 45 clearly states that there MUST be 307 at this time

So I see, that's news to me

only in the GC1.0 case though wtf

https://xmpp.org/extensions/xep-0045.html#enter-gc

Basically the fallback behaviour we want (for UX reasons) is a normal leave, not a kick

weird

because kicks were making users "wtf"

here it’s not clearly spelt out: https://xmpp.org/extensions/xep-0045.html#service-error-kick

yep, users don't like to get kicked

so it can go either way

MattJ, I suggest someone makes a PR which states that and fixes the wording then.

jonas’, for clarification: states what?

flow, that https://xmpp.org/extensions/xep-0045.html#service-error-kick shouldn’t use 307 ✏

something something somebody suggested a specific error condition just for that

Ge0rG, what is it, that you want to tell us?

flow: IIRC jonas’ had interesting ideas for a new error condition that's neither kicked nor access denied, in the context of 0410

Ge0rG, irrelevant, because MUC leaves don’t have stanza errors

Also we abandoned that idea because nobody had time to pursuit it

so much for the military using XMPP https://www.theregister.co.uk/2020/03/18/army_adopts_whatsapp_orders_coronavirus

There's more than one army

and more than one branch of military

hi all, im trying to develop an messaging app with React-Native. I have Prosody server installed and i can send/recieve messages but cant complete in-band registration. i couldnt find a package for that. Does anyone know how to do it in RN environment? Thanks

mbt: are you using xmpp.js?

looks like it's a lonstanding wish... https://github.com/xmppjs/xmpp.js/issues/783

yes i use xmpp.js for connection and messaging, in those topics 'https://xmpp.org/extensions/xep-0389.html' is offered but i cant understand how can do these instructions

XEP-0389 is not really ready yet

https://xmpp.org/extensions/xep-0077.html is what you would use

okay thanks, i can send iq stanzas with xmpp.js. Then should i use 0077s iq examples?

If you can do that before you're fully connected, then I guess that'll work

okay then i will try this thank you very much Zash, Ge0rG

Just disovered Kontalk. Somebody knows if they federate?

last I looked they do yes

But you have to manually hash the phone number to talk to someone on kontalk. With Quicksy.im you can just write +12345...@quicksy.im #shamelessPlug

quicksy is ever so slightly easier to un-hash into a plain phone number though :)

JIDs like sha1(phone number)@beta.kontalk.net from what I could find on some wiki

But SHA1 is broken! ;)

yep, where phone number is +12223334455

https://www.moparisthebest.com/phonehash/ this doesn't work anymore because I no longer have 500gb to spare but it "unhashed" kontalk numbers instantly

500GB? I feel like you could get away with far less than that

Rainbow tables aren't known for being small

I guess

I guess you could cheat and only store the shortest prefix or something

Iirc it wasn't a rainbow table but just all hashes

Have I misunderstood what a rainbow table is?

I always wanted to make it a nice weekend project to learn how to build rainbow tables and actual have all possible numbers

Rainbow tables only store a subset of hashes

rainbow tables could maybe be smaller, but still are computationally expensive

500gb was all numbers, stored as 5 byte integers, sorted by hash, so I could binary search them and do at most like 5 sha1 operations to find any number instantly

ah, I knew it was something clever

all the technical details here https://github.com/moparisthebest/phonehash it's actually not clear to me if rainbow tables would actually be smaller or not

moparisthebest: why didn't you upload the 500GB to github? :D

I don't think it supports that haha, but the code to generate it is there

In Germany, phone numbers are 12 or sometimes even 13 digits.

yep, doesn't support any of that nonsense either :)

I guess it'd still fit in a 5 byte number but you'd need significantly more than 500gb to store them all, unless you just went for a subset

don't really feel like doing the math to figure out how much data that is right now :)

the fixed prefix is +49, leaving 10 or 11 useful digits

you'd have to cut the prefix off or go for six-byte indexes

ah ok that changes things, I'm storing 11 digits there, so you'd just do the same except prefix +49 instead of +

looks like there is something wrong with s2s with this new xmpp.org. I checked two Russian servers with quite old ejabberds. none of them allowed me to connect here.

How old is old?

3.2

and 2.1.13

oh. it's not s2s. I see myself in the web logs joining here

hm or s2s.. well muc sent me nothing back

but obviously received and handled my presence

So the connectivity problem is in the other direction

won't connect to TLS 1.0 or something?

ok jabber.ru admin say s2s is connected. there is something upper-level

I vaguely recall there being all sorts of s2s issues between prosody and ejabberd back in those dark ages

MattJ: poke? ↑

I don't have access to the new box

Uh, can get you access in a bit

No idea what would cause this

rion: Did this that work before the crash?

yep

All I can think of is some kind of network or DNS issue on the new box

hmm Dele also reported that his openfire (?) instances could no longer connect to xmpp.org

I was speculating TLS

No TLS 1.2?

I'd say 'try xmpp.net' but that's not up yet

Ah, it's Debian buster so it could indeed be TLS

Old software still attempting SSL 3?

Who doesn't do TLS1.3 yet? /s

If I'm guessing their domain correctly then that's not the problem. I get a Dialback error instead.

does s2s uses 2 connections between 2 particular servers?

sometimes

Usually at least 2, yes.

(most of the time actually)

Yes, for hysterical raisins

there’s s2s bidirectional mode, but it’s not too widely deployed

so usually 2 uno-directional

jabber.ru guys looking into the problem too.

[23:15:45] *** rion2 заходит как участник [23:15:46] *** rion2 удален из комнаты по техническим причинам that was me from jabber.ru

what looks like this here? 18:14:44 ---> rion joined the room 18:14:45 <--- rion has left the room due to an error (Kicked: remote server not found) 18:15:25 ---> rion joined the room 18:15:26 <--- rion has left the room due to an error (Kicked: remote server not found)

Oh, rion_2_?

yep

s2s with jabber.ru seems to work everywhere else I try

Psi writes: removed by technical reasons. I don't remember what's this in xml log

Pretty sure it's the 333 code discussed earlier

It's what Prosody uses if you send an error to the room, which is what it sees if the s2s connection in the other direction fails

rion, Zash: from the log: Mar 24 20:47:28 server_epoll debug TLS handshake error on FD 231 (172.104.234.182, 5269, 104.248.10.4, 33976): dh key too small

ah, yeah, jabber.ru

What was the result of the discussion around Inbox again at Summit. The "ordered list" of tabs doesn't seem mentioned in the minutes, I assume that's supposed to be something separate

took me awhile how to figure this out. I'm curious why p256 is 'short' though

If you get that message then it's not using ECDHE

That's plain old DHE

probably with 1024bit parameters

:~$ openssl s_client -connect jabber.ru:5269 -starttls xmpp-server 2>/dev/null | grep Temp Server Temp Key: ECDH, P-256, 256 bits

Or may be it's because it's not ephemeral though

not sure how to force that through s_client to check

~$ wrapsrv _xmpp-server._tcp.jabber.ru openssl s_client -connect %h:%p -starttls xmpp-server -cipher 'HIGH+kEDH:HIGH+kEECDH:HIGH:!PSK:!SRP:!3DES:!aNULL' this would be closer to what prosody 0.11 does

Server Temp Key: DH, 4096 bits

Odd. Recently changed?

i tend to answer 'no' in a most sarcastic way, usually. But I guess sarcasm is difficult to transfer through xmpp. So, yes, minutes ago

but what's curious is that DHE is used only when I try a longer EC curve

that's why I was asking about P256

openssl s_client -connect jabber.ru:5269 -starttls xmpp-server -curves secp384r1 this is a curve my openssl doesn't yet support so this results in using DH instead of ECDH

Oh no, I didn't want to be reminded of how OpenSSl handles curve

/sigh

but I have to change dh param default length due to this handling >_<

pep.: Jabber.org has this problem since several years ;)