5 ms·

There are several Matrix projects that are quite full-featured and were built by a ~single person. Leveraging an appropriate SDK makes it feasible.

pmlnr 6y ago
Most of them in alpha state, with some functionality - read not all XEP implemented ;)
- feanaro 6y ago
  Sure, but that is not unlike the XMPP/XEP situation. That's pretty much unavoidable and comes down to the responsibility of the client. It's natural that there will only be a few full-featured clients since those require a lot of effort with either Matrix or XMPP.
  - pmlnr 6y ago
    That's exactly what I'm saying. XMPP got attacked a lot because of how XEP support was lacking in certain clients, but was implemented in others, yet nearly every federated system out there has the exact same, inevitable problem - email, Matrix, ActivityPub are no exceptions.
    - feanaro 6y ago
      I think XMPP got attacked not because of the fragmented ecosystem of clients, but because the standard itself (in the sense of the complete set of XEPs in existence) got fragmented. As far as I know, multiple competing/overlapping XEPs were not an uncommon situation. Compared to this, the Matrix standard(s) have thus far been able to maintain a certain kind of coherence (IMO), allowing for at least a vision of what a complete implementation of a server or client should look like. The standard is versioned so that you can aim for support of a particular version instead of a pick-and-choose subset of functionality. Also, part of the Matrix's coherence story probably lies in the fact that there is an "official" set of clients in the form of the Element clients. Ultimately, you cannot prevent others from writing incomplete servers or clients. But you can show what the goal looks like and have other implementations approach it asymptotically.
      - ge0rg 6y ago
        There have been significant efforts to reduce this kind of fragmentation and to outline which XEPs a client or server developer should focus on, given a certain target application. We are reviewing the most important specifications on a yearly base and provide recommendations in the form of Compliance Suites with different profiles like Instant Messaging, Mobile etc.: https://xmpp.org/extensions/xep-0443.html https://xmpp.org/extensions/xep-0443.html
        feanaro 6y ago
        That's great info, I wasn't aware of this. Thanks!
remram 6y ago
If you use an SDK, you're not implementing the protocol or any XEP, and therefore it's not a testament to how easy that is to do.
- feanaro 6y ago
  That's true, but then again, if everyone uses a small set of SDKs that are robust and known to be compliant, isn't that a strictly better situation? Why is it important to reimplement the standard itself from scratch?
  - remram 6y ago
    Better situation yes, better protocol no.
    - feanaro 6y ago
      True, though it doesn't imply it's a worse protocol either.

pmlnr 6y ago

Most of them in alpha state, with some functionality - read not all XEP implemented ;)

feanaro 6y ago
Sure, but that is not unlike the XMPP/XEP situation. That's pretty much unavoidable and comes down to the responsibility of the client. It's natural that there will only be a few full-featured clients since those require a lot of effort with either Matrix or XMPP.
- pmlnr 6y ago
  That's exactly what I'm saying. XMPP got attacked a lot because of how XEP support was lacking in certain clients, but was implemented in others, yet nearly every federated system out there has the exact same, inevitable problem - email, Matrix, ActivityPub are no exceptions.
  - feanaro 6y ago
    I think XMPP got attacked not because of the fragmented ecosystem of clients, but because the standard itself (in the sense of the complete set of XEPs in existence) got fragmented. As far as I know, multiple competing/overlapping XEPs were not an uncommon situation. Compared to this, the Matrix standard(s) have thus far been able to maintain a certain kind of coherence (IMO), allowing for at least a vision of what a complete implementation of a server or client should look like. The standard is versioned so that you can aim for support of a particular version instead of a pick-and-choose subset of functionality. Also, part of the Matrix's coherence story probably lies in the fact that there is an "official" set of clients in the form of the Element clients. Ultimately, you cannot prevent others from writing incomplete servers or clients. But you can show what the goal looks like and have other implementations approach it asymptotically.
    - ge0rg 6y ago
      There have been significant efforts to reduce this kind of fragmentation and to outline which XEPs a client or server developer should focus on, given a certain target application. We are reviewing the most important specifications on a yearly base and provide recommendations in the form of Compliance Suites with different profiles like Instant Messaging, Mobile etc.: https://xmpp.org/extensions/xep-0443.html https://xmpp.org/extensions/xep-0443.html
      - feanaro 6y ago
        That's great info, I wasn't aware of this. Thanks!

remram 6y ago

If you use an SDK, you're not implementing the protocol or any XEP, and therefore it's not a testament to how easy that is to do.

feanaro 6y ago
That's true, but then again, if everyone uses a small set of SDKs that are robust and known to be compliant, isn't that a strictly better situation? Why is it important to reimplement the standard itself from scratch?
- remram 6y ago
  Better situation yes, better protocol no.
  - feanaro 6y ago
    True, though it doesn't imply it's a worse protocol either.