3 ms·

the examples given (matrix, activitypubkindathing) both have major players (matrix, mastodon) that move fast enough that everyone else is constantly chasing aft

the examples given (matrix, activitypubkindathing) both have major players (matrix, mastodon) that move fast enough that everyone else is constantly chasing after parity with them, which IMO kinda re-enforces moxie's point. As far as I can tell, if you want to do fully open and parity, you got either IRC, the joke being still lack of parity, no client can agree on using the same E2E encryption method, etc. Or XMPP, once again, 5million extensions to the spec (the XSF recommends reading through 23 seperate RFCs to get an idea of how to implement a client). - - - So, if you have issues with the current options, and concrete ideas of how to solve them, please free us all from the hell that is current open communications. This isn't a "just fork it", its an earnest plea.

MattJ100 4y ago
> Or XMPP, once again, 5million extensions to the spec (the XSF recommends reading through 23 seperate RFCs to get an idea of how to implement a client). Fact check: The XMPP core protocol is split into three RFCs, one describing the fundamental building blocks of the protocol (RFC 6120, "XMPP core") and the second describing how to compose these for instant messaging (RFC 6121, "XMPP IM"). Finally, there is an additional short RFC which describes the address syntax and rules (RFC 6122). These documents are stable, and need to be updated rarely. Other things such as audio/video calls, file transfers, push notifications and such, are defined by the XMPP Standards Foundation (XSF), as I imagine you know, in documents known as "XEPs". These have enabled the evolution of the protocol over the years, and are why XMPP didn't get stuck frozen in time in the early 2000s. People like to point at the "5 million" XEPs (actually, 468). However the truth is that these are not required reading. They are not all applicable to IM clients (e.g. XMPP is used in IoT and other places), and many are simply proposals/experiments that didn't take off (XEPs have a lifecycle, including states such as "proposed" and "stable"). The XSF is a place of sharing and collaboration, and these proposals are a natural side-effect of that process. The actual required reading is published annually in the "compliance suites" which describes what implementations are expected to be supporting in any given year. This promotes interoperability, encourages regular reviews of the ecosystem, and helps developers to discuss and plan their roadmaps. The 2022 document is here: https://xmpp.org/extensions/xep-0459.html https://xmpp.org/extensions/xep-0459.html An alternative resource is the protocol overview on modernxmpp.org: https://docs.modernxmpp.org/client/protocol/ https://docs.modernxmpp.org/client/protocol/ Why is all this relevant? Because, although I don't claim XMPP to be perfect (what software/protocol is?), I think this has been a pretty successful model that has stood the test of time and continues to deliver sensible community-driven evolution. The Matrix model is extremely similar (they have "MSCs" instead of "XEPs", and they regularly release versioned documents, though not strictly on an annual basis), IRC folk are trying something with IRCv3. Open protocols and ecosystems are hard work, but they are worth it.
- Arathorn 4y ago
  > The Matrix model is extremely similar (they have "MSCs" instead of "XEPs", and they regularly release versioned documents This isn’t strictly accurate. Matrix’s MSCs are effectively proposals to update Matrix’s monolithic spec, and once they are merged into the spec (or closed) they are discarded. So someone reading the spec should never have to mess with MSCs (unless they are implementing something experimental); this is a very fundamental difference to IETF RFCs or XMPP XEPs.
  - larma 4y ago
    I wouldn't call it a fundamental difference. If I was to concatenate the 3 XMPP RFCs and the suggested XEPs from the compliance suite linked, I would end up with a monolithic spec. Every now and then, when a new compliance suite is published, I'd need to update the one concatenated document aka. monolithic spec. A new compliance suite in XMPP "activating" a XEP is like "merging" an MSC. For as long as a XEP is not part of the compliance suite, it's not part of the monolithic spec (it's still just an MSC) and you don't have to mess with it. The only real difference is that the current version of XMPP spec is a document with links to other documents whereas the current version of Matrix spec is a document with links inside the document itself.
- asojfdowgh 4y ago
  https://xmpp.org/rfcs/ https://xmpp.org/rfcs/ I count 23 active also 6122 is replaced with 7622, updated rarely, but updated often enough it seems. I never mentioned "core" for a reason, I used the words "to get an idea of how to implement a client" for a reason. perhaps "recommend" is wrong, but they still list 23 RFCs as relevant. And I'm talking clients mainly as in pre-existing ones, where every landed XEP might need to be implemented if its codified for a given year, even if its removed the very next year. And by fact of XMPP being still updated, means parity chasing is still happening. I'm eager for IRCv3 to end as opposed to becoming a living specification, because no one of any popular client seems even slightly interested in chasing parity anymore, the constant slow trickle of things to change must be so insanely wearing. I don't disagree with "its the best we've got" but when other areas of software development have like, 20 best-we've-gots, but live text communication has 2 best-we've-gots, I would love to see that change, despite not having the skills to do so (but I plan to try regardless!)

MattJ100 4y ago

> Or XMPP, once again, 5million extensions to the spec (the XSF recommends reading through 23 seperate RFCs to get an idea of how to implement a client). Fact check: The XMPP core protocol is split into three RFCs, one describing the fundamental building blocks of the protocol (RFC 6120, "XMPP core") and the second describing how to compose these for instant messaging (RFC 6121, "XMPP IM"). Finally, there is an additional short RFC which describes the address syntax and rules (RFC 6122). These documents are stable, and need to be updated rarely. Other things such as audio/video calls, file transfers, push notifications and such, are defined by the XMPP Standards Foundation (XSF), as I imagine you know, in documents known as "XEPs". These have enabled the evolution of the protocol over the years, and are why XMPP didn't get stuck frozen in time in the early 2000s. People like to point at the "5 million" XEPs (actually, 468). However the truth is that these are not required reading. They are not all applicable to IM clients (e.g. XMPP is used in IoT and other places), and many are simply proposals/experiments that didn't take off (XEPs have a lifecycle, including states such as "proposed" and "stable"). The XSF is a place of sharing and collaboration, and these proposals are a natural side-effect of that process. The actual required reading is published annually in the "compliance suites" which describes what implementations are expected to be supporting in any given year. This promotes interoperability, encourages regular reviews of the ecosystem, and helps developers to discuss and plan their roadmaps. The 2022 document is here: https://xmpp.org/extensions/xep-0459.html https://xmpp.org/extensions/xep-0459.html An alternative resource is the protocol overview on modernxmpp.org: https://docs.modernxmpp.org/client/protocol/ https://docs.modernxmpp.org/client/protocol/ Why is all this relevant? Because, although I don't claim XMPP to be perfect (what software/protocol is?), I think this has been a pretty successful model that has stood the test of time and continues to deliver sensible community-driven evolution. The Matrix model is extremely similar (they have "MSCs" instead of "XEPs", and they regularly release versioned documents, though not strictly on an annual basis), IRC folk are trying something with IRCv3. Open protocols and ecosystems are hard work, but they are worth it.

Arathorn 4y ago
> The Matrix model is extremely similar (they have "MSCs" instead of "XEPs", and they regularly release versioned documents This isn’t strictly accurate. Matrix’s MSCs are effectively proposals to update Matrix’s monolithic spec, and once they are merged into the spec (or closed) they are discarded. So someone reading the spec should never have to mess with MSCs (unless they are implementing something experimental); this is a very fundamental difference to IETF RFCs or XMPP XEPs.
- larma 4y ago
  I wouldn't call it a fundamental difference. If I was to concatenate the 3 XMPP RFCs and the suggested XEPs from the compliance suite linked, I would end up with a monolithic spec. Every now and then, when a new compliance suite is published, I'd need to update the one concatenated document aka. monolithic spec. A new compliance suite in XMPP "activating" a XEP is like "merging" an MSC. For as long as a XEP is not part of the compliance suite, it's not part of the monolithic spec (it's still just an MSC) and you don't have to mess with it. The only real difference is that the current version of XMPP spec is a document with links to other documents whereas the current version of Matrix spec is a document with links inside the document itself.
asojfdowgh 4y ago
https://xmpp.org/rfcs/ https://xmpp.org/rfcs/ I count 23 active also 6122 is replaced with 7622, updated rarely, but updated often enough it seems. I never mentioned "core" for a reason, I used the words "to get an idea of how to implement a client" for a reason. perhaps "recommend" is wrong, but they still list 23 RFCs as relevant. And I'm talking clients mainly as in pre-existing ones, where every landed XEP might need to be implemented if its codified for a given year, even if its removed the very next year. And by fact of XMPP being still updated, means parity chasing is still happening. I'm eager for IRCv3 to end as opposed to becoming a living specification, because no one of any popular client seems even slightly interested in chasing parity anymore, the constant slow trickle of things to change must be so insanely wearing. I don't disagree with "its the best we've got" but when other areas of software development have like, 20 best-we've-gots, but live text communication has 2 best-we've-gots, I would love to see that change, despite not having the skills to do so (but I plan to try regardless!)