XSF Discussion - 2018-03-10

https://news.ycombinator.com/item?id=16540390

Seve/SouL: you are a bit late to the game 😉

I was going to tell that I was reading it because you shared that link some days I ago and I haven't had the time to read it :)

So yeah, I'm late indeed.

> addressing with user-owned identifiers like phone numbers Don't take things like that too seriously. That's just the result of the reality distortion field that comes with sitting on top a huge database of phone numbers.

lol

His observations are correct but the conclusion is wrong. You can have a coherent, changing federated system you just have to keep the number of implementations down.

The problems with XMPP as IM are due to the massive amount of different use-cases of XMPP not the federation.

SaltyBones, Email seems to work despite having wildly different implementations.

And it has very much failed to change...

Across its lifetime? Or just recently?

I mean, I can remember MIME taking over from UUENCODE, so maybe I have a different view, but it seems to have been fairly vibrant up until Google/Hotmail/Yahoo/Exchange basically took over the space and squeezed everyone else out.

hm...well...hard to say what would have been required

but e-mail is very much not the primary means of communication anymore

But yeah, in the corporate environment it evolved quite a bit. You can copy and paste tables into mails and attach skype meeting to them and whatnot....but then again that only really works between outlooks so the "fewer implementations" holds again.

Dave Cridland, but maybe I'm misunderstanding what you're saying, I don't get your comment about hotmail squeezing people out.

Before Outlook was dominant, stuff like message receipts, attachments, etc all came about in a highly federated environment involving dozens of implementations.

hm...guess there must have been a lot more manpower for e-mail back then...?

No, probably not. But *standards* flow faster when you have lots of implementations.

I suspect that Conversations, for example, actually slows things down by being so dominant on Android. There's less incentive to standardize.

🤔

So....the standards flow faster because the devs are trying to figure out how to interop?

I suspect so.

Then it still requires the manpower to implement all those standards to work properly which must have been more than is available now.

But it doesn't really explain what happens in the case of more niche or controverse things. Why did we never get proper e-mail encryption?

I mean, nowadays there is a fucked up incentive towards silos because users are somehow money so the problem must have gotten worse but I think it has always existed.

So we did get proper email encryption. S/MIME actually works, and amazingly works really well if it's a nice implementation. But most implementations suck, and nobody ever really figured out certificate lookup.

I think those are contradictory statements in this context.

Our point was that we want to have a well working federated ecosystem not a "works well if done right but most dont", that's was the problem!

Dave Cridland: there was a really nice idea to put email certificates into DNS with DNSSEC.

And I think that conversations actually accelerates progress because Daniel is actively doing standardization work (albeit not for all the things I'd like to see standardized, mainly for UX), and because Conversations is creating incentives to server developers and operators.

what are the recommended and deprecated SASL mechanisms ?

edhelas: the SCRAM family is mandatory to support per https://xmpp.org/rfcs/rfc6120.html#security-mti-auth

ok, I'm wondering if we can deprecate some mechanisms

Like what?

PLAIN, CramMD5, DigestMD5

DIGEST-MD5 is already deprecated

And PLAIN is not going anywhere

ok

-rfc 6331

Zash: Moving DIGEST-MD5 to Historic. A. Melnikov. July 2011. (Status: INFORMATIONAL) https://tools.ietf.org/html/rfc6331

Deprecated since 2011

I'd like to see PLAIN deprecation

And everyone failing to connect

🤣

ok so I'll remove it from my list

DIGEST-MD5 is disabled by default in Prosody since 0.10.0, and newer worked with hashed password storage.

edhelas: You have CRAM-MD5 support?

seems so

I'm looking to remove it as well

SCRAM-SHA-256 (and -PLUS) would probably be something a modern SASL implementation should have

normally the lib that I'm using is handling SCRAM-*

don't know about the -PLUS