how about using the @xmpp@fosstodon.org or another dedicated account to explain XEPs as simply as possible ?
pep.
peetah, you'd pick a random XEP and try and explain it?
pep.
Or would you do that for every XEP that gets changed
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
pep.
peetah, the issue with that is not all XEPs can be explained easily
peetah
I guess every XEP from 001 to the ned
peetah
that would be the challenge
pep.
They're more technical things in there, and there's lots of XEP that depend on others that are more technical :P
peetah
ok so we could decide here which one would be the most valuable and draft it here before sending on microblogging platform✎
peetah
ok so we could decide here which would be the most valuable and draft them here before sending on microblogging platform ✏
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
peetah
the idea is to make users more aware of the modularity of their tool, and give them arguments to promote it
pep.
I don't think it's important to end users tbh :/
pep.
It's important to devs for sure
peetah
I'm not talking about explaining the changes, but what each of them are
pep.
I don't understand
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
peetah
the idea is to make all this XEP environment easier to grab
pep.
"people"?
pep.
We're actually trying to figure out here what kind of people we're targetting :P
peetah
user writing comments on the various platform where the newsletter is published
peetah
that is why I was suggesting a separate microblogging account, so taht it is separated from the newsletter✎
peetah
that is why I was suggesting a different microblogging account, so that it is separated from the newsletter ✏
peetah
if it becomes a reality , we would talk about it in the newsletter but it would live on its own
pep.
Right but are these users really a group of people that need to be exposed to XEPs
peetah
not all of them, bu some are willing to understand the modularity of XMPP to make informed choices ✎
peetah
not all of them, but some are willing to understand the modularity of XMPP to make informed choices ✏
peetah
and reading the full specifications of a XEP is not very tempting
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
peetah
this whole discussion could then be summarized in the wiki✎
peetah
the result of this whole discussion could then be summarized in the wiki ✏
pep.
Tbh I'd also like to have vulgarization material even for developers
Maybe that can help more technical non-technical users also :)
Licaon_Kter
Not a bad idea, but do start with those under 0423 ;)
pep.
Yeah sure, the order is not exactly the most important thing just now :)
peetah
no but it can have its importance if we think of the learning curve
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
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✎
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 ✏
peetah
I would need that :)
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
pep.
emus, a series of blog post or sth? :p
emus
Videos 😀
emus
I also still have my podcast idea in mind
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
peetah
and to do so, I need short and strong arguments, relying on a good knowledge of the XEPs
pep.
Tbh I don't think the strengh of XMPP is in any individual XEP
pep.
It's in the fact that XEPs are a thing
pep.
(That it's possible to extend the protocol)
peetah
can you do what X and Y is doing ? yes there's a XEP for that and it's doing it more efficiently !
peetah
but not implemented everywhere...
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✎
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 ✏
pep.
peetah, yeah I think that's slightly misguided
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 🙂 😀
Licaon_Kter
Eg. PEP XEPs....it's OMEMO but also Movim stuff...but also whatever Salut-a-toi adds up
emus
I dont understand
pep.
Yeah I also don't understand. Is that the list of XEPs you'd like to see explained
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
peetah
I would like to create those basic bricks that would allow any one to have a global understanding of this ecosystem
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
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