> Sure, you need a lib - but what the hell do I care?
Well I care, that does not mean that you have to care. Again, look at the lack of client diversity for Matrix and tell me that you do not think that there is at least some correlation in terms of the complexity of the protocol. I sure care that the barriers to entry are significantly higher for Matrix than IRC if you do not have the luxury of having someone else having spent months on a good library for your language of choice (last I checked it meant using either Python or Go). Add to this that the more mandatory features you have and keep adding, the more difficult it will be for clients to keep up.
For what it matters, I use Matrix daily. But I am not going to behave as if images, reactions, code blocks, threads, end-to-end encryption, voice calls, video calls, etc. do not come at a cost.
>Well I care, that does not mean that you have to care.
The point I'm making is that the protocol being implement-able by yourself or grabbing a lib from someone else is moot, since you will 9 times out of 10 use a library.
>Again, look at the lack of client diversity for Matrix and tell me that you do not think that there is at least some correlation in terms of the complexity of the protocol.
The problem is not client diversity for Matrix - there's plenty of them. The problem is that Matrix is more than displaying a log on a screen, and most of the clients are frankly abysmal and could use a trained UI/UX owner.
>last I checked it meant using either Python or Go
The Rust SDK has worked well for me, although I can't state how close it is to Python or Go's libs. That said, I know I'm certainly not the only one using it.
The Rust lib could be wrapped into other languages (e.g, Ruby) if there's not a good SDK for that language. I don't really consider this to be an issue, especially considering the Rust SDK is maintained by the Matrix org themselves.
>Add to this that the more mandatory features you have and keep adding
Don't maintain your own bespoke library and you won't have to. :)
>But I am not going to behave as if images, reactions, code blocks, threads, end-to-end encryption, voice calls, video calls, etc. do not come at a cost.
They do come at a cost, but that's the price of admission for what people expect from modern chat systems. I'd rather live in 2022 than 2004, and I grew up on IRC.
Well, I sure am glad to get told that my concerns and perspectives do not matter because you have different subjective preferences. Despite me being charitable enough to entertain your view on things; especially as I have used and evangelised Matrix for half a decade at this point.
As I am essentially stuck with an argument that boils down to “But I like deep dependency stacks (even with calls across language boundaries) with less than a handful of protocol implementations, there is client diversity (despite the fact that pretty much everyone uses Element despite its glaring UI faults/bugs and no other client seems to keep up feature-wise), and in ${CURRENT_YEAR} I expect these features in a single client/protocol come hell or high water”, I will sign off here as I feel like I am not getting through anyway.
Well I care, that does not mean that you have to care. Again, look at the lack of client diversity for Matrix and tell me that you do not think that there is at least some correlation in terms of the complexity of the protocol. I sure care that the barriers to entry are significantly higher for Matrix than IRC if you do not have the luxury of having someone else having spent months on a good library for your language of choice (last I checked it meant using either Python or Go). Add to this that the more mandatory features you have and keep adding, the more difficult it will be for clients to keep up.
For what it matters, I use Matrix daily. But I am not going to behave as if images, reactions, code blocks, threads, end-to-end encryption, voice calls, video calls, etc. do not come at a cost.