4 ms·

> What do you have in mind? You are using URIs and HTTP status codes (if you want to call it that, as you are not actually speaking HTTP), which is completely

> What do you have in mind? You are using URIs and HTTP status codes (if you want to call it that, as you are not actually speaking HTTP), which is completely unnecessary (you could transport that same information in JSON, reducing the number of languages that an implementation needs to be able to generate and parse to one instead of three, thus reducing the attack surface by at least 66 % (probably more, given the complexity of HTTP)). I mean, just look at the "lightweight C client" that you linked to above: Not only is it not in C, but it's already full of bugs that are essentially caused by the complexity of all those languages on has to interface with. > But nobody's bothered to implement it, because nobody seems to feel HTTP+JSON is particularly broken in practice. Or, more likely, those who do feel that way have read the spec, facepalmed, and forgot about it?

Arathorn 10y ago
Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;) Totally agreed that HTTP is inefficient and increases the potential bug surface a bit. However, the ubiquity and convenience empirically seems to outweigh the inefficiency and risk. Just to reiterate: the websockets transport does (in part) what you propose: it doesn't use URIs, it doesn't use HTTP status codes; it shoves a stream of JSON over a websocket. We even wrote an implementation of it: https://github.com/matrix-org/matrix-websockets-proxy https://github.com/matrix-org/matrix-websockets-proxy. And NOBODY in over a year has felt the urge to actually implement a client against it - instead there have probably been 40-50 new clients, all who were quite happy to use the ugly HTTP API instead. This doesn't feel like people facepalming and walking off, but just saying "huh, let's see if the HTTP thing is that bad in practice. oh, it's fine, i'll concentrate on writing my bot/bridge/client/whatever".
- zAy0LfpBZLC8mAC 10y ago
  > Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;) Except for the fact that it's necessarily redefining quite a bit of the protocol, also necessarily further complicating any possible universal implementations because this kind of construct doesn't even provide any sensible layering abstractions. > Just to reiterate: the websockets transport does (in part) what you propose: it doesn't use URIs, it doesn't use HTTP status codes Except that the client and the server still need to understand HTTP in order to then implement a bad version of TCP on top of it, more or less, which makes this whole mess even more bloated and error-prone. > This doesn't feel like people facepalming and walking off, but just saying "huh, let's see if the HTTP thing is that bad in practice. oh, it's fine, i'll concentrate on writing my bot/bridge/client/whatever". What exactly would people facepalming and walking off feel like, that this doesn't feel like it? In case you hadn't guessed it yet, that was exactly my reaction when I looked at the spec a while ago, and it just so happened that I stumbled upon this thread here, or you most likely wouldn't ever have heard about it, and I can only guess that I am not the only one. (And no, that reaction was not just based on the use of HTTP, but more generally on the impression from the spec that it's all a huge dysfunctional mess that's essentially impossible to implement securely, and that probably will result in even greater interoperability problems than email with all its historical baggage in a much shorter time frame. All of which in turn makes me suspect that the people who are busily writing software for it just are lacking knowledge and experience to see the flaws, and examples like that "C" client do not exactly help to convince me of the opposite.)
  - vacri 10y ago
    > What exactly would people facepalming and walking off feel like, that this doesn't feel like it? Funny how the silent majority is alway on 'my side'. No-one ever claims that the silent majority is against them.
    - zAy0LfpBZLC8mAC 10y ago
      Where did you pull that supposed majority from?
  - Arathorn 10y ago
    From my perspective, the defining bit of Matrix is the data model (eventually-consistent decentralised Merkle DAGs), the schema, and the semantics of the API - e.g. what arguments do you pass when you paginate? what data do you get when you sync? how do you tell it where to sync from? etc. I genuinely don't care whether you do RPC via an HTTP PUT, a COAP PUT, an MQTT Publish, or some funky custom RPC of your own devising - or whether you encode the data as JSON, CBOR, BSON, protobufs or whatever. To say that switching transport from HTTP to Websockets is "necessarily redefining quite a bit of the protocol" entirely misses the point. It's just a transport! We want people to propose alternative transports! In terms of the websocket transport proposal requiring HTTP to set up the websocket... yes, this is true. I guess you really don't like HTTP - I'm amazed you're willing to use it to communicate on HN! In terms of Matrix being a "huge dysfunctional mess that's essentially impossible to implement securely" - you're entitled to your opinion; it's just a shame it doesn't seem to be particularly well-founded.
    - zAy0LfpBZLC8mAC 10y ago
      > From my perspective, the defining bit of Matrix is the data model (eventually-consistent decentralised Merkle DAGs), the schema, and the semantics of the API Great, and where is that actually specified? > or whether you encode the data as JSON, CBOR, BSON, protobufs or whatever Except that you still need at least a sort-of JSON generator for the signing stuff, thus only adding bloat by using a different format? > It's just a transport! Except that it isn't. HTTP is "just a transport" for JPEG files. You don't need to touch JPEG encoders and decoders to swap HTTP for SFTP, that is what "just a transport" means. > We want people to propose alternative transports! Which is just idiotic, both because you make it unnecessarily difficult if that really is what you want, and because a federated system that doesn't have a common transport protocol just doesn't work. And if you need to expose an HTTP engine for compatibility anyway, it would be just braindead to add further complexity on top of that. > I guess you really don't like HTTP - I'm amazed you're willing to use it to communicate on HN! I don't like unnecessary complexity because it makes it unnecessarily hard to build secure software. The HTTP engines in browsers are probably some of the best-audited ones out there, so it's somewhat acceptable to use them ... but even they have their history of vulnerabilities. The last thing we need is a new large distributed system that's creating even more botnet material than we already have. > it's just a shame it doesn't seem to be particularly well-founded. lol

Arathorn 10y ago

Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;) Totally agreed that HTTP is inefficient and increases the potential bug surface a bit. However, the ubiquity and convenience empirically seems to outweigh the inefficiency and risk. Just to reiterate: the websockets transport does (in part) what you propose: it doesn't use URIs, it doesn't use HTTP status codes; it shoves a stream of JSON over a websocket. We even wrote an implementation of it: https://github.com/matrix-org/matrix-websockets-proxy https://github.com/matrix-org/matrix-websockets-proxy. And NOBODY in over a year has felt the urge to actually implement a client against it - instead there have probably been 40-50 new clients, all who were quite happy to use the ugly HTTP API instead. This doesn't feel like people facepalming and walking off, but just saying "huh, let's see if the HTTP thing is that bad in practice. oh, it's fine, i'll concentrate on writing my bot/bridge/client/whatever".

zAy0LfpBZLC8mAC 10y ago
> Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;) Except for the fact that it's necessarily redefining quite a bit of the protocol, also necessarily further complicating any possible universal implementations because this kind of construct doesn't even provide any sensible layering abstractions. > Just to reiterate: the websockets transport does (in part) what you propose: it doesn't use URIs, it doesn't use HTTP status codes Except that the client and the server still need to understand HTTP in order to then implement a bad version of TCP on top of it, more or less, which makes this whole mess even more bloated and error-prone. > This doesn't feel like people facepalming and walking off, but just saying "huh, let's see if the HTTP thing is that bad in practice. oh, it's fine, i'll concentrate on writing my bot/bridge/client/whatever". What exactly would people facepalming and walking off feel like, that this doesn't feel like it? In case you hadn't guessed it yet, that was exactly my reaction when I looked at the spec a while ago, and it just so happened that I stumbled upon this thread here, or you most likely wouldn't ever have heard about it, and I can only guess that I am not the only one. (And no, that reaction was not just based on the use of HTTP, but more generally on the impression from the spec that it's all a huge dysfunctional mess that's essentially impossible to implement securely, and that probably will result in even greater interoperability problems than email with all its historical baggage in a much shorter time frame. All of which in turn makes me suspect that the people who are busily writing software for it just are lacking knowledge and experience to see the flaws, and examples like that "C" client do not exactly help to convince me of the opposite.)
- vacri 10y ago
  > What exactly would people facepalming and walking off feel like, that this doesn't feel like it? Funny how the silent majority is alway on 'my side'. No-one ever claims that the silent majority is against them.
  - zAy0LfpBZLC8mAC 10y ago
    Where did you pull that supposed majority from?
- Arathorn 10y ago
  From my perspective, the defining bit of Matrix is the data model (eventually-consistent decentralised Merkle DAGs), the schema, and the semantics of the API - e.g. what arguments do you pass when you paginate? what data do you get when you sync? how do you tell it where to sync from? etc. I genuinely don't care whether you do RPC via an HTTP PUT, a COAP PUT, an MQTT Publish, or some funky custom RPC of your own devising - or whether you encode the data as JSON, CBOR, BSON, protobufs or whatever. To say that switching transport from HTTP to Websockets is "necessarily redefining quite a bit of the protocol" entirely misses the point. It's just a transport! We want people to propose alternative transports! In terms of the websocket transport proposal requiring HTTP to set up the websocket... yes, this is true. I guess you really don't like HTTP - I'm amazed you're willing to use it to communicate on HN! In terms of Matrix being a "huge dysfunctional mess that's essentially impossible to implement securely" - you're entitled to your opinion; it's just a shame it doesn't seem to be particularly well-founded.
  - zAy0LfpBZLC8mAC 10y ago
    > From my perspective, the defining bit of Matrix is the data model (eventually-consistent decentralised Merkle DAGs), the schema, and the semantics of the API Great, and where is that actually specified? > or whether you encode the data as JSON, CBOR, BSON, protobufs or whatever Except that you still need at least a sort-of JSON generator for the signing stuff, thus only adding bloat by using a different format? > It's just a transport! Except that it isn't. HTTP is "just a transport" for JPEG files. You don't need to touch JPEG encoders and decoders to swap HTTP for SFTP, that is what "just a transport" means. > We want people to propose alternative transports! Which is just idiotic, both because you make it unnecessarily difficult if that really is what you want, and because a federated system that doesn't have a common transport protocol just doesn't work. And if you need to expose an HTTP engine for compatibility anyway, it would be just braindead to add further complexity on top of that. > I guess you really don't like HTTP - I'm amazed you're willing to use it to communicate on HN! I don't like unnecessary complexity because it makes it unnecessarily hard to build secure software. The HTTP engines in browsers are probably some of the best-audited ones out there, so it's somewhat acceptable to use them ... but even they have their history of vulnerabilities. The last thing we need is a new large distributed system that's creating even more botnet material than we already have. > it's just a shame it doesn't seem to be particularly well-founded. lol