Would be sweet if I can have a static #HTML / #CSS website that uses #HTMX for interaction with a backend written in Kotlin and compiled to #wasm running on an edge location using #wasi .
Hey #journalists if you're going to use an open source project as an example of a hack, can you at least let them know in advance you're about to do something reckless so they can prepare?
Não uso muito streaming, mas no início da pandemia, dando suporte às aulas/eventos remotos percebi que nitidamente as soluções Google funcionam mais fluidas.
Não só em relação às soluções on-premisse (Jitsi, ConferênciaWeb, BigBlueButton), mas também em comparação com Zoom, Teams, Skype.
O que Google tem diferente que explicaria isso?
Redes de entrega de conteúdo mais próximas?
Parcerias com provedores de internet, tipo aquilo que o Netflix faz (uma espécie de cache local)?
Algum privilégio nas infraestruturas de transporte de dados?
Non so quanto senso abbia onestamente, ma probabilmente se potete è meglio firmarla che non. Un mesetto fa ho già parlato della questa questione anche qui sopra, e le cose sono solo peggiorate… non ho una timeline completa sotto mano ma insomma, i #blocchi sono stati più profondi e #problematici, sono stati bloccati siti legittimi ed economicamente e moralmente danneggiate persone che hanno quindi anche sporto querela, tramite un nuovo #blocco di #CDN anche di #CloudFlare (più incidenti minori). Quest’ultima si sta anche giustamente incazzando e ora sta iniziando pure a inviare mail ai suoi utenti chiedendo di lamentarsi con le autorità dei #problemi che questa #merda sta causando e potrà continuare a causare. Ma io ripeto, passino loro che anche se sono una parte (ahinoi) fondamentale dell’infrastruttura di #Internet non sono conosciuti dai normie… ma io ora aspetto che venga fatto un bel torto magari ad Amazon, a Microsoft, a Google, insomma altre aziende ben conosciute anche da chi non mastica tecnologia… me ne farò di risate quando tutti loro si coalizzeranno per boicottare #AGCOM e compagnia bella! 😍
E comunque rimango dell’idea che ‘sta cosa non si doveva proprio fare, perché nel nostro paese abbiamo il #vizio di fare sempre tutto e male finché ci sono gli interessi privati di mezzo (mentre quando ci sono gli interessi del popolo, le cose non si fanno e basta). Tutti i nostri parlamentari sono dei #cretini e noi come popolo siamo dei #coglioni; vi ricordo che la legge che ha portato a #PiracyShield era stata approvata all’unanimità, una cosa assurda, sicuramente un po’ per le #mazzette date dalle #lobby del #calcio ai nostri politici, e sicuramente un altro po’ per peer pressure tra quei signorotti sia al #governo che all’opposizione. Perché il colmo definitivo è che questa #cagata non funziona! Io continuo a seedare (caricare via torrent) decine e decine di GB al giorno di materiale #pirata, e il fatto che ci siano la nuova #legge e la #piattaforma scassata non mi ha impattata di una virgola; letteralmente, magari sarà che io ho a che fare con materiale che non è sport, però davvero pirato tanto bene quanto prima senza alcun accorgimento. #Soldi pubblici semplicemente bruciati, e nessuno che se ne vuole prendere la responsabilità, la #questione alla fine è anche questa, non sono solo i #danni causati e prospettati al #web. 🤮
Though the plugin still has some rough edges and missing features, overall I think it is working pretty well for what I wanted. When I post on joelencioni.com, I can see my post in my Mastodon feed pretty quickly—though sometimes the formatting isn’t the best but I suppose that’s just the way it is. And, commenting is bi-directional: replies from Mastodon show up as comments on my blog, and replies to those comments from my blog show up as replies on Mastodon. Great!
The ActivityPub plugin watches for when the client sends a request HTTP header that is asking for content with the mime type of “application/activity+json”. If that type of content is requested, then instead of responding with the web page, it will respond with some JSON data meant for machine consumption instead of human consumption. This is how the syndication works, and that all seems fine.
However, I have been bumping into an issue due to the way this all works together with the CDN I chose for page caching, CloudFlare.
This is what one of my blog posts looks like when the ActivityPub JSON is served instead of the web page.
The problem is that CloudFlare will cache the first version of the page that is requested and serve that up to everyone going forward, regardless of the type of content being requested.
Thankfully, I found a new approach to try. Using CloudFlare workers, I can program the CDN to vary the content based on this header with this bit of code:
export default { async fetch(req) { const acceptHeader = req.headers.get('accept'); const url = new URL(req.url); if (acceptHeader?.indexOf("application/activity+json") > -1) { url.searchParams.append("activitypub", "true"); } return fetch(url.toString(), { cf: { // Always cache this fetch regardless of content type // for a max of 5 minutes before revalidating the resource cacheTtl: 300, cacheEverything: true, }, }); }}
This tells CloudFlare to look at the accept header, and if it has “application/activity+json”, it will add “activitypub=true” to the request query string (the part of the URL after the question mark) behind the scenes, which effectively makes it a different URL. This allows the different content to be cached and served up differently, which I think should solve the issue for me for good. If you still see this problem, please let me know!
For a very small instance with only a couple of concurrent users a CDN might not make much difference. But if you take a look at your web server logs you’ll quickly notice that every post / like / vote triggers a storm of requests from other instances to yours, looking up lots of different things. It’s easy to imagine how quickly this would overwhelm an instance once it gets even a little busy.
One of the first web performance tools people reach for is to use a CDN, like Cloudflare. But how much difference will it make? In this video I show you my web server logs before and after and compare them.
The short answer is – before CDN: 720 requests. After CDN: 100 requests.
Usually just turning on a CDN with default settings will not help very much, you’ll need to configure some caching rules or settings. By watching your server logs for a while you’ll get a sense for what needs to be cached but check out mine for a starting point:
Beware of caching by URI Path because often fediverse software will return different data depending on the Accept header that the requester sets. For example, on PieFed and Lemmy instances a request by a web browser to /post/123 will return HTML to show the post to someone. But when that same URL is requested with the Accept: application/ld+json header set, the response will be an ActivityPub representation of the post! You don’t want people getting activitypub data in their browser and you don’t want to be serving HTML to other instances. Once you spot a URL you want to cache, use a tool like Postman to set the Accept header and make a fake ActivityPub request to your instance and see if you get back HTML or JSON.
Another problem that can happen is that often a response will vary depending on whether the viewer is logged in, or who is logged in. If you can figure out how to configure the CDN to pay attention to cookies or whatever headers are used for Authentication by your platform then you might be able to cache things like /post/*… I couldn’t.
The things I’ve chosen to cache by URI Path above are ones that I know don’t vary by HTTP header or by authentication.
Although we can’t use URI Path a lot of the time, we can cache ActivityPub requests by detecting the Accept: allocation/ld+json header:
https://join.piefed.social/wp-content/uploads/2024/02/caching_activity2-1024x811.pngThis will cache all ActivityPub requests, regardless of URL. People browsing the same URLs as those used by ActivityPub will be unaffected as their requests won’t have the special HTTP header. I used a short TTL to avoid serving stale data when someone quickly edits a post straight after creating it.
There seems to be a deep vein of optimization here which I’ve only just started to dig into. These changes have made a huge difference already and for now my instance is under very little load so I’ll leave it there for now…
@piefedadmin “often fediverse servers return different data”
You mean that the servers don’t set Vary headers for the headers that can change per response ???
I would like to see fediverse platforms introduce a random amount of delay to their requests so they don’t hammer origin servers all at once. It really wouldn’t matter if a post was ingested 0 to 30 seconds later, would it?
Also, cache the results of queries for longer. Most of the requests are looking up data that probably hasn’t changed since last time it was queried.
Also, use a caching mechanism like ETags or something so origin servers can return HTTP 304 to indicate it hasn’t changed.
Simple stuff like that would make a huge difference.
🪡 🧵 Would you like to learn a new skill while doing something good for the environment? The éco-quartier Côte-des-Neiges and the FabLab at the Bibliothèque Interculturelle are joining forces to give you the chance to learn how to use digital sewing machines! 🪡 🧵
Hands up if you caused a global outage today...
Just me?
Sorry!
I was making a change to our "outside the UK" CDN config today for www.bbc.co.uk & www.bbc.com & the change included 2 bugs which pre-testing didn't spot:
@nhoizey Did you give it a spin? I'm biased, but I'm not impressed (yes, beta, I know).
I mean, it would be a shame for web perf if devs think that "I'm using a image resizing service, so my performance is great!", when there's so much more to image optimization than just size and converting to webp...
#Discord will switch to temporary file links to block #malware delivery
Discord's #CDN is regularly abused by threat actors to host and drop malware such as information stealers. Discord has always struggled with mitigating this.
The hope is that temporary file links will make it that much harder for threat actors to host malware using Discord's CDN... but we will see. Supposed to roll-out by end of the year.