XSF Communications Team - 2020-07-13


  1. emus

    peetah, wurstsalat: All merged! Thank you guys!

  2. peetah

    how about using the @xmpp@fosstodon.org or another dedicated account to explain XEPs as simply as possible ?

  3. pep.

    peetah, you'd pick a random XEP and try and explain it?

  4. pep.

    Or would you do that for every XEP that gets changed

  5. peetah

    it would need to be short, simple, user centric, explaining what problem it solves, what constraint it brings and when possible how it is better than other protocols

  6. pep.

    peetah, the issue with that is not all XEPs can be explained easily

  7. peetah

    I guess every XEP from 001 to the ned

  8. peetah

    that would be the challenge

  9. pep.

    They're more technical things in there, and there's lots of XEP that depend on others that are more technical :P

  10. peetah

    ok so we could decide here which one would be the most valuable and draft it here before sending on microblogging platform

  11. peetah

    ok so we could decide here which would be the most valuable and draft them here before sending on microblogging platform

  12. pep.

    You can probably summarize PubSub as "Publish Subscribe" and explain the concept, but then explaining why there's a change in there from "this" to "that" that changes the meaning of 90% of the thing (as an example) and also all dependant XEPs :x

  13. peetah

    the idea is to make users more aware of the modularity of their tool, and give them arguments to promote it

  14. pep.

    I don't think it's important to end users tbh :/

  15. pep.

    It's important to devs for sure

  16. peetah

    I'm not talking about explaining the changes, but what each of them are

  17. pep.

    I don't understand

  18. peetah

    people often complain about the number and complexity of XEPs, why this one is implemented in a server, this one in a client, how they impact them directly and why they should care when choosing their client or server

  19. peetah

    the idea is to make all this XEP environment easier to grab

  20. pep.

    "people"?

  21. pep.

    We're actually trying to figure out here what kind of people we're targetting :P

  22. peetah

    user writing comments on the various platform where the newsletter is published

  23. peetah

    that is why I was suggesting a separate microblogging account, so taht it is separated from the newsletter

  24. peetah

    that is why I was suggesting a different microblogging account, so that it is separated from the newsletter

  25. peetah

    if it becomes a reality , we would talk about it in the newsletter but it would live on its own

  26. pep.

    Right but are these users really a group of people that need to be exposed to XEPs

  27. peetah

    not all of them, bu some are willing to understand the modularity of XMPP to make informed choices

  28. peetah

    not all of them, but some are willing to understand the modularity of XMPP to make informed choices

  29. peetah

    and reading the full specifications of a XEP is not very tempting

  30. peetah

    the microblogging format could be the start of a discussion with those users around a XEP to catch what should be explained and what should be left to experts/developers

  31. peetah

    this whole discussion could then be summarized in the wiki

  32. peetah

    the result of this whole discussion could then be summarized in the wiki

  33. pep.

    Tbh I'd also like to have vulgarization material even for developers

  34. peetah

    it's 23h34, I'm just thinking out loud

  35. peetah

    it's 23h24, I'm just thinking out loud

  36. pep.

    Maybe that can help more technical non-technical users also :)

  37. Licaon_Kter

    Not a bad idea, but do start with those under 0423 ;)

  38. pep.

    Yeah sure, the order is not exactly the most important thing just now :)

  39. peetah

    no but it can have its importance if we think of the learning curve

  40. pep.

    I'll repeat though, for end-users -- like a big chunk of people on linuxfr -- I don't think this is something they need

  41. pep.

    They might be interested in what features they client have, not what a (doesn't have to be the only one) protocol that client is using can do

  42. pep.

    They might be interested in what features their client have, not what a (doesn't have to be the only one) protocol that client is using can do

  43. peetah

    I would need that :)

  44. emus

    peetah, I recently had similar ideas in mind. I like it basically. How this should be done can be discussed. But I basically like it

  45. pep.

    emus, a series of blog post or sth? :p

  46. emus

    Videos 😀

  47. emus

    I also still have my podcast idea in mind

  48. peetah

    again what I would like to be able to do on my own is to explain why XMPP is better than such and such other protocols/tools

  49. peetah

    and to do so, I need short and strong arguments, relying on a good knowledge of the XEPs

  50. pep.

    Tbh I don't think the strengh of XMPP is in any individual XEP

  51. pep.

    It's in the fact that XEPs are a thing

  52. pep.

    (That it's possible to extend the protocol)

  53. peetah

    can you do what X and Y is doing ? yes there's a XEP for that and it's doing it more efficiently !

  54. peetah

    but not implemented everywhere...

  55. pep.

    Because there are lots of XEPs that are actually useless, there are some that are even harmful, then there's those that have nice goals but the spec is sub-par, and there are those that most implementations are using that still have lots of things that needs fixing but won't be changed exactly because everybody is using them

  56. pep.

    Because there are lots of XEPs that are actually useless, there are some that are even harmful, then there's those that have nice goals but the spec is sub-par, and there are those that most implementations are using that still have lots of things that need fixing but won't be changed exactly because everybody is using them

  57. pep.

    peetah, yeah I think that's slightly misguided

  58. emus

    I like the basic approach he has. Maybe XEPs are not he best way to directly advertise XMPP. But maybe peetah can create a few example what he would like to advertise and we look what we can do with it. In general, it is good to make clear why XMPP is the best 🙂 😀

  59. Licaon_Kter

    Eg. PEP XEPs....it's OMEMO but also Movim stuff...but also whatever Salut-a-toi adds up

  60. emus

    I dont understand

  61. pep.

    Yeah I also don't understand. Is that the list of XEPs you'd like to see explained

  62. peetah

    I'm not sure it is the best since I don't have the basic bricks to explain how it works: there are only complex specifications that even repulse those already involved

  63. peetah

    I would like to create those basic bricks that would allow any one to have a global understanding of this ecosystem

  64. emus

    And I join your intention. I am just not sure whats a good way. Mapping of or generaliszing the important XEPs could be helpful too? even for tech-newcomers

  65. peetah

    I believe a simplification effort is required in order to redirect interested end-users to something more accessible than the XEPs specifications: what, why, current limits and possibly how it compares to their equivalents in other tools

  66. emus

    Yep! Why XMPP? <reasons>