Message delivery is not a problem that needs solving. You don't even need XMPP for that, good old sockets do the trick. The problem is that you need to fetch data over high latency network links and you are not even allowed to cache it due to legal reasons.

Eh, what? The EU data privacy laws have a specific paragraph directly and specifically declaring that caching is exempt.

You can even use worldwide cloudflare caching for your site, and store userdata in the EU, and still comply.

> Eh, what? The EU data privacy laws have a specific paragraph directly and specifically declaring that caching is exempt.

That works for actual short lived caching, but not for database replication which is what you would actually need for services like facebook.

//EDIT: also the directive does not actually mention caching directly, it just mentions various exceptions of the rule. Can I have a reference to what you mean exactly?

Global latency is not that bad for a website. Sending light from one side of the globe to the other is 133 milliseconds and it's not like your sitting in the same room as Facebooks severs anyway.

133ms latency (in the best case) is insanely bad for a database connection!

Even just adding 100ms latency to Google's page load time had a clear measurably effect on # of searches, and having 100+ms latency for each database request during a pageview would absolutely kill performance of most sites...

No it isn't, average page load is much higher. It's a huge struggle to get below 300ms. Adding 100ms on its own is not insanely bad, but the head of line blocking would probably be terrible and that's what would annoy you most.

EDIT: to those downvoting try cold loading google.com, I get > 200ms within San Francisco. 100ms is not "insanely" bad, and maybe a good price to pay for regulated data privacy

But it's 100ms each way for every database request while rendering the page! There's not a lot of apps out there that can do with 1 request to their database during an average page load.

If you actually had that limitation you could redesign the overwhelming majority of apps to only need 1 DB request/response. EX: Stored procedure or map reduce

I think we would adapt. GraphQL and http/2 are steps in the right direction but I expect we would move faster with a strong incentive :)

I think the idea is not that slower speed would impact the Internet, but the Internet is built specifically to handle that kind of impact. Slowing it down would suck, but would not kill it. People managed just fine on dial-up, and the difference between 100ms delay and dial-up is enormous. The only thing it would impact is JS-heavy web apps that rely on pulling megs of content down very quickly. Stuff that looks and feels nice but is hardly necessary.

I can’t find the specific exception anymore, and Google is only delivering articles about today, so I’m sorry (and at any Googlers reading this: Fix your damn algorithms, or at least give us the ability to search the same way as in early 2013! I’m less bothered by spam domains than by getting only buzzfeed etc instead of actual documentation)

Back to topic: Database replication is forbidden, yes. So, well, host your data in the EU for now, and hope that the US finally comes to senses regarding spying. Same applies to GCHQ and BND

> Google is only delivering articles about today, so I’m sorry

only three of my top links are from today if I search something like "EU safe harbor caching" and even fewer for searches that omit "safe harbor" and search for data protection (which gets you the actual directives as the first hit).

Regardless, your problem is solved easily with Search Tools -> Any Time -> Custom range...

Well, that search tool stuff still doesn’t give me any proper links, and with the way Google results are customized nowadays, it’s not really comparable anymore anyway.

Anyway, database replication is nothing that is supposed to be exempt from data privacy laws anyway. You’ll have to deal with it somehow without giving my data into the hands of a US entity.