WEBVTT 00:00.000 --> 00:07.320 This is something that's been bugging me as a side quest. 00:07.320 --> 00:13.640 I am doing a PhD in decarbonising how energy-eating, but as a side quest, I noticed that when 00:13.640 --> 00:20.280 I publish my podcast RSS feed, it's being pulled down a thousand times more than 00:20.280 --> 00:22.480 being needed by all the big players. 00:22.480 --> 00:27.160 I reckon just the four Apple, Amazon, Spotify, and whoever it's pod being, are between 00:27.160 --> 00:33.240 them wasting 100 kilowatt hours of electricity globally, just pulling down podcast feeds. 00:33.240 --> 00:34.240 Anyway, here we go. 00:34.240 --> 00:40.080 So the problem is that even with well-understood protocols, federated ones, like a rule 00:40.080 --> 00:46.920 festival now in our social media, and podcast and RSS is coming back because certain actors 00:46.920 --> 00:51.160 in social media are not making themselves popular, even though some of these protocols 00:51.160 --> 01:00.120 are 20 years old, more, they're being used very badly. 01:00.120 --> 01:07.080 So the problem is in theory if you have a federated system, like say the Fediverse, that there's 01:07.080 --> 01:12.000 no one player that is so powerful that if they behave badly, you have to continue to work 01:12.000 --> 01:13.000 with them. 01:13.000 --> 01:17.640 The problem is, for example, with Apple's podcast directory, as if you don't appear in 01:17.640 --> 01:21.880 there, lots and lots of people never know about your podcast at all. 01:21.880 --> 01:26.600 So Apple is very influential, likewise, Amazon, likewise, Spotify. 01:26.600 --> 01:32.160 And as it happens, therefore, they will not spend the roughly day of engineering at work 01:32.160 --> 01:36.920 it would take to avoid 99% of the waste they're currently inducing. 01:36.920 --> 01:41.200 So I've put, I've named Apple, Amazon, and Spotify here. 01:41.200 --> 01:47.480 There's another player I'd never even heard of called pod being, who, so, I deliberately 01:47.480 --> 01:53.280 didn't update my podcast for three months, guess how often pod and being polls every day 01:53.280 --> 01:59.240 to see if I've changed my mind, they would like to guess an order of magnitude? 01:59.240 --> 02:00.240 How much? 02:00.240 --> 02:07.480 Not quite that bad, but it is literally every six minutes, right? 02:07.480 --> 02:11.160 Okay, next one. 02:11.160 --> 02:16.480 So order of magnitude solutions here, so I've written a little archive paper all they will 02:16.480 --> 02:21.240 put it up soon, but I wrote five things you can do that they could do to be better. 02:21.240 --> 02:28.360 So whenever you do a request over HTTP, which is how podcast feeds are retrieved, I respond 02:28.360 --> 02:35.600 when I serve the file back to you with a content max age, how long it should cash it for. 02:35.600 --> 02:42.280 If you're beating me too fast, I serve you a 503 or 409 error, I say a request after. 02:42.280 --> 02:45.880 So I give you some fairly strong clues, they're saying, that is no point in polling me 02:45.880 --> 02:49.160 again in six minutes time. 02:49.160 --> 02:54.360 In fact, I quite often say, come back in a day, no one pays any attention to any of those 02:54.360 --> 02:55.360 whatsoever, right? 02:55.360 --> 02:56.360 That's the first thing. 02:56.360 --> 03:00.280 If your browsers were like that, your browsing experience would be awful, so this 03:00.280 --> 03:05.600 is really, really basic stuff, which is a two-tone HTTP one. 03:05.600 --> 03:11.360 But I also suggest some defensive rules that you can put into your static configuration 03:11.360 --> 03:13.000 for your web server. 03:13.000 --> 03:18.880 So I was, I had some fun where Apple doesn't even allow you to compress the response, 03:18.880 --> 03:24.520 which isn't really stupid because our assesses at least like four times compressible. 03:24.520 --> 03:29.080 So I randomly reject three out of four of their requests, which gets the bandwidth back 03:29.080 --> 03:33.920 to roughly where it would have been if they had done the right thing in the first place. 03:33.920 --> 03:41.160 So my estimate is seriously, if those four top users would spend the day to actually 03:41.160 --> 03:46.160 respect the 20-year-old elements of the protocols that they're ignoring, it would save, 03:46.160 --> 03:52.240 well, a considerable amount of money and carbon. 03:52.240 --> 03:57.160 And another problem is that the creators of podcasts are not rich people often, right? 03:57.160 --> 03:59.760 They're not all Joe Rogan or his name is. 03:59.800 --> 04:04.200 So they're paying bandwidth charges because Apple can't be bothered to do it right. 04:04.200 --> 04:11.080 But I mean, no, probably no extra person will die from the extra carbon emissions from 04:11.080 --> 04:12.080 these things. 04:12.080 --> 04:15.760 But it's a bit of a canary in the coal mine, it's about like anyone here who is running 04:15.760 --> 04:21.720 a web server has been blasted by OpenAI and everyone else scraping their content, right? 04:21.720 --> 04:25.520 But if you can't be bothered to fix something as simple as this, which all the tools 04:25.560 --> 04:31.040 you need to use in all the protocols had has been in place for two decades, what chance 04:31.040 --> 04:35.560 have we got the people are going to be responsible with newer, really power hungry things 04:35.560 --> 04:36.560 like AI? 04:36.560 --> 04:37.560 So this is my view here. 04:37.560 --> 04:41.840 Now, who knows about Rachel on the Bay? 04:41.840 --> 04:42.840 No? 04:42.840 --> 04:43.840 Okay. 04:43.840 --> 04:50.240 So there, me and a German guy and she have all encountered this problem. 04:50.240 --> 04:57.360 And she has got a sort of feed tester that you can connect your podcast retriever to 04:57.360 --> 04:59.320 and see how well it behaves. 04:59.320 --> 05:00.320 And it will be quite nice. 05:00.320 --> 05:03.740 There are many initiatives, you know, where you go and test your website and see how green 05:03.740 --> 05:04.740 it is. 05:04.740 --> 05:10.120 If Apple could point to their thing at yours and you say, oh, you're an E this week. 05:10.120 --> 05:13.440 Because of course, we're all sort of engineers in this room, right? 05:13.440 --> 05:16.880 So if you see a number, you can make number go up. 05:16.880 --> 05:21.560 So if we made this really easy for people to do, I think we take out a whole chunk of waste 05:21.560 --> 05:23.360 out of this piece of the ecosystem. 05:23.360 --> 05:24.360 Right. 05:24.360 --> 05:25.360 So this is the bottom of it. 05:25.360 --> 05:31.520 Let me say the bit I'm not talking about here is every podcast feed now allows you 05:31.520 --> 05:35.400 to specify multiple versions of the same media. 05:35.400 --> 05:38.280 So by default, you'll get served an MP3. 05:38.280 --> 05:42.680 But you can also say, oh, I'm on my mobile phone, I'd like Opus instead, save 10 times 05:42.680 --> 05:45.960 the bandwidth of the data being transmitted as well. 05:45.960 --> 05:49.280 So guess how well that implemented is. 05:49.280 --> 05:53.560 So there's a lot of waste here, which could be very easily removed, which would be climate 05:53.560 --> 05:56.160 saving, bandwidth saving and money saving. 05:56.160 --> 05:57.880 There we go. 05:57.880 --> 05:59.880 That was my lightning talk. 05:59.880 --> 06:10.280 OK, well, if there's any questions, please go ahead. 06:10.280 --> 06:28.720 Oh, all right. 06:28.720 --> 06:31.720 Yeah, we could do things badly, too. 06:31.720 --> 06:32.720 Yep. 06:32.720 --> 06:36.960 Your presentation and the recommendations you do, are they online? 06:36.960 --> 06:43.720 Yeah, if you go to my site, which is earth.org.uk, and search for RSS in the search box, 06:43.720 --> 06:47.440 it's called RSS inefficiency is the thing. 06:47.440 --> 06:52.880 And you can search for it now, it's up and you can do Google scholar, I think now as well. 06:52.880 --> 06:53.880 Yeah. 06:53.880 --> 06:54.880 Yeah. 06:54.880 --> 06:55.880 Yeah. 06:55.880 --> 06:56.880 Yeah. 06:57.800 --> 07:13.520 So one thing which happily blokes Facebook scraping is the same thing I do with Apple, 07:13.520 --> 07:20.400 which is if they will not even offer GZP as an encoding format off, it's a technical term. 07:20.400 --> 07:21.400 And it's great. 07:21.400 --> 07:23.120 And that blocks all the Facebook straight things straight off. 07:23.120 --> 07:27.440 If they will not even let you compress the stuff, just don't go away, because there's no 07:27.440 --> 07:31.160 good reason for that for any substantial use. 07:31.160 --> 07:32.160 And so there's a bunch of things. 07:32.160 --> 07:35.520 If you look on my page, you'll see there's a few there, RSS specific, but they're very easy 07:35.520 --> 07:36.520 to adapt. 07:36.520 --> 07:38.560 And it's just config in the web servers. 07:38.560 --> 07:41.360 Nothing else. 07:41.360 --> 07:43.040 Anything else? 07:43.040 --> 07:44.040 OK. 07:44.040 --> 07:47.600 What's OK, it's the oven. 07:47.600 --> 07:52.800 Improving UK home heating decarbonization. 07:52.880 --> 07:56.400 Anyway, it's also avoiding wasting energy doing other things we want to. 07:56.400 --> 08:03.120 I mean, you have all the data, you have all the statistics, which you have together. 08:03.120 --> 08:08.360 I mean, you have the considerant, I mean, it's, again, on your card and your time, yes, you 08:08.360 --> 08:09.360 would have been spent. 08:09.360 --> 08:14.360 Have you considered, like, some automatic responses for the big contributors by having, I 08:14.360 --> 08:18.640 don't know, an automatic mail that's sent to some Facebook threat for something like that. 08:18.640 --> 08:19.640 There's no where it's go. 08:19.640 --> 08:24.880 You do know, for example, I do know a bloke inside Amazon, who's pretty senior. 08:24.880 --> 08:27.560 And I've told him about this, and he is cringing suitably. 08:27.560 --> 08:29.560 But I mean, you know, there's nothing you can do. 08:29.560 --> 08:33.600 I am hoping, ultimately, by publishing on archive and by coming, giving talks like this, 08:33.600 --> 08:38.080 that eventually, someone will be embarrassed enough at one of the organizations to go and 08:38.080 --> 08:40.960 say, why are we doing this? 08:40.960 --> 08:46.240 But I have no more control on that, right? 08:46.240 --> 08:47.240 Right? 08:47.240 --> 08:48.240 I think we might be done. 08:48.240 --> 08:49.240 Thank you.