XSF Discussion - 2019-06-26

cc

fippo: now I realize who you are. nice to meet you! :-D

not very active anymore but hey, small world :-)

fippo, you write that "Now transport-replace is difficult... XEP-0260 uses this in odd ways to fallback from s5b to ibb.", But when I look at the sequence diagram in xep260 § 3. I don't see any oddities, seems perfectly reasonable to use transport-replace(IBB) for the IBB fallback. I would expect that this can also be applied to fallback from ICE (xep371) to IBB, or am I wrong?

is xmpp.net melting down currently?

jonas’: can you kick it gently?

I don’t have any power there

Ge0rG: Melting?

Zash: I'm running into a 504 Gateway Time-out

...when submitting 404.city s2s

which my prosody also fails to connect to, apparently due to "connection closed"

flow: 0260 does a "try, determine failure, fallback" approach. ICE does the equivalent (even though not falling back to ibb) in parallel, potentially using a inferior transport (i.e. a relay) for some time. results in a better ux

works for me

Zash: ah, it closes after/during TLS handshake

hm. works from my desktop PC

Is that ejabberds way of telling you it doesn't like your cert?

works with openssl s_client. doesn't work from prosody

https://xmpp.net/result.php?domain=404.city&type=server

this is taking very long to load

and also runs into the 504

fippo: as @zinid said s5b has to be forgotten in favor of TURN/ICE

rion, why?

rion: well, ICE doesn't offer any ibb-fallback. Even though I would still be scared of any attempt to run a videochat over ibb :)

Zash: it's mainstream now

And isn't it already forgotten in favor of HTTP upload?

S5b meaning si file transfer or the jingle mechanism?

Jingle allows to fallback from ice to ibb theoretically or to http or vice verca

I don't see anything wrong with the jingle mechanism

zash: never declare a protocol obsolete, dead or forgotten. because what happens then is that people start using it

Daniel: jingle is more or less fine but its s5b is not

fippo so dead == ready for enterprise deployment? 🙂

rion: what's wrong with s5b?

Daniel: read my remarks on wiki

Link?

https://wiki.xmpp.org/web/XEP-Remarks/XEP-0260:_Jingle_SOCKS5_Bytestreams_Transport_Method

fippo: > ICE doesn't offer any ibb-fallback Do you mean ICE xep? I see transport-replace as more general purpose approach then transport specific. Currently in Psi I added kind of transport features. like if it's slow and/or reliable etc. And an application declares which features are compatible or preferable with it (still work in progress though). So jingle core mechanism can build kind of transports priority list from just compatible transports and do replace properly.

IBB will never be selected for the RTP application :)

rion: more correctly, ice doesn't specify a candidate format for xmpp ibb. only udp and tcp transports

fippo: in theory ibb allows to open substreams. so it can have one for RTP and one for RTCP. candidates are not needed.

Daniel, TURN sould be used instead of (peseudo) socks5 proxies, no matter if legacy XMPP stream initiation, or jingle

fippo, but from an XMPP jingle point-of-view, the jingle ICE transport chould be replaced with an IBB transport, no?

fippo, Maybe I understand your statement wrong, so there is nothing odd with how xep260 specifies the fallback from S5B to IBB?

(context for those who wonder: https://github.com/xsf/xeps/pull/793#issuecomment-505792574)

flow: i don't think this kind of scenario has seen much practical use otherwise the questions rion asked would have been asked earlier

fippo, is that really so? If we consider a world with S5B replaced with TURN, and legacy SI replaced with Jingle, why not keep the door open for IBB fallback as last resort?

I think the questions did not come up earlier because rion can be considered an early-adopter, at least of the FOSS community

flow: it ends up being a question of maintenance cost. ibb fallback is cool but do you need to implement it to be compliant?

I think IBB for any kind of media transfer, real-time or not, results in unwanted pressure on servers' routing and interference with 'regular' stanzas. This starts hurting quickly with increasing numbers of users.

also IBB wreaks havoc with rate limiting mechanisms (i.e. jabberds karma)

So although it might work, I'd explicitly strongly recommend against it.

fippo, Isn't a transport-replace(IBB) replacing a previous ICE tranpsort compliant?

flow: it is. but do we have a spec saying "try transports in this order"?

fippo, do we need one?

flow: how do you know whether ice is better than raw-udp or ibb?

From XEP-0176: * In Jingle, lists of "preferred" candidates are typically sent in the Jingle session-initiate and session-accept messages, in a way that is consistent with the SDP offer / answer model described in RFC 3264 [5] and the process described in ICE-CORE. * Candidates can also be sent in separate transport-info messages either before sending the session-accept message (to expedite negotiation) or after media begins to flow (to find modify existing candidates, find superior candidates, or adjust to changing network conditions).

btw fallback from S5B to IBB works perfectly in Psi. but it would be nice to have some recommendation in XEP. like if your file is bigger than 100kb please avoid the fallback to IBB. Or maybe even checking props via server disco about current speed limits, stanzas burst mode etc.

I also would like the ability for a server to (ahem) "discourage" this beyond a certain size.

fippo, I may be mistaken, but ICE would potentially include TURN as far as I can tell. So it appears to be the natural higher priority transport mechanism with IBB as fallback

ralphm, I am not sure if xep176 is really important here, given that it xep371 is expected to supersede xep176

flow: but ibb is not part of ice (which has its internal rules/priorities) but a different transport

fippo, I know, that's why I talking abut transport-replace(IBB), replacing the XMPP Jingle ICE transport with the XMPP Jingle IBB transport

Well, hah, so far nobody's cared enough for XEP-0371 to move forward, but yes. I also don't think it changes the idea behind the quoted text.

flow: and we certainly agree that ice is better than ibb. but i don't see a spec for that

And indeed I'd put IBB at priority 0, but the problem I see is that a server doesn't have an easy way to not want to support it.

ralphm: it can provide a terrible experience to any user that uses it? :-)

How complicated is ICE to implement for an XMPP server?

STUN would be a good start

fippo: as well as all other users

TURN STUN ICE so many acronyms!!!

Zash: do you mean integrate with any existing turn server?

ralphm: I assume servers do provide rate limiting :-)

Zash: you can use an existing TURN/STUN server. Like coturn.

it's matter of providing proper authentication to turn. that's it

And now you doubled the complexity of the installation procedure.

And then look at implementing Jingle Nodes

zash: in general you don't want that. IM servers have completly different deployment patterns (200ms latency due to centralization for the whole world) is ok but for turn servers you want them in many datacenters around the world

fippo can tell a lot about turn auth :)

Auth stuff already exists afaik

So indeed, don't reimplement a TURN server, but provide an easy way to use them (Jingle Nodes).

Zash: yes. xmpp servers should tell turn server about auth keys.

zash: prosody even has a module for xep-0215 :-)

I'm literally writing a blog post on how we did this at VEON.

ralphm: waiting for a link :)

rion: noted

fippo: Me, with my single user self-hosting in my basement, now need to deploy things to multiple data centers?

What, no.

zash: send 1$ to twilio each month instead

At VEON we had one in Russia and one for the rest of the world. As you scale up, you geographically (network wise) add more.

Just run coturn next to prosody, and you'll be fine.

Is that going to work if it runs behind a NAT?

if you know your external ip that can be configured

Also note that you don't provide TURN for others, it is for your (users) benefit. Your contacts should use their own.

Zash: you need to be able to reach it, of course (single port), and for relaying you do need to open up additional ports so that your peer can connect to it.

(typically a range of UDP ports)

So, say you run this at home, you'd have your NAT pass on the traffic for that port range (udp, and 3478, udp and tcp).

Is there any XEP like Last Message Correction but to delete a message including mam?

There's a proto-xep in the inbox I think

Inbox isn't rendered?

rion https://github.com/xsf/xeps/blob/master/inbox/message-retraction.xml

thx.

huh added almost 2 years ago. what's wrong with it?

well Barbra Streisand tried it in 2003 and it didn't work out very well

Check standards archives and council logs from around that time?

Hm, was those logs lost in the crash?

I see there is no notifications to other resources or muc participants about the retraction. So it's kind of incomplete

It should work the same as LMC?

ah other resources will be notified with carbons.

honestly I don't like the LMC idea. I'd prefer for changes to a message to be in place instead of a patch as it's for LMC.

moparisthebest, :-)

rion, what do you want to do exactly?

rion: It's not a patch, or do you mean that the old message is still in MAM for everyone? You know you can't really delete anything in an open system?

And that's probably why the retraction xep was not accepted.

You can't un-say something. Can't reverse time.

Does reversing time also reverse your actions?

Just imagine I'm writing to my mistress something quite private and after sending a message I discover it's was a chat dialog with my wife! Fine, I can delete/correct the message. But fu** she can see the previous message from MAM. what??

Can't prevent clients from keeping the "deleted" message and sticking a blinking red border around it

rion, maybe she wouldn't be able to. Her client would

Same as if you say something to their face

Can't un-say something.

Stop trying to break the laws of physics and causality

would be better if I could :)

You can't

Deal with it

nooo!

Not in an open system.

Even then.. people take pictures of pictures nowadays..

Zash: and yes I have to be honest with my wife..

good

Or you can claim plausible deniability

Claim temporary insanity

So it looks, to me, that message-deletion was almost accepted, but had its name changed as a result of council feedback - but I can't see it actually getting rejected.

Somebody not following up?

It was four years ago, though. But I think the general feel back then was that as long as we called it "retraction" and not "deletion", it'd be OK.

pep., Very hard to tell. I suspect it fell through the inter-council gap.

There was also a thread about something similar a few months ago iirc

pep., If by a few months ago, you mean 2016...

I'm not sure, I think it was by one of the russian fellows

Trying to copy signal or telegram or something like that

There was no XEP proposed, just a discussion

Oh, yeah, Andrew Nenakhov mentioned it I think.

Even in Whatsapp, deleting a message at the remote party is a request, and if the remote app doesn't process it within (I think) 7 days, the request expires and the message stays.

How do you test TURN/STUN/STUFF/ICE?

Testing that connections work, or that candidates are generating?

There's https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ if you want to test candidate gathering is handing out the right things

Okay. It does something.

Yay?

What's the state of XEP-0215 (client) implementations?

I see there was a version bump to :2 at some point

lance removed it from talky I think (boo lance!) and it seems jitsi uses :1

Zash: were you trying to use it for discovering your TURN server?

ralphm: I'm wondering why I did this, what I can use it with.

Well, you might want to look at XEP-0278 (Jingle Nodes), which besides discovery also handles authentication and requesting a channel.

This is what we used in VEON, likely also because the author (Thiago) was one of the team members :-D

Talky will be getting 215 back soon. Have to finish writing patch for extdisco prosody mod first to generate service entries/credentials via an event instead of pulling from static config file

I went with https://modules.prosody.im/mod_turncredentials.html but it implements :1

Seems to magically Just Work tho

Daniel, is registration ID a local device ID?

its a device ID

im not sure what you mean by local

you generate it for the user on first use

zash: sadly i don't remember why we bumped the namespace even

:2 added support for server pushing updated services/credentials to clients that had requested them

where do you get the word registration ID from?

lib signal?

lovetox, I mean that we have a local device ID, which we generated ourself and remote device IDs, generated by other devices, which we discover via PEP.

yeah and libsignal has also something similar they call it registrationID

in my lib i just set it to None and ignore it

lovetox, that's what my question was. If "registration ID" is local "device ID" in terms of libsignal-protocol.

but maybe you can use that, if i look through the code its actually just a value stored in libsignals objects

i dont see it doing somewhere something specific

lovetox, I need to specify it when calling session_pre_key_bundle_create() to create a pre key bundle.

yes pass the device id there

lovetox, ok, thanx.

Well

What should be wrapped in <key/> elements? Serialized ciphertext_message?

yes

And then I must deserialize it with signal_message_deserialize?

maybe, in my python port of the lib this call loos like this PreKeyWhisperMessage(serialized=message)

but yes you obviously have to deserialize it somehow

So, session_cipher is the only thing, which describes a session.

And I must use the only session_cipher for both encoding outgoing and decoding incoming messages?

yes

and as you before asked key element wraps the ciphertext serialized

but of course you should not forget about base64 encoding it first

signallib does not do this for you

Lance: oh, right. But clients should already know when to update, cause of expiry. Is this for premature expiry, like a turn server restart?

:2 added expiration attribute too. It was for server restarts and forcing move to new instance, yes

https://cerdale.zash.se/upload/ylN-_jalmw_Dvpuh/xep-0215-diff.html

Gah, things detecting that stdout isn't a terminal and disabling color :(

https://cerdale.zash.se/upload/YxG91XYKo9S47ZSd/xep-0215-diff.html Now then?