Modern XMPP project discussion - 2019-10-16

what do I need to do to get +w on modernxmpp.org?

I’d like to start writing a pull request ... ;)

Define `+w`

(and knowing you guys I expect this to be a hg repository with markdown files)

(or something like that)

I wish

https://docs.modernxmpp.org/ click "Edit on Github"

oh

there is a Edit on Github

excellent

I already have a fork

fun

Heh

So it's a git repo with markdown files 🙂

git checkout -b feature/consistent-colors

I'm happy to see contributions for modernxmpp :)

I'm planning to launch the blog this week or early next

Will share a draft of the first post here soon

I'll consider that the official announcement of the project, which never really happened so far

a blog, good idea!

MattJ, what is the magic to build modernxmpp.org locally?

oh, mkdocs is a thing which is packaged

I was somehow anticipating some lua hack

Why would you think such a thing?

:D

something about scansion

but the scansion site is also mkdocs iirc?

what do you folks think would be a good place for the stuff I just ripped out of XEP-0392 (<https://github.com/xsf/xeps/pull/845>), i.e. the recommendations on how to form the input to the algorithm as well as avatar substitutes?

There isn't even any Lua involved in building http://prosody.im/ 😛

(there was some involved in converting it from dokuwiki tho)

jonas’, if it pertains only to MUC, I'd say add it to https://docs.modernxmpp.org/client/groupchat/

The best structure for the docs is still an open question, but for now it seems like it would be at home with all the other things to consider when implementing MUC

jonas’: can't we at least keep a MAY for the coloring of occupants (and/or their avatars)?

MattJ, https://github.com/modernxmpp/modernxmpp/pull/24

cc @ Ge0rG

jonas’, maybe XEP-0084 itself?

Recommendation for fallback when data isn’t available sounds sensible at least.

Link Mauve, no, it doesn’t concern wire format

XEP-0084 isn’t only about wire format.

if we ever substitute '392 with something else, we’d have to update '84

No XEP is ever only about wire format even.

which won’t be possible when it reaches Final

It feels more and more like our workflow (incl. final status, deferred, experimental) is the part being broken.

Maybe we should stop pretending we’re the IETF and instead adapt it to how we actually work at the moment? ✏

Or be *more* like the IETF, and only have draft → RFC stages, and then new draft → RFC that replaces the previous one?

Link Mauve, I think in this case it highlights feature creep in a XEP

The only XEP I’ve seen taking that course is Compliance Suite.

Every other one has its number set in stone, and then nobody wants to accept a new one even extending it.

Yes, this one for instance.

When I wanted to extend 0045 with 0153 avatar support in another XEP for instance, I got told there were already too many avatar-related XEPs and that I should instead extend 0045.

MattJ, that was quick

I expected more discussion :)

PR-ocracy?

This ain't the XSF!

Zash, don’t get me started.

Ge0rG, Link Mauve, people are afraid of change it seems :)

Yes.

Breaking Change

Ain't nobody wants to namespace-bump '45

Well.. when you pronounce namespace-b! everybody jumps at you

So either we document that we accept changes forever, which we are already doing by never moving any XEP to final, or we change our workflow entirely.

I’d expect the first one to be easier for the time being.

I-D → RFC → I-D → RFCbis → ...

I also want to be clear about how we operate, and atm what's written doesn't reflect reality (and I don't think what's described is even possible anyway)

XEP-0001bis

Link Mauve, or neither, and simply separate different concerns into different documents.

("No I guarantee you nothing is going to break ever!!")

Link Mauve, regarding the extension of MUC with separate documents, that is an ongoing war, and we also have the issue that we cannot really document such additions because our registries are broken

jonas’, MUC isn’t the only case where this happens.

PubSub is the other?

Pubsub already has every feature you can imagine, you probably just haven't found it yte.

No, we basically never want to commit anything to final in fear of having to change it afterwards.

I just left a comment on https://github.com/modernxmpp/modernxmpp/pull/23

Feedback welcome

“So we have this balance between making things easy for developers and making things easy for developers.” ?

pep., correct. :p

:)

My 2 cents, lingo for devs doesn't have to be the same that's used for users. And the target of this document is devs not users (in hope that they use it for users :p)

👍

Re #23 devs should use terms as defined in specs.

"specs"?

XEPs/RFCs?

RFC and XEPs as well, I hope they use the same terms. I just started to read and develop agains the RFC.

What do you mean with "as well"?

Are you talking about the terms modernxmpp defines?

I'm talking about #23 and I fully agree on https://github.com/modernxmpp/modernxmpp/pull/23#issuecomment-542806746