XSF Discussion - 2019-07-18

I'm planning to provide some improvements to SIMS xep. And I think this recent unique MUC occupant id xep would be useful here. Is it going to be published any soon?

rion, I expect it to be accepted

but that’s just me ;)

still lacks two council votes because the respective members weren’t available for the meeting yesterday

which means it’ll probably be dealt with next wednesday

What kind of improvements?

The biggest issue I have with the occupant-id thing is that IT'S NOT ANONYMOUS!

Anonymity is in the eye of the beholder?

it's effectively adding a pseudonym for each bare JID in a MUC.

I'm not saying it's bad or wrong, just that the name doesn't fit.

my sarcasmometer isn’t sure about what you’re saying ✏

Ah, right.

Ge0rG, you didn’t mention that yesterday

but then again, MUC is pseudonymous in itself, it won’t get better than that?

It would be better if that were more explicit.

jonas’: it's a different kind of pseudonymous

Anonymity for occupants v.s. admins, right?

one could hash (muc-jid, nickname, bare-user-jid) together to allow nick changes to become identity changes.

jonas’: I didn't mention it because it was not critical for what the XEP is supposed to do

Ge0rG, I think one of the goals is not to include nick in there ✏

But yeah that could be made explicit

I still think that making it a proxy-JID on top of the MUC service domain would be a Good Thing™, and then just stuff it into messages and presence.

Ge0rG, ITYM making MIX?

This

Ge0rG, I also have something like that in mind

But it's not incompatible

are you going to re-invent MIX in worse on top MUC?

I think doing MIX is a much better use of time than attempting to bolt things onto MUC even further.

worse? Last time I checked proxy-JID wasn't particularly pretty in MIX, trying to fit 4 things into 3 (is that the one?) ✏

pep.: yeah, it's the one

pep., you’ll end up in the same situation with MUC, plus the additional issues from the different participant model

Of course a MIX service could still expose a MUC interface/facade.

ralphm: I'm fighting hard to keep that a thing, yes.

I agree that proxy-JID is one of the uglier things of MIX.

pep., the protoxep wants the occupant-id to be stable across rejoins. putting it on the domain then requires to make it reversible (so a simple HMAC won’t do, you eithre need to encrypt it symmetrically (not feasible) or store the mapping (ew))

now that I think about it. Advertising those proxy JIDs inside of MUC will add a bunch of problems indeed, like clients trying to PM those JIDs

it was a dumb idea, nevermind.

Ge0rG, excellent, problem solved ;)

Yay

I just hate UUIDs for their uglyness.

jonas’, putting what on the domain

Where are there UUIDs?

Is that a remake of yesterday's discussion in programming@

I suggest HMAC(server_secret, muc-JID + user-bare-JID)

Zash: "UUID" is a placeholder for "long, random-looking hexadecimal string"

Also, who cares. It is not something the user should ever see.

Ge0rG, HMAC(real_bare_jid, room_secret) is what I use in the module atm

Someone should use emoji for hex digits

pep.: that requires persisting the room_secret, whereas with a server_secret + room-JID you reduce the storage reqs

jonas’, see I said somebody would care about that :P

ralphm: did you just say "usability nightmare"?

I just didn't know how to do that with prosody's API, but I don't really mind :)

Ge0rG room destruction and recreation would produce the same IDs then, which seems undesirable

^ this ✏

Zash: is it really?

okay, you could also rotate the room_secret on jid visibility changes.

(as if anybody would do those in practice)

what does that mean

Ge0rG, I prefer a room secret managed by the server, because it fixes destroy/re-create use cases

Ge0rG, plus it avoids having to have the secret configurable / have a server/domain-wide secret which needs to be managed somehow

jonas’: what's the threat model in those cases?

I create a MUC, invite everybody there, store the occupant-id mappings, close down the MUC and let somebody else recreate it?

Ge0rG, take a destroyed room, re-create it becoming owner, make it full-anon to lure folks back in (clients could warn if it isn’t anon/anon-mode changed between joins), note occupant-IDs, revert to non-anon ✏

full-anon has been removed, hasn't it?

Ge0rG, I call "occupant-id anon" "full anon"

when we assume the path towards where the owner cannot see the real JID anymore, instead operating on the occupant-id

jonas’: your naming convention needs more thought

Ge0rG, sorry

I might have mentioned it before, but none of this is actually anon.

yes

full-pseudonymous then ;)

That's also something I'd like to see, using occupant-id instead of real-jids to do MUC operations (even for owners)

Ge0rG, admittedly, I’m a bit thinking ahead here, but I think it’s valuable to do that

pep.: we can hardly manage affiliation management in our clients with the existing protocol.

Fix your client?

jonas’: what's the additional attack surface compared to "make a full-pseudo room full of people non-anon"

Ge0rG, you need to be owner to do that

jonas’: yes, like in your proposed scenario

tbh if we were to start using occupant-id for more things, I'd prefer that to be a component setting and not a room setting that the owner can change

pep.: what to be a component setting?

The problem I see in SIMS is jingle transfer with references like this <reference xmlns='urn:xmpp:reference:0' type='data' uri='xmpp:romeo@montague.lit/resource?jingle-ft' /> While they look quite simple to handle this "resource" part makes it very temporary. While it can be intended to have a temporary share it doesn't look quite reliable anyway. So a client to download a file should try all possible resources and expect the jingle session will be rejected immediately if the resource doesn't have this file. I'm not sure how it can't be enhanced, but probably there is a way (likely something with carbons). As far as I understand Jingle session publishing suffers from the same problem. We have to send <start> request to specific resource, but which one?

And with MUCs things are even more complicated.

Ge0rG, "use occupant-id for things", as said above (using it for MUC operations instead of real-jids)

pep.: so you want to be able to enforce occupant-id-stamping on all MUCs of your service?

> pep. 10:42 That's also something I'd like to see, using occupant-id instead of real-jids to do MUC operations (even for owners) That would be broken, wouldn't it? You would need someone to join the room first before you could ever ban them.

And you wouldn't be able to ban other than single users.

what if someone is set on harassing a muc

and start creating a whole bunch of free accounts on a host

tom: they'll just register new accounts via IBR

...on different hosts

and you can't preactively ban

there's that script that will register thousands of IBR accounts on hundreds of servers for you.

how can we metigate that?

we can hope that the abusers won't find out

so is this like an open resolvers on the internet type situation?

More or less, yes.

oh no.

nevermind

Kev, you can use mod_firewall for that. Or you can ask the server operator.

(well in both cases it's up to the server operator)

I'm not saying banning a real-jid wouldn't be possible anymore, I just don't feel the need to expose them

I don't understand the motivation, though. Suggesting mod_firewall, or other things the server operator needs to do, seems to be moving away from a functional standard mechanism, and that's kinda what we do.

handling spam is not really well spec'd tbh

And I don't think it's ever possible to do

I don't think banning people is necessarily about spam.

And this feature wouldn't go away ✏

we have blocking, but it doesn't work for MUCs

Technical solutions to social problems?

So much this

Unless you get really radical, technology usually doesn't solve social problems. Merely mitigates, or permanently removes the opponent from the equation. The latter is where Geneva is often mentioned.

Let's give up and farm potatoes.

You've never been in the Netherlands?

ralphm: It'd be interesting to have a way to accomplish that... over the Internet.

OTOH, there are underground groups with pre-made lists-of-opponents-to-be-removed, so I'm less prepared than they are, and their lists have all the wrong people on them.

And without being able to properly execute, I shouldn't utter this kind of wish.

...

Is there an xmpp logo in svg somewhere?

Ah on the main page

Board meeting -10 min

o/

time+1

where's the gavel?

0. Welcome

Who do we have?

Hey

bonjour

Hi!

I'm on a very unreliable network

:-D

1. Minute taker

I might drop at any time, for any period

if nobody wants it, I'll do it

2. Badges

Poll results yet?

not sent yet, was waiting for more feedback: are we ok to go?

https://forms.gle/nY76DLaD6Ttyn8AV9 latest iteration, DO NOT VOTE YET

I think so

if no red light today, I'll send it to members@ after I send the minutes

sgtm

But I'm a bit confused. You didn't really add more questions per dwd's suggestion?

yes, I did, second page

Oh!

first page is the choice + comment

Yes, I see it now

Looks good to me

LGTM2.

ok, thx all

Nice!

Thanks, nyco!

So disappointed it's "badges" and not "badgers" though.

:-D

3. Messenger Regulation

I'm sure it's holiday season, so nothing to report here?

Ge0rG

ralphm: I still haven't written that promised mail to members@

the contact person was very much interested in e2ee btw.

also promised to come back to me in the timeframe of two months, which isn't over yet.

our task of determining what exactly we expect is still open

or rather what we want

I think the first goal is give them the executive summary of what XMPP is

maybe one of the XSF sposors would stand up to sponsor some heavy lobbying? ;)

ralphm: that I did.

ralphm: we have been listed as one of the stakeholders in the process.

Good

so what is our desired outcome? put XMPP into law? put "standardized protocol" into law?

well what other protocol qualifies?

no one sane recommands SIP/SIMPLE

Matrix is in its infancy

nyco: matrix has been accelerating their standardization efforts

nyco: the only difference between matrix and xmpp, for an outside observer, is some rfc numbers

Telegram protocol is quite not open nor standard, although openly documented, only one server implem

The thing I find most important in general was summarized perfectly by Google (https://developers.google.com/talk/open_communications): Freedom of Client, Service, Platform.

ralphm: from when is that? 2004?

Matrix has only one server implem, thus does not qualify as an open standard

Ge0rG: slightly later

nyco: I think you are mixing up things there.

Ge0rG: But it is indeed timeless

to be honest, we can push open standards protocols, but only one qualifies

nyco: this is a classic approach, to make the requirements appear generic but be sufficiently specific so that only your proposal matches.

still, Microsoft Open Office XML is the mandatory reference here.

athough I am biaised, you gotta be honest: what other protocol qualifies? none

I'm sure that if pushed by legal regulations, Facebook, Google and the others will all come up with their own "open" "standard"

...overnight

Note: have to leave exactly at 16:00

nyco, personally I wouldn't want to put a protocol name in the legislation

pep. this, I agree

Ge0rG: indeed, the things we have going for us: standardized at IETF, many implementation, not a single entity in control

I think we can all agree on that

ss

Ge0rG, that will happen and I don't think there's anything you can do about this

pep.: it's possible to make law that leaves the specific protocols open for a later decree.

the RGI name protocols (Référentiel Général d'Interopérabilité) in France

pep.: we might have to create wording that, in the presence of malicious actors, can't be gamed too much

Even if you'd mandate 'XMPP', what does that mean?

RFC3920!

we must then clearly define what an open standard is, and then different actors will push their agendas

I think what you'd want is interop in features, retaining the freedoms I (Google) listed.

https://en.wikipedia.org/wiki/Open_standard

Exactly what Google deployed in 2006, no more, no less

This will be fluid over time.

Zash: with various notes, to be honest

so how do we move forward now?

(time -5 min for me to leave)

Does it make sense to try to push what I wrote above, and showing how XMPP would get us there?

we also should prepare an answer for E2EE over bridges.

I think so

Ge0rG, "it doesn't work"? :/

FWIW, full interop is never going to happen. There will always be features only certain implementations support. Establishing a baseline is not easy, but maybe our compliance suites could be a guide.

The best example of E2EE over bridges we have is OTR..

which reminds me of things I need to put onto next Council's agenda.

pep.: OTR is also the worst example.

Ge0rG: bridges between XMPP and other networks (e.g. Matrix)?

Ge0rG, agreed

and IRC

ralphm: if you mandate open access to facebook, whatsapp etc over xmpp, it will be some kind of bridge as well

on their side

even if the bridging part is hidden from us

I'd also note that although both XMPP and Matrix have federation features, making it a single federation is hard.

gotta go, sorry, I'm off

nyco: thanks@

do we want to mandate OMEMO in all IM clients? Or rather wait for / influence MLS?

Ge0rG: well, I assume that Facebook, WhatsApp would expose their services as an XMPP server.

I.e. the interop would be XMPP s2s

ralphm: this is not an answer to E2EE

Indeed, you'd need to agreed on protocol agnostic E2EE. I don't know if that's possible.

ralphm: either that, or all providers need to implement a protocol-specific E2EE algo in all their clients

which is not impossible, if properly agreed upon by all parties

Why couldn't you specify an E2EE mechanism like how SASL is defined?

ralphm: please explain

I.e. you can do SASL over IMAP, XMPP, and others.

The interactions are defined, the wire protocol framing is a specialization

Where things get hard is encrypting more than just text.

If whatever you encrypt needs to be distributedly extensible, you need to agree to, basically, XMPP stanzas.

I think we can continue this discussion, but I'd also close the formal part of this meeting.

5. Date of Next

+1W

6. Close.

KTXBYE

Thanks!

Thank you :)

Ge0rG: is it clear what I meant?

ralphm: yes, thanks.

I suppose you could also define a JSON format that can then be encrypted, but if you want distributed extensibility, you need namespaces, etc., and you are basically replacing angle brackets with curly ones.

I wonder if OMEMO isn't already 90% there

I think DE is also a selling point to reluctant corps

I love this WiFi. Good meeting! Ttyl

Ge0rG, but not really appealing. I'm not sure I want to get stuck with only encrypted body in the legislation

if only somebody had told the XEP authors.

And if you want more, as ralphm says, you have to have the same transport on the other side basically

Ge0rG, well OMEMO or not that's what you're saying, and that's effectively the only thing that can go over bridges (body-only)

Guus: :-/

pep.: OMEMO is what's there in XMPP land. There is also MLS of which I have no clue.

pep.: same transport (XMPP s2s) would be ideal. For E2EE you need a common format to encrypt.

pep.: and I'm sure we can easily embed XML or JSON or whatever inside OMEMO payloads

Ge0rG, and then you'd need clients to put encrypted json in body? :(

pep.: and if you want Distributed Extensibility within that encrypted payload, then you might as well mandate XML Stanzas

pep.: into the new OMEMO element.

ralphm: at which point we arrive at Stanza Encryption

Ge0rG, I'm not sure I follow

You're not talking about stanza encryption yet?

no idea what we are talking about

We were talking about how E2EE might work across networks.

E.g. Facebook, WhatsApp, 'normal' XMPP clients

And I tried to list requisites, given that I assume both we and Facebook would want to be able to encrypt more than just plain text.

I'm not sure how much the second part of that assumption holds.

At least we do, I'm not sure about Facebook

But that'S something to consider

Well, have you seen Facebook Templated messages?

no, what are they?

pep.: https://developers.facebook.com/docs/messenger-platform/send-messages/templates/

Or using another example: Slack, which has a lot of rich stuff in messages.

Buttons?

Zash: Buttons++

If I was a company working on this, and I wanted to offer E2EE, I'd definitely want/need to include this

now we are speaking of a baseline feature set

this will be hard to agree upon.

Right. "What do we want to have in the legislation"

because facebook needs templates, instagram needs galleries and whatsoever.

(also caroussels, maps, link cards (url, picture, title, description), flight infor)

Nobody said open standards were easy

Ge0rG: that's why I mentioned distributed extensibility. If each vendor has the ability to add their own stuff, you are not limiting a feature set.

Of course whether other clients can interpret all the things is another matter.

ralphm: I think you just invented the XSF

But you'd definitely need to have a baseline (probably plain text)

Not even the XSF needs to be a single controlling entity.

At VEON, we clearly defined all rich messaging in a way that it could have a fallback body with plain text.

I wish XEP authors would consider that.

Aren't you on the Council?

Each rich messaging XEP should: - mandate a legacy body format - mandate that the body MUST NOT contain anything else, so that compliant clients can ignore it

Make it one of your review checkboxes.

ralphm: you'd be surprised, it already is

I'd hoped so. It was definitely on mine.

unfortunately I'm not aware of any XEP that follows this simple pattern

not even EME

> When a message is marked with an encryption tag and can not be decrypted, the body can safely be ignored and a localized message displayed instead. This is close, but not quite there.

No?

XHTML-IM?

References, and thus SIMS, also assume this.

So when are we un-deprecating XHTML-IM again?

No, I'm saying that the way it was designed, it assumes that if you don't support it, you can still use the body.

Without loss of information ideally.

Also, XEP-0060, section 12.7 (and other places).

ralphm: indeed, XHTML-IM is explicit in that regard. I'm not sure I would count References as it's only an annotation to <body>, not a replacement.

Sure, but the idea here is entirely that the common format is plain text, and that richer stuff points to it.

(sure, you can also use References with actually referencing begin/end, but that'd mean you lose information)

without

I'm looking at XEPs that contain a fallback <body> for non-supporting clients, and that should mandate that the <body> will be superseded

OOB as currently used is the best anti-pattern example to that.

the new reactions proto-proto-XEP fails miserably as well

and then there are things like MUC invitations (direct or mediated)

I haven't read that yet, but reactions should be annotations. A body might be tricky. I'm not sure how to refer to a previous message in plain text in a way that a user could understand.

ralphm: https://github.com/jabbercat/jabbercat/issues/80#issue-304305375

In case a body cannot convey a certain extension, maybe it could say something to that effect.

I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo

'You are invited to a chat room, but your client doesn't support this mechanism. [link-to-faq-page].

See, literally the same thing.

(oh, and a closing ')

ralphm: technically, an OMEMO client could insert actual text into the <body> of an OMEMO message, and it would remain unnoticed by OMEMO clients.

https://xmpp.org/extensions/xep-0384.html doesn't mandate that the <body> must be throw-away content

> If the decryption fails, the client MUST silently discard the OMEMO message. If it succeeds, the decrypted contents are treated as the <body> of the received message.

Given that it is not Final, there's some room still :-D

So I could troll OMEMO-enabled clients by adding a broken <encrypted xmlns='eu.siacs.conversations.axolotl'> element into all my messages.

There are so many ways to troll clients. Again, social problems.

ralphm: I'm pretty sure that XEP won't move forward in the current state ;)

when designing the receiving side of things, I need to make a deliberate decision on throwing away the <body>

I suppose I'm way too deep in nitpicking mode.

:-)

:-)

minutes sent

poll sent

can I vote now? :D

MattJ: hats ping

Ge0rG only once! :)

only once per split identity.

ah, this...

if these people are many contributors, then yes

nyco: you forgot to add the "would you use it?" to the poll.

second page

2) If you run an XMPP project, would you use those badges? (website, repo, doc, flyer, poster, etc.)

👍

jonas’: > The initiating party MUST NOT perform A/AAAA fallback as per &rfc6120; (since the service provider has already indicated that the SRV protocol is supported).

eh, I know what 6120 says but I can't agree with that here

it's trivial for an evil attacker to insert a DNS record that tells a client/server not to fallback

I see no harm in falling back anyway if you are doing TLS, does anyone?

(sorry for ENOCONTEXT referencing https://github.com/xsf/xeps/pull/796/files )

the other bit, trying regular _xmpp-client/_xmpp-server seems fine though

about improving SIMS... I believe Jingle Session Publishing xep should take some features from Jingle Message Initiation then it will fit well to SIMS. Like.. 1. I'm sending SIMS with published Jingle session 2. a party discovers details of the published Jingle session and if it's compatible sends a *message* (not iq) with <start> 3. the message is carbonned and my other resources not having the file from SIMS just ignore the message (or maybe just record it happened) 4. my resource which has the file sends <starting> via message to a party resource so other my resources know I'm sending a file and also know where from 5. a party initiates jingle session with file request to specific resource (where <starting> came from)

moparisthebest: I wrote this elsewhere before, but I disagree, too. See also RFC 2782. We should totally have a fallback, so the service name should be registered with IANA with a port number.

Elsewhere being the mailing list

yep I see that in the email chain now ralphm

rion: could you send a mail on this, with maybe some example protocol exchange?

I vaguely recall conversations daniel talking about falling back to 443, clearly we can't register that with IANA though

rion: It is a bit hard to wrap my head around it.

I actually don't mind either way if the XEP recommends to fallback and/or a port, I just strongly disagree with "MUST NOT fallback"

ralphm: yep. a little bit later. need to finish some regular work stuff first :)

moparisthebest: I think that's not a great idea. However, one could use port 443 as an SRV target port.

rion: 👍

moparisthebest: right, I think we should prevent doing something special. I'd like to use existing generic SRV handlers.

especially when it's only downsides, basically just allowing a network MITM to keep you disconnected when there is a chance you could connect

moparisthebest, an evil attacker can also insert a broken A/AAAA record

if you assume that DNS can be meddled with, all bets are off

right, should probably fallback then too

fall back to what?

everything you can

there is nothing to fall back if your attacker spoofs A/AAAA

you just end up with broken TLS, hopefully

ah sorry I read that as 'broken SRV record' but yea

jonas’: I don't think it is useful to think about spoofing DNS in this context.

ralphm, indeed

But following the RFC on SRV records seems sensible.

I think it is though, you can't get around everything an evil mitm could do of course, but maybe you can get around some of them, and there is no reason to give up early

ralphm: So does that mean the "fetch both _xmpp and _xmpps SRV and merge the results" is undesirable?

Yes

I tend to agree

that is optional though

moparisthebest, initiating connections the domain owner clearly did not intend you to do is probably not a good idea

and this is what you’re doing in this case

the endpoint you end up connecting to may easily be a hacked webserver for the same domain

it may be in an entirely different trust domain. just don’t do things the domain owner asked you specifically not to do by placing SRV records.

you have no guarantees that the SRV record came from the domain owner though

unless DNSSEC, I'm fine with a MUST NOT if you've validated it with DNSSEC

17:29:06 ralphm> jonas’: I don't think it is useful to think about spoofing DNS in this context.

moparisthebest, ^

if the attacker can spoof the SRV record, they can also spoof the A/AAAA you want to fall back to. it’s pointless.

and I disagree with that :)

what you propose does not help against an active DNS attacker, and it makes the situation worse in a non-attacked situation.

because some attacker might just spoof the SRV record and not A/AAAA, or you might be getting A/AAAA over tor because that only supports them and not SRV

(or in a situation where the attacker has control over a specific machine (A/AAAA), but not over DNS)

or a million other reasons

moparisthebest, if you’re connecting via a transport which does not support SRV, then obviously XEP-0386 does not apply to you

Don't worry, be happy. Make sure you validate the TLS certificate.

if domain owner is running a public web server that will be hurt by attempting a funky connection to it, they need to fix that

and neither does the SRV RFC or the parts about SRV in RFC 6120

moparisthebest, it may not be *hurt*, but it may easily log things to plaintext logs which you (as the client/user) wouldn’t want to have there. think pipelining authentication because you "know" the domain already.

SRV RFC is more generic, it doesn't know we have a foolproof way of validating the port we connect to by guessing

validating ... by guessing

we guess the port

what?

we have a foolproof way of validating whether it was correct or not, TLS certs

no, that’s not foolproof

the webserver or whatever on the A/AAAA record *will* have a TLS cert for *exactly* the domain

so you’re on the wrong port, but still connected and TLS says everything’s green

right, and that's fine

no it’s not

400 WHAT ARE THESE ANGLE BRACKETS Connection: gtfo

I still think guessing is stupid

guessing is stupid and dangerous

it absolutely is, again running a public port on the internet means you are willing to accept whatever garbage anyone throws at you

and not only accept, but be happy about it

moparisthebest, yes, and I might log that "garbage" including your SASL PLAIN password into some plaintext files for someone to investigate

which is probably very much not what you want

or alternatively, the webserver may run in a different trust domain and may be owned by an attacker

the domain owner is the one that made a decision to give them a cert valid for xmpp, and to run an xmpp and https service on the same domain

so the owner already decided all that was fine

not really

they have told you via SRV that you should very much should not connect to that webserver machine for XMPP

anything you do beyond that is your fault

again without DNSSEC you can't know that, you can only guess

okay, the discussion has just become a pointless loop

bottom line, as a user, I want to connect by any means possible, I certainly don't want to not connect because a network is poorly configured either intentionally or accidentally

if I understand correctly, you are saying a domain/server operator might not want certain connections, and while I agree, that's tough shit

you open a public port on the internet you have to be willing to accept anything anyhow at any time, period

so we have the two classic camps "fail early and hard on errors" and "just make it work at an ycost"

XML vs HTML

etc

I dislike being compared to HTML but otherwise sure :D

If you want to prevent connections, you can publish an SRV record with . as target

Ask Ge0rG how common it still is for devices to not support SRV resolution

Well, if that's true, they are not able to have functional compliant XMPP implementations.

I imagine the fault would most likely be in DNS resolvers in cheap routers or something

Or Tor.

But wait, how does that prevent a client device from doing SRV? Or do you mean routers blocking SRV requests?

Blocking or otherwise failing for unknown reasons

because a client generally gets their DNS server from DHCP which tells it to use crap router

WiFi routers having a built-in caching DNS server that's borked.

Well, I'm not sure if I want to be in the business of catering for such brokenness.

there’s also some firewall appliances which filter SRV away

And fallback combined with SRV not being critical for the web or email means nobody notices or fixes them.

of course DoX fixes this if you have a hard-coded ip+port for your resolver :D

On the public servers I'm involved with, we'd loose >10% of the users by not redirecting 5222 from the A/AAAA target.

Holger: Sounds like what Ge0rG has said about yax.im

Holger: wow. Are those corporate users?

Also, how can you tell.

ralphm: I don't think so; as I said, from what I've seen it's mostly crap end-user routers and Tor.

Tor is not on my radar

But how can you tell that users cannot use SRV?

ralphm: I just check the percentage of the connections that are redirected from the A/AAAA target.

Oh, you publish a different host in SRV?

ralphm: Yes.

I kinda want users to complain to their ISPs.

ralphm: Not sure about the Tor/crap-router ratio. But it's definitely not just Tor.

ralphm: Well they'd have to complain to their router manufacturers. At least in the cases I tracked down.

(Which was like two or three.)

A popular thing in France was/is affected, for example.

also just as a data point I have what I'd call a "crap corporate network" and SRV is wide open, but it'll only allow HTTP on 80 and TLS on 443, it checks that it's actually TLS too

and yea it'd be great if people complained to ISP/router manufacturers, in practice though it's just "XMPP sucks I can't even connect"

Holger: in most cases people get routers from their ISP. If not, they have themselves to blame for broken behavior.

True that.

Of course neither will stop them from concluding what moparisthebest said. XMPP fails, everything else just works.

Can't have nice things

And corporate users, well, should complain to corporate IT. There's no end to stupidity in that area.

ENTERPRISE

> Star Trek Fan Accidentally Accepts Job Writing "Enterprise Software"

When we worked on Jingle/WebRTC we had some issues with blocked UDP traffic in our office.

ralphm, don't worry QUIC should fix that for you in a bit :)

Thus wasting valuable bandwidth for calls between two people in the office.

moparisthebest: I think QUIC has a lot going for it, but no.

Zash, I think it's more like "can only have nice things if HTTP wants them first" :D

:(

moparisthebest: not in this case, I mean. I definitely would like to see XMPP-over-QUIC.

And indeed if QUIC would work in the corporate environment, then calls would too, since you can use the same port for TURN/STUN.

I mainly meant users will complain if websites quit working, so as websites migrate to http3/udp and break, networks should be fixing that

I think websites will fallback to plain http for a long time

QUIC+WebRTC ? I though wg abandoned this idea because all the id remapping crap for compatibility with STUN and absence of signalling ideas.

thought*

Sure, but I believe even without changes, it can still be done.

Especially with XMPP, as hey, we have signaling.

The conflict is with TURN mostly

I am a bit surprised one of the arguments is that TURN is rarely used with WebRTC, though. TURN was considered a significant requirement when we were building calls in the VEON app.

But that's not on websites, so who cares? Right, fippo?

If web browsers could use our signaling out of the box that would be quite interesting.

Hah, well! If I'm right, the webrtc library has roots in libjingle.

Of course with all the XMPP now removed.

ralphm: I have heard that as well

Maybe we could say XMPP caused WebRTC to happen.

Shouldn't IPv6 fix these issues as well?

because with IPv6, if setup properly every computer on then network get's it's own unique publicly routable IPv6 address

sometimes every device gets a whole range to itself

> because with IPv6, if setup properly

that’s the catch ;)

well

but yes, IPv6 will (hopefully) make many things easier ✏

most corporate enviroments are going to setup PFsense or OpenWRT

which sets up most of ipv6 for you ounce you give it an upstream

we aren't in the dark ages of proprietary router firmware ruling majority anymore, least not for professional space

too many routers got turned into zombies

ironically, the gateway thing provided by my ISP handles IPv6 just fine

it even supports prefix delegation via DHCPv6

I think your view on the activities or competence of corporate IT departments is extremely optimistic.

maybe that's just my area

PFsense? OpenWRT? NOT ENOUGH ENTERPRISE

the only place I've really seen something not PacketFilter of NetFilter based is where it's probably not possible to route/firewall without ASICs

ralphm, that, too

like routing 400+gbps

where we'd use a switch fabric backplane

otherwise everything in the office areas flowed threw a PFsense box.

the 1U unit they sell

You might have been lucky.

I've seen IT departments being understaffed, underfunded, outsourced, and misused for setting up teleconferences.

tom, can you tell my corporate IT dept, they use all the proprietary blackboxes, riverbed, telari, cisco, and palo alto

and those are just the ones I know about

"Ge0rG> Each rich messaging XEP should: - mandate a legacy body format - mandate that the body MUST NOT contain anything else, so that compliant clients can ignore it", I don't want to start a discussion right now (sleep!) but I also don't want to forget about it, so I'll say for now that I'm not sure I like this, and we can come back to it later :)

Dude. I want to sleep.

pep.: I'm going to write that to standards in the context of reactions

Ok

I'll reply to that

https://upload.ik.nu/upload/oQfV7r-1Xd5r9hYF/9XML-6JsSvqz0agHghjWlg.png

https://www.xkcd.com/386/

Yes