XSF Discussion - 2018-03-10


  1. Seve/SouL

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

  2. Ge0rG

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

  3. Seve/SouL

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

  4. Seve/SouL

    So yeah, I'm late indeed.

  5. jonasw

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

  6. jonasw

    lol

  7. SaltyBones

    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.

  8. SaltyBones

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

  9. Dave Cridland

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

  10. SaltyBones

    And it has very much failed to change...

  11. Dave Cridland

    Across its lifetime? Or just recently?

  12. Dave Cridland

    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.

  13. SaltyBones

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

  14. SaltyBones

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

  15. SaltyBones

    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.

  16. SaltyBones

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

  17. Dave Cridland

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

  18. SaltyBones

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

  19. Dave Cridland

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

  20. Dave Cridland

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

  21. SaltyBones

    🤔

  22. SaltyBones

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

  23. Dave Cridland

    I suspect so.

  24. SaltyBones

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

  25. SaltyBones

    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?

  26. SaltyBones

    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.

  27. Dave Cridland

    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.

  28. SaltyBones

    I think those are contradictory statements in this context.

  29. SaltyBones

    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!

  30. Ge0rG

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

  31. Ge0rG

    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.

  32. edhelas

    what are the recommended and deprecated SASL mechanisms ?

  33. Zash

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

  34. edhelas

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

  35. Zash

    Like what?

  36. edhelas

    PLAIN, CramMD5, DigestMD5

  37. Zash

    DIGEST-MD5 is already deprecated

  38. Zash

    And PLAIN is not going anywhere

  39. edhelas

    ok

  40. Zash

    -rfc 6331

  41. Bunneh

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

  42. Zash

    Deprecated since 2011

  43. Maranda

    I'd like to see PLAIN deprecation

  44. Maranda

    And everyone failing to connect

  45. Maranda

    🤣

  46. edhelas

    ok so I'll remove it from my list

  47. Zash

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

  48. Zash

    edhelas: You have CRAM-MD5 support?

  49. edhelas

    seems so

  50. edhelas

    I'm looking to remove it as well

  51. Zash

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

  52. edhelas

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

  53. edhelas

    don't know about the -PLUS