XSF Discussion - 2020-08-28

  1. pep.

    https://www.mnot.net/blog/2020/08/28/for_the_users nice read for the weekend. I think that's a stab in the direction I'd like the XSF to take as well :)

  2. pep.

    > So at its heart, “The Internet is for End Users” is a call for IETF participants to stop pretending that they can ignore the non-technical consequences of their decisions

  3. Daniel

    Am I reading this right that the articles only example of 'bad' / controversial rfcs is DoH but at the same time it admits that DoH is a bad example because filtering porn based on DNS was a terrible idea to begin with?

  4. jonas’

    there’s also ADD in the pipeline

  5. jonas’

    of which I don’t know exactly how terrible it is

  6. Zash

    Everything is terrible.

  7. MattJ


  8. jonas’

    MattJ, https://datatracker.ietf.org/wg/add/about/

  9. jonas’

    TL;DR so far

  10. jonas’

    but #powerdns is concerned, and that’s never a good sign

  11. pep.

    Daniel: it's just one of the latest and most obvious exemples that have had echo in the political spheres

  12. jjrh


  13. jjrh

    someone from the council might want to reply to that thread - quite a bit of stuff that really isn't the case in 2020.

  14. Ge0rG

    That's a very long thread

  15. Zash

    And it started over a month ago, and the thing seems to have already happened.

  16. jjrh

    Yeah sorry I just saw it today

  17. Zash

    Anything specific we can address; "It doesn't work for various reasons because of how poor it is" is kinda vague and hard to respond to.

  18. jjrh


  19. jjrh

    Some of the stuff being said is surprising to me considering xmpp /is/ a IETF standard.

  20. Ge0rG

    Zash: specific thing: offer to run an xmpp server that's tied into ietf account database, provide MAM and guidance on which clients (not) to use

  21. Zash

    IETF has an account database? News to me.

  22. Zash

    Thought everyone participated via email

  23. jjrh

    You need a account on https://datatracker.ietf.org/

  24. Zash

    There was some OIDC mention in the middle of that thread

  25. Zash

    We were going to do something a few years ago but it didn't really happen.

  26. Ge0rG

    https://mailarchive.ietf.org/arch/msg/ietf/GXtpcDuBcjTq_hc-mPggKnH41Eo/ is asking for snikket

  27. Zash

    Just need the iOS story to be in order...

  28. jjrh

    Isn't there a iOS client that meets 0423 'advanced' ?

  29. Ge0rG

    Zash: thilo got an iPhone now, it's only a matter of time now

  30. Ge0rG

    jjrh: is there any client at all?

  31. Wojtek

    > Isn't there a iOS client that meets 0423 'advanced' ? @jjrh and @Zash SiskinIM perhaps (and BeagleIM for macOS)? though it lacks XEP-0245 (alas I'd question the need for it...)

  32. Zash

    Wojtek: Yeah I hear there's good progress being made on those 🙂

  33. Zash

    I meat, Snikket is still in alpha, so while there's progress being made on that kind of thing it's not completely there yet, and I've had poor experiences in the past trying to sell alpha stage solutions when there are well-polished proprietary solutions already in use. So, I'm a bit wary about jumping in that thread and telling them to just use Snikket at this point.

  34. Wojtek

    yeah, that could backfire

  35. Wojtek

    but at the same time XMPP seems to be in constant flux

  36. jjrh

    well keep in mind the IETF already uses XMPP

  37. jjrh


  38. Wojtek

    I'd say that recommending beagleIM for mac could be better option than adium at this point; and maybe conversations for android... or a couple of them

  39. eta

    Wojtek, yeah, siskin is pretty solid from what I've seen :) [although if you could auto-enable MAM and push, or at least make it more obvious, that would be great!]

  40. mdosch

    > Wojtek, yeah, siskin is pretty solid from what I've seen :) Yeah, seems to work pretty good for my apples. > [although if you could auto-enable MAM and push, or at least make it more obvious, that would be great!] +1

  41. eta

    (this is beginning to get offtopic for this channel, but does it use a notification service extension like monal was proposing?)

  42. Wojtek

    @eta it should ask user to enable those upon first detection availability - there was an issue in previous versions but it should work better in next one (current testfligh, should be ont next-week-ish) regarding notification extension - we do have something like it, but it's used to decrypt received notifications frmo APNS and not (what you are probably expecting) to do stream resumption

  43. eta

    Wojtek, ah, so server needs to support the tigase XEPs to show payload?