3 ms·

>Everyone use HTTP upload nowadays, it works all the time No it doesn't. Firstly, an out-of-band upload is ridiculous. Secondly, it doesn't support upload resu

>Everyone use HTTP upload nowadays, it works all the time No it doesn't. Firstly, an out-of-band upload is ridiculous. Secondly, it doesn't support upload resumption in case the network is bad.

ValdikSS 12d ago
>Firstly, an out-of-band upload is ridiculous It is a bit, true, but the alternatives are worse. XEP-0231 (Bits of Binary) Base64-encoded data inside the text message is more ridiculous idea. Direct P2P connections, which were widely used before HTTP upload, are mostly not working in our day. >it doesn't support upload resumption in case the network is bad. There's a draft for HTTP for it: https://httpwg.org/http-extensions/draft-ietf-httpbis-resumable-upload.html https://httpwg.org/http-extensions/draft-ietf-httpbis-resuma...
- ezst 12d ago
  Re: P2P, it's kind of making an impromptu comeback. If you want some trivia, IIRC, the developer of Conversations was on some trans-continental flight few months ago and realized that XMPP works just fine on the free onboard internet plan (being considered by the firewall as legitimate "social-usage"), except for HTTP upload. So now, when your HTTP upload fails, Conversations asks if you want to try again with P2P, so you can send your images for free from the plane :-)
- aboardRat4 11d ago
  >but the alternatives are worse It's not that "alternatives are worse, it's that xmpp is a broken protocol, which doesn't include support for anything, even such a basic thing" >There's a draft LOOOOOOOOL
  - ValdikSS 11d ago
    XMPP was not designed for human chat only, and XMPP foundation promotes it as an IoT communication protocol, like MQTT. Thanks to Daniel, the author of this post, we now have communication profiles which the IM-oriented servers and clients follow.
    - aboardRat4 11d ago
      >XMPP foundation promotes it as an IoT communication protocol, like MQTT Which means that it will never work for human messaging, due to all the IoT cruft. >Thanks to Daniel, the author of this post, we now have communication profiles which the IM-oriented servers and clients follow. LOL, he only implemented p2p transfers when it bit himself in the tail on a plane flight. Conversations is the best of them all, but it doesn't mean that it is good.
      - ValdikSS 11d ago
        I use XMPP almost exclusively for the last 10 years and don't see any major issues, not with the protocol, not with the clients. Everything is pretty reliable and works fine.
        aboardRat4 11d ago
        Yeah, me too. Even my mom agrees to use it, because she loves me. But it's a "worksforme" fallacy.
toast0 12d ago
Having media out of band causes some problems but eases others. Having a separate tcp window for media and messages is pretty valuable. Additionally, if media is separate, you might run it in different locations than chat. HTTP may not have native resumption, but it's not hard to do partial upload and resumption over HTTP, you just need agreement on parameters / a protocol to determine where to resume from.
- aboardRat4 11d ago
  >Having a separate tcp window for media and messages is pretty valuable What for? >t's not hard to LOOOOOOOOL
  - ValdikSS 11d ago
    >What for? To prevent head-of-line blocking.
    - aboardRat4 11d ago
      >To prevent head-of-line blocking. Of course using TCP has nothing to do with head-of-line blocking. Only if you blindly do write(socket, fileptr, sizeof(file)), it starts to matter, but, you know, people did not start writing for TCP/IP yesterday. If you have a decent protocol, it splits files (and texts as well) into chunks, and sends them in prioritized order, text chunks having higher priority than binary chunks. The server re-assembles the chunks then. The fact that such a simple way of multiplexing data is a discovery for XMPP fanboys is very revealing.
      - toast0 11d ago
        You can certainly chunk things and interleave/multiplex interactive and bulk data. But it's easy to end up with low throughput, because you limit how much unacked bulk data you send, because you don't want to overqueue bulk data and not be able to immediately write interactive messages. And it's easy to end up with high latency, because despite the limits above, you queued too much and interactive messages need to wait. Or you sent bulk data and there was a burst of packet loss and new data can't be received until the missing packets are resent and received. > people did not start writing for TCP/IP yesterday. And yet you find resuming uploads over http to be too hard?

>Everyone use HTTP upload nowadays, it works all the time No it doesn't. Firstly, an out-of-band upload is ridiculous. Secondly, it doesn't support upload resumption in case the network is bad.

ValdikSS 12d ago

>Firstly, an out-of-band upload is ridiculous It is a bit, true, but the alternatives are worse. XEP-0231 (Bits of Binary) Base64-encoded data inside the text message is more ridiculous idea. Direct P2P connections, which were widely used before HTTP upload, are mostly not working in our day. >it doesn't support upload resumption in case the network is bad. There's a draft for HTTP for it: https://httpwg.org/http-extensions/draft-ietf-httpbis-resumable-upload.html https://httpwg.org/http-extensions/draft-ietf-httpbis-resuma...

ezst 12d ago
Re: P2P, it's kind of making an impromptu comeback. If you want some trivia, IIRC, the developer of Conversations was on some trans-continental flight few months ago and realized that XMPP works just fine on the free onboard internet plan (being considered by the firewall as legitimate "social-usage"), except for HTTP upload. So now, when your HTTP upload fails, Conversations asks if you want to try again with P2P, so you can send your images for free from the plane :-)
aboardRat4 11d ago
>but the alternatives are worse It's not that "alternatives are worse, it's that xmpp is a broken protocol, which doesn't include support for anything, even such a basic thing" >There's a draft LOOOOOOOOL
- ValdikSS 11d ago
  XMPP was not designed for human chat only, and XMPP foundation promotes it as an IoT communication protocol, like MQTT. Thanks to Daniel, the author of this post, we now have communication profiles which the IM-oriented servers and clients follow.
  - aboardRat4 11d ago
    >XMPP foundation promotes it as an IoT communication protocol, like MQTT Which means that it will never work for human messaging, due to all the IoT cruft. >Thanks to Daniel, the author of this post, we now have communication profiles which the IM-oriented servers and clients follow. LOL, he only implemented p2p transfers when it bit himself in the tail on a plane flight. Conversations is the best of them all, but it doesn't mean that it is good.
    - ValdikSS 11d ago
      I use XMPP almost exclusively for the last 10 years and don't see any major issues, not with the protocol, not with the clients. Everything is pretty reliable and works fine.
      - aboardRat4 11d ago
        Yeah, me too. Even my mom agrees to use it, because she loves me. But it's a "worksforme" fallacy.

toast0 12d ago

Having media out of band causes some problems but eases others. Having a separate tcp window for media and messages is pretty valuable. Additionally, if media is separate, you might run it in different locations than chat. HTTP may not have native resumption, but it's not hard to do partial upload and resumption over HTTP, you just need agreement on parameters / a protocol to determine where to resume from.

aboardRat4 11d ago
>Having a separate tcp window for media and messages is pretty valuable What for? >t's not hard to LOOOOOOOOL
- ValdikSS 11d ago
  >What for? To prevent head-of-line blocking.
  - aboardRat4 11d ago
    >To prevent head-of-line blocking. Of course using TCP has nothing to do with head-of-line blocking. Only if you blindly do write(socket, fileptr, sizeof(file)), it starts to matter, but, you know, people did not start writing for TCP/IP yesterday. If you have a decent protocol, it splits files (and texts as well) into chunks, and sends them in prioritized order, text chunks having higher priority than binary chunks. The server re-assembles the chunks then. The fact that such a simple way of multiplexing data is a discovery for XMPP fanboys is very revealing.
    - toast0 11d ago
      You can certainly chunk things and interleave/multiplex interactive and bulk data. But it's easy to end up with low throughput, because you limit how much unacked bulk data you send, because you don't want to overqueue bulk data and not be able to immediately write interactive messages. And it's easy to end up with high latency, because despite the limits above, you queued too much and interactive messages need to wait. Or you sent bulk data and there was a burst of packet loss and new data can't be received until the missing packets are resent and received. > people did not start writing for TCP/IP yesterday. And yet you find resuming uploads over http to be too hard?