XSF Discussion - 2020-09-30

  1. Zash

    pep., re https://github.com/xsf/xeps/pull/986 I wonder if the type thing should also be mentioned under https://xmpp.org/extensions/xep-0277.html#node_config

  2. Zash

    edhelas, have you seen that ^ btw? comments?

  3. pep.

    goffi gave me an ok :p

  4. pep.

    Zash: k, I can add that

  5. edhelas

    Zash https://github.com/movim/movim/blob/master/lib/moxl/src/Stanza/Pubsub.php#L187 ?

  6. pep.

    I guess he meant "have you seen the PR"

  7. Zash

    Yes, the PR

  8. edhelas

    looks good to me, i'm just wondering how I can migrate to that

  9. pep.

    yeah.. migration is always "fun". Setting the type on creation for a start (to eventually stop creating type-empty nodes), then set the type on type-empty nodes when writing to them? or if you can detect signs of microblog such as presence of id='0' etc.

  10. pep.

    I also need to mandate that for comment nodes right

  11. pep.

    Zash, pushed! Thanks

  12. pep.

    Re comment nodes I'm not entirely sure.

  13. pep.

    I guess whether it's on PEP or PubSub doesn't change the fact that the node will be named urn:xmpp:microblog:0:comments/ID. But it might be good for consistency

  14. pep.

    Also I was gonna add a "MAY" set pubsub#type on PEP (anyway). For consistency always, even though it's also obvious here

  15. pep.

    It's probably the same code that's gonna be used here so at least saying that it's a thing may be good

  16. Zash

    I wonder if MUST is a bit strong (for the other thing). Is #type even widely supported?

  17. Zash

    The field

  18. pep.

    I find the XEP a bit useless without MUST tbh

  19. pep.

    Well, this change, rather. But the XEP becomes unusable without the MUST the second another spec uses pubsub + atom

  20. Zash

    That's already a thing that's done, e.g. fetching rss/atom feeds and pushing into pubsub, or our commit (etc) notifications

  21. pep.

    Here you go

  22. pep.

    I'm not saying I don't want a tool reading "generic" pubsub+atom (whatever that means), but I definitely don't want a tool editing my pubsub+atom extension labelled "not-microblog" with microblog rules

  23. Zash

    Hm. I've got a thing that derives a <body> for pubsub notifications, but it seems it bases it on the payload xmlns, not the #type

  24. edhelas

    https://xkcd.com/2365/

  25. mdosch

    It's two days now and I still don't understand Jabber + TLS = e2e²…

  26. flow

    Am I the only one who finds it remarkably that xkcd #2365 does not mention Matrix?

  27. pep.

    Don't jynx it

  28. moparisthebest

    it doesn't mention XMPP either

  29. edhelas

    Jabber is the new XMPP

  30. mdosch

    I guess for them Jabber == XMPP…

  31. moparisthebest

    I assumed he meant legacy Cisco© Jabber©

  32. pep.

    flow, it also doesn't mention IRC fwiw

  33. pep.

    Well not in the picture

  34. mdosch

    https://xkcd.com/1810/ didn't mention neither jabber nor xmpp.

  35. mdosch

    > Jabber.org (based on XMPP) is a communications protocol based on XML that was developed in 1999. The Jabber protocol could be used with Transport Layer Security (TLS) to have a secure communications service. https://www.explainxkcd.com/wiki/index.php/2365:_Messaging_Systems

  36. mdosch

    Never saw that wiki before. 😂

  37. Neustradamus

    Mistake, it is XMPP since 2004, the original name was Jabber in 1998. Jabber.org is an XMPP service.

  38. pep.

    Neustradamus, maybe you should propose a change on that wiki?

  39. Zash

    TOPIC: Another episode of the never-ending XHTML-IM vs Message Styling story

  40. Daniel

    Anyway I think what ever proper solution comes out of xhtml-im2 or out of body markup or what ever is independent of what we do with 393

  41. eta

    Daniel: agreed

  42. pep.

    Yeah I didn't like the proposal made during summit either tbh..

  43. jonas’

    (for anyone who wants context, start here: https://logs.xmpp.org/council/2020-09-30#2020-09-30-0b1875408a3ee1bb )

  44. Zash

    Random comment: I like the way that SVG has attributes mirroring CSS properties, which seems somehow easier to deal with.

  45. Daniel

    I mean the point raised during summit (remember summits?) of not wanting two truth is also valid and should be taken into consideration

  46. pep.

    Daniel, sure. Which makes me say again "What pains me most is devs thinking this is actually a good solution"

  47. jonas’

    Zash, but then SVG still has CSS to make things more confusing

  48. Daniel

    But again independent of 393

  49. Zash

    sum-mit???

  50. Kev

    I think that is right in principle. Although I think that if you added <strippable/> (which, as noted in https://mail.jabber.org/pipermail/standards/2020-June/037514.html is going to be a huge benefit to Accessibility) 393 would actually be Good Enough, rather than needing immediate replacing.

  51. jonas’

    strippable, which would be a SHOULD or MUST to add? being equivalent to the opt-in I’ve been asking for all the time?

  52. Kev

    jonas’: I think you SHOULD add it if you determine(wave hands) that the user intended the markup - e.g. because you rendered it that way on the text input.

  53. pep.

    And poezio will never add the flag unfortunatley, so receivers will never know

  54. Kev

    Things continue to render it without the strippable, but they have to render the control characters.

  55. pep.

    Fortunately for receivers, poezio is not the most widely used clients out there

  56. Kev

    So I don't claim that by adding this 393 would be the perfect solution (to what I think is an impossible problem), merely that it makes 393 better.

  57. Neustradamus

    pep.: XMPP + TLS or XMPP or other?

  58. pep.

    I don't know, whatever you think is best. Maybe you can be nice with them. XMPP was after all called "Jabber" at the beginning, and the author does still use IRC so I wouldn't be surprised if they still think of XMPP as something from that time

  59. pep.

    Wasn't it called Jabber still when OTR came up? :P

  60. pep.

    arf, stpeter replies to #986 and possibly swipes all the +1 I was gonna get :(

  61. Neustradamus

    pep.: https://twitter.com/neustradamus/status/1311337554793377792

  62. pep.

    great

  63. Neustradamus

    It will be really good if we can plan a migration of mail.jabber.org to mail.xmpp.org...

  64. Daniel

    pep.: if the goal is to find all mircoblogs. Doesn't it matter to what value the type is set to as long as its known and agreed upon?

  65. pep.

    To “Here the payload is Atom, right?” I was gonna reply “I'm saying I wouldn't define the payload as Atom, no.”.

  66. pep.

    The goal is..

  67. pep.

    to be able to distinguish what kind of payload that is. Now it seems peter and I are disagreeing on what payload means..

  68. pep.

    Not especially microblog

  69. pep.

    Say I publish my new spec also using pubsub + atom with different but very specific rules about how to handle Atom stuff that is also different from how the Atom spec defines things, I can, right? It's my spec.

  70. pep.

    Now I don't want microblog clients coming on my stuff and doing non-compliant things

  71. pep.

    And I guess they also wouldn't want that from me

  72. flow

    IMHO pubsub#type should not define the pubsub node's payload type, but the node's type. and the node's type defines which payload(s) you may find in the node's items

  73. flow

    Neustradamus, did it occur to you that explainxkcd.com may be not related to xkcd? because it looks that way

  74. Neustradamus

    flow: Have you looked the source? - https://xkcd.com/2365/

  75. Neustradamus

    The problem is here

  76. Neustradamus

    After the update, the picture will be updated in explainxkcd.com