XSF Discussion - 2018-02-05

  1. marc

    Ge0rG: anything new regarding protoXEP?

  2. Ge0rG

    hi marc! We got it in, as XEP-0401

  3. Ge0rG

    marc: I've asked for feedback from the standards@ ML regarding the IBR extension, but got not much so far

  4. Ge0rG

    marc: people would prefer a data form :(

  5. marc

    Wow, cool. A data form instead of an ad-hoc command?

  6. Ge0rG

    marc: a data form instead of a new IBR element.

  7. Ge0rG

    marc: for the actual account registration, not for requesting the account

  8. marc

    Okay, so that's what I used in the first place :D

  9. marc

    Not a big problem IMO

  10. Ge0rG

    I don't like it because it requires more complicated logic to figure out how to map fields to your client UI

  11. marc

    Why? The field has a name and the names are defined in the XEP, no?

  12. Zash

    If you do it like in MAM with a basic set of predefined fields?

  13. Ge0rG

    Zash: even then, I end up comparing a list of my own UI elements to a list of server-side form fields, with a need to fall back to a data form UI when a mismatch is found

  14. jonasw

    Ge0rG, I don’t see the point; if you don’t want to support data forms, only support that specific setup of data forms and treat it as if IBR wasn’t supported at all/didn’t work otherwise.

  15. jonasw

    also, Ge0rG: A host MUST NOT add new fields to the 'jabber:iq:register' namespace; instead, extensibility SHOULD be pursued via the Data Forms protocol as specified herein.

  16. jonasw

    (from XEP-0077)

  17. Ge0rG

    jonasw: you can override MUST NOT with another XEP

  18. jonasw

    ugh

  19. Ge0rG

    jonasw: the problem is to detect whether this is the "that specific setup of data forms"

  20. jonasw

    FORM_TYPE would tell you

  21. jonasw

    I don’t see a problem at all. compare form_type, compare set of var values, if they don’t match your expectations, afil ✎

  22. jonasw

    I don’t see a problem at all. compare form_type, compare set of var values, if they don’t match your expectations, fail ✏

  23. Ge0rG

    jonasw: how will FORM_TYPE tell me? It will be just `jabber🇮🇶register`

  24. jonasw

    that’s a start

  25. pep.

    rrr smileys. Ge0rG I assume you meant `jabber:iq:register`

  26. Ge0rG

    pep.: yes, indeed. I need to fix that script finally

  27. edhelas

    https://github.com/henry-luo/mark

  28. Zash

    no

  29. edhelas

    Zash you're so focused on the past

  30. Zash

    no

  31. jonasw

    search for namespace didn’t yield anything

  32. jonasw

    doomed

  33. Zash

    Looked like HTML with {} instead of <>

  34. Zash

    Meh

  35. Zash

    Relevance to XMPP: Can't see any

  36. moparisthebest

    yes that's exactly what we need, one new standard to replace all the existing ones https://xkcd.com/927/

  37. Zash

    It wont

  38. Guus

    obligatory

  39. ralphm

    yaml adoption is limited, haha

  40. Zash

    didn't toml come to replace yaml?

  41. moparisthebest

    I also enjoy how it has downsides to json like 'not as widely supported as json' but no downsides to xml

  42. moparisthebest

    I guess it's as widely supported as XML ?

  43. Ge0rG

    XML, the configuration file format from hell

  44. Zash

    Also, meh, I have Lua table notation. I don't need no JSON-XML hybrid

  45. Zash

    Good luck inventing a format for everything that doesn't suck at everything.

  46. edhelas

    https://xmpp.org/extensions/xep-0239.html cover pretty much all the cases

  47. Zash

    Perfection