So? Many people (not all) are right-wing because they want to preserve beauty. Being a right-wing is not a rare thing, it's the second most popular belief system in the West.
>Another popular one on social media is the Greek and classical world, especially its comparative lack in modern education compared to, say, 1900. That's an easy intro to colonialism and racism
Racism is much less of a thing in Europe, compared to the USA, yet fascination with Antiquity is just the same or even higher.
>Or were old, traditional buildings super expensive?
I'd say yes. Reading fairy tales and historical records, we see just how huge were the prices. A pair of boots could be worth a year's income of a peasant.
Who are those people having lot of time to re-read their old message history? I assume most people only read last several messages in a chat. This matches the real life conversations which are not stored anywhere. However, police will definitely be happy to discover that your many years messaging history is intact.
I would rather want a feature, like Telegram has, where you can set auto-delete of all messages older than N days.
>Who are those people having lot of time to re-read their old message history?
Everyone who has to, say, prove that they kept paying their rent for a year without interruptions. You sent a photo of your money transfer from the bank app to your landlord, and he sends the "received" screenshot from his bank app.
Moreover, a lot (even most) people make personal notes by sending messages to themselves.
For me searching my old messages is really useful. I don't scroll back through history but I'll search for things like "plumber" to find the number of a plumber a friend texted me a while back.
the only people that really trust the police are ones that never actually had to deal with the police (which may be a whole lot of people). however, if you ever have an unfortunate situation to have a run in with the police, there is a good chance you will not be all that trusting any longer. people trust the idea of police more so than anything else
Well, true. But even so, having the history intact is also a way to remove suspicions from yourself.
"Where were you during the event X? I was very far from the place you are interested in, as can be proven by this photo, sent to my grandma, have a look at the history in her phone."
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.
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 :-)
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.
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.
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.
? I've done it a few times. It worked fine on Nokia S40 and the version of J2ME they run can't even seek backwards in files.
It's a three part recipe:
a) send a request to upload with whatever auth you need, some stable identifier for the file and the file size. Ideally a nice checksum to confirm the file was not corrupted in transit; TLS should protect you, but I've seen things, a 32-byte sha256 checksum offers protection from a lot of things.
b) if the upload is unfinished, you'll get a url (or whatever) to post to and a starting offset (0 on the first time); if the upload is complete, you'll get a download url to send to your correspondent. (or an error like file too big, try again later, go away, whatever)
c) upload the file to the url. Maybe get a status if the upload finishes and you're still online to receive it. Status could indicate error or a download url. If you timeout or get a retriable error, go back to part a.
It's not rocket science or anything. Maybe it would be hard to get done in the XMPP ecosystem, but it's simple enough to do with any stack that's got big enough media that resuming uploads is relevant.
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.
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?
And yet the OS is doing just that when you open two TCP streams. It packs them into ethernet frames and keeps track of the acks. Only the OS does not know the context, so it prioritises both streams equally. (Unless some evil magic is involved.)
>And yet you find resuming uploads over http to be too hard?
Me? No. Xmpp developers? Apparently yes, as it's neither in any of the XEPs nor in any of the clients.
> Only the OS does not know the context, so it prioritises both streams equally.
Of course there's prioritization options on socket APIs since forever (DSCP), but usage is limited, because it requires coordination and coordination is hard.
Even with equal prioritization, when you overuse on the media connection and that results in packet loss and congestion window reduction, chat messages don't have to wait for all the dropped packets to be resent over multiple round trip times. If you're lucky the chat connection didn't see any of the loss, and even if you're not, you've likely got a smaller queue on your chat connection than your media connection.
This also doesn't prohibit client driven prioritization --- when connecting, get caught up on chat before processing media. Maybe pause media while sending chat messages or if server acks are slow. Server driven prioritization is hard, because probably your http media servers don't have information on the chat connection --- but if a client stops reading from the media connection, the server will get the message eventually.
>Even with equal prioritization, when you overuse on the media connection and that results in packet loss and congestion window reduction, chat messages don't have to wait for all the dropped packets to be resent over multiple round trip times.
Well, again, it's merely an implementation detail. You could just open a second TCP connection using the in-band IM protocol, not some external HTTP. Or make your IM protocol UDP based.
But really, that's what quic was designed for, which is also not new.
Only in the USA.
reply