4 ms·

Could you elaborate?

by isaacaggrey 2y ago

ranger_danger 2y ago
https://0x0.st/H8h-.png https://0x0.st/H8h-.png
- Groxx 2y ago
  All that really shows is "the project has an active community". Have you seen how many XMPP has? Or Python[1]? This is just normal open development metadata. [1]: https://peps.python.org/pep-0000/# https://peps.python.org/pep-0000/#
  - jeroenhd 2y ago
    > Have you seen how many XMPP has? Or Python[1]? Python has had 664 PEPs in 23 years (29 per year). XMPP has received 495 XEPs in 23 years (22½ per year). Matrix has received about 650 in 8 years (>81 per year). Four times the change rate is quite annoying when writing code against the spec. Plus, most XMPP clients only support a fraction of the full spec, so by that comparison the impact of the rate of change is even worse. Furthermore, most XEPs and PEPs are mere (optional) extensions, whereas a lot of MSCs are alterations of existing APIs. Any JSON parser used for Matrix needs to anticipate fields changing or being added all over the place because you never know when random fields show up all over the input data because of a spec change. The way the Matrix spec is developed feels a lot more like a proprietary company spec that happens to be published on Github than the IETF/XMPP/Python spec process. The rate of change is high and almost all changes are done to serve new features for the two or three major players that bought into the Matrix ecosystem. One recent change that comes to mind is the move from secret, public URLs for media, to authenticated URLs. The setting to force that changeover won't apply everywhere for a while, but it'll completely break every media-supporting client written before the spec change. Nothing wrong with extending the spec to improve the product, but with how fast the protocol is growing, I wouldn't want to be tasked with maintaining a Matrix client and I don't have much faith in the forward compatibility of the few Matrix bots I've written either.
    - Arathorn 2y ago
      Aaaargh, this comment is a nightmare. It is a GOOD THING for people to open MSCs and try to evolve Matrix, and the number of open proposals shows the enthusiasm in the ecosystem for doing so and proposing ways to evolve the protocol. Meanwhile, the number of actually accepted merged MSCs is way lower - 226 merged in 8 years: https://github.com/matrix-org/matrix-spec-proposals/issues?q=label%3Amerged+is%3Aclosed https://github.com/matrix-org/matrix-spec-proposals/issues?q... - so 28 per year. Same as Python. > I wouldn't want to be tasked with maintaining a Matrix client and I don't have much faith in the forward compatibility of the few Matrix bots I've written either. Authenticated media is literally the first time we've made a significant breaking change on the CS API in 10 years - and was effectively a security fix, to stop people abusing Matrix as a CDN. Bots I wrote 10 years ago still work today without changes (other than auth media). > The way the Matrix spec is developed feels a lot more like a proprietary company spec that happens to be published on Github than the IETF/XMPP/Python spec process. Seriously, read the proposal mechanism (https://spec.matrix.org/proposals/ https://spec.matrix.org/proposals/) and look at a MSC like https://github.com/matrix-org/matrix-spec-proposals/pull/1772 https://github.com/matrix-org/matrix-spec-proposals/pull/177... with >500 comments from across the wider community (so big that it crashed GitHub at the time).
dzaima 2y ago
There are some hilariously ugly things for even trivial things like editing/replies: Edits get a `"m.relates_to": {"event_id": ..., "rel_type": "m.replace"}` field in the body, and `"m.new_content": {...}`, containing the plain-text and HTML versions of the message (while also keeping a copy of both, typically with a prepended "*", outside "m.new_content", for backwards compatibility; yes, that's 4 (four) copies of the message text in an edit; for some while Element generated up to 10 (ten) copies IIRC, due to some proposed extension(s), but that seems to be gone thankfully). Reply messages get `"m.relates_to": {"m.in_reply_to": {"event_id": ...}}` - an annoyingly different format from the edits. It might look like that that allows an edit to change which message is being replied to, but nope, last I checked, that's not supported. Oh and for backwards compatibility a <mx-reply> HTML element is to be prepended, containing a copy of the replied-to message and its info (and yes, that means that the replied-to message effectively can't be deleted as the reply will still contain its text; luckily clients can choose to do not generate such <mx-reply>, but Element still does). And if you want to actually get proper reliable info about the replied-to event, you have to just make an API request for every single one you want to display (unless you happen to already have a cached copy, which luckily for replies is reasonably common). And then there's threads - again in the name of crappy backwards-compatibility there's a mess - within-thread replies imitate a reply to the last in-thread message, along with `"m.relates_to": {"event_id": ..., "rel_type": "m.thread", "is_falling_back": true, ...}`, that "is_falling_back" indicating that this isn't actually a reply (being false when you want an actual reply). And clients are "supposed" to also handle replies to in-thread messages without the "m.thread" relation (which'd come from clients not supporting threads), but as far as I can tell there's no way do to it while paginating without making an API request per every single message (and yes Element behaves quite buggily here). And then there are some things that can't be reasonably handled - the context/message listing/pagination APIs don't give any reaction info (besides the reaction events themselves in chronological position of their addition), so reaction presence/counts in history view must be calculated by clients, and thus won't be able to show ones that were posted a while after the messages. (there used to be some aggregation provided, but it's since been removed!!!) I think the only way to do this properly is truly just making an API request of "list reactions" for every single message the client wants to show. This may make it seem like Matrix has an extremely firm stance on backwards-compatibility, but nope - recently they deprecated & made non-functional the unauthenticated API retrieval of media, making it impossible for clients not supporting video/audio/image display to just open those in the browser, instead forcing them to have custom file downloading & saving code, and also making it impossible to link to media within a message. There was a window of 6 (or less?) months between the new API being finalized, and the old one being removed.

Could you elaborate?

ranger_danger 2y ago

https://0x0.st/H8h-.png https://0x0.st/H8h-.png

Groxx 2y ago
All that really shows is "the project has an active community". Have you seen how many XMPP has? Or Python[1]? This is just normal open development metadata. [1]: https://peps.python.org/pep-0000/# https://peps.python.org/pep-0000/#
- jeroenhd 2y ago
  > Have you seen how many XMPP has? Or Python[1]? Python has had 664 PEPs in 23 years (29 per year). XMPP has received 495 XEPs in 23 years (22½ per year). Matrix has received about 650 in 8 years (>81 per year). Four times the change rate is quite annoying when writing code against the spec. Plus, most XMPP clients only support a fraction of the full spec, so by that comparison the impact of the rate of change is even worse. Furthermore, most XEPs and PEPs are mere (optional) extensions, whereas a lot of MSCs are alterations of existing APIs. Any JSON parser used for Matrix needs to anticipate fields changing or being added all over the place because you never know when random fields show up all over the input data because of a spec change. The way the Matrix spec is developed feels a lot more like a proprietary company spec that happens to be published on Github than the IETF/XMPP/Python spec process. The rate of change is high and almost all changes are done to serve new features for the two or three major players that bought into the Matrix ecosystem. One recent change that comes to mind is the move from secret, public URLs for media, to authenticated URLs. The setting to force that changeover won't apply everywhere for a while, but it'll completely break every media-supporting client written before the spec change. Nothing wrong with extending the spec to improve the product, but with how fast the protocol is growing, I wouldn't want to be tasked with maintaining a Matrix client and I don't have much faith in the forward compatibility of the few Matrix bots I've written either.
  - Arathorn 2y ago
    Aaaargh, this comment is a nightmare. It is a GOOD THING for people to open MSCs and try to evolve Matrix, and the number of open proposals shows the enthusiasm in the ecosystem for doing so and proposing ways to evolve the protocol. Meanwhile, the number of actually accepted merged MSCs is way lower - 226 merged in 8 years: https://github.com/matrix-org/matrix-spec-proposals/issues?q=label%3Amerged+is%3Aclosed https://github.com/matrix-org/matrix-spec-proposals/issues?q... - so 28 per year. Same as Python. > I wouldn't want to be tasked with maintaining a Matrix client and I don't have much faith in the forward compatibility of the few Matrix bots I've written either. Authenticated media is literally the first time we've made a significant breaking change on the CS API in 10 years - and was effectively a security fix, to stop people abusing Matrix as a CDN. Bots I wrote 10 years ago still work today without changes (other than auth media). > The way the Matrix spec is developed feels a lot more like a proprietary company spec that happens to be published on Github than the IETF/XMPP/Python spec process. Seriously, read the proposal mechanism (https://spec.matrix.org/proposals/ https://spec.matrix.org/proposals/) and look at a MSC like https://github.com/matrix-org/matrix-spec-proposals/pull/1772 https://github.com/matrix-org/matrix-spec-proposals/pull/177... with >500 comments from across the wider community (so big that it crashed GitHub at the time).

dzaima 2y ago

There are some hilariously ugly things for even trivial things like editing/replies: Edits get a `"m.relates_to": {"event_id": ..., "rel_type": "m.replace"}` field in the body, and `"m.new_content": {...}`, containing the plain-text and HTML versions of the message (while also keeping a copy of both, typically with a prepended "*", outside "m.new_content", for backwards compatibility; yes, that's 4 (four) copies of the message text in an edit; for some while Element generated up to 10 (ten) copies IIRC, due to some proposed extension(s), but that seems to be gone thankfully). Reply messages get `"m.relates_to": {"m.in_reply_to": {"event_id": ...}}` - an annoyingly different format from the edits. It might look like that that allows an edit to change which message is being replied to, but nope, last I checked, that's not supported. Oh and for backwards compatibility a <mx-reply> HTML element is to be prepended, containing a copy of the replied-to message and its info (and yes, that means that the replied-to message effectively can't be deleted as the reply will still contain its text; luckily clients can choose to do not generate such <mx-reply>, but Element still does). And if you want to actually get proper reliable info about the replied-to event, you have to just make an API request for every single one you want to display (unless you happen to already have a cached copy, which luckily for replies is reasonably common). And then there's threads - again in the name of crappy backwards-compatibility there's a mess - within-thread replies imitate a reply to the last in-thread message, along with `"m.relates_to": {"event_id": ..., "rel_type": "m.thread", "is_falling_back": true, ...}`, that "is_falling_back" indicating that this isn't actually a reply (being false when you want an actual reply). And clients are "supposed" to also handle replies to in-thread messages without the "m.thread" relation (which'd come from clients not supporting threads), but as far as I can tell there's no way do to it while paginating without making an API request per every single message (and yes Element behaves quite buggily here). And then there are some things that can't be reasonably handled - the context/message listing/pagination APIs don't give any reaction info (besides the reaction events themselves in chronological position of their addition), so reaction presence/counts in history view must be calculated by clients, and thus won't be able to show ones that were posted a while after the messages. (there used to be some aggregation provided, but it's since been removed!!!) I think the only way to do this properly is truly just making an API request of "list reactions" for every single message the client wants to show. This may make it seem like Matrix has an extremely firm stance on backwards-compatibility, but nope - recently they deprecated & made non-functional the unauthenticated API retrieval of media, making it impossible for clients not supporting video/audio/image display to just open those in the browser, instead forcing them to have custom file downloading & saving code, and also making it impossible to link to media within a message. There was a window of 6 (or less?) months between the new API being finalized, and the old one being removed.