# A Shabbat Radio That Can't Be Paused My Weird Prompts — an AI-generated podcast. Daniel Rosehill sends in a prompt; AI hosts Corn and Herman discuss it. Verify important claims independently. - Episode: 5328 - Published: 2026-09-18 - Duration: 20:57 - Audio: https://episodes.myweirdprompts.com/audio/shabbat-podcast-radio-device.m4a - Tags: rail, audio-equipment, home-automation, open-source, rag - Web page: https://myweirdprompts.com/episode/shabbat-podcast-radio-device/ - JSON: https://myweirdprompts.com/api/episodes/shabbat-podcast-radio-device.json ## Summary What if a podcast player had no controls at all? In this episode, we explore a listener's prototype for a Shabbat-friendly radio: a Raspberry Pi that pulls episodes from an RSS feed, plays them continuously, and lives inside a soundproofed box. Opening the lid is play. Closing it is pause. That's the entire interface. We dig into the halakhic reasoning behind the Shabbat elevator and the concept of grama — indirect causation — to understand why a device that never changes state based on your action might fit within Shabbat observance. Then we build it: the Pi Zero, the amplifier, the acoustic enclosure, and the surprisingly tiny electricity cost. Finally, we confront the design questions that make this more than a build log — how do you model "listening" when the device plays whether you're paying attention or not? What does it mean to have heard something you didn't listen to? And why might the absence of controls be exactly the point for listeners with ADHD who value disconnection but grow bored without stimulation? ## The prompt > This podcast, which is a very proud achievement of mine, has become a sort of beloved background presence in my life. My wife and I both dip in and out of episodes. I send in prompts throughout the day, and I never feel any particular pressure to listen to them in order. I like the fact that we build up a kind of growing library of interrelated topics, and that whenever we feel like searching for them, we can. This is why I think the podcast format, while a useful distribution mechanism, also doesn't quite fit our use case, which is more intended as a growing archive of informative content. Here's one technical question for you guys that I would love to get your take on. My wife and I are both Jewish, and we try to keep Shabbat. I listen to this podcast usually when I'm doing other things. I'll often listen in while I'm cleaning or doing something else. It's actually quite an effective motivator for staying on top of house. Cleaning up sounds boring, but if I say I want to listen to that episode from Herman and Corn, now I have a reason to listen while I clean. The Jewish Shabbat prescribes a period of digital disconnection, which I think is actually extraordinarily healthy. But that involves abstaining from using technology, at least deliberately. Nevertheless, Jewish authorities have found ways to accommodate the use of technology in a way that doesn't violate religious law but jives with modern life. One of those examples is the use of Shabbat elevators. I've always thought that it's a great pity that the one time we have the most bandwidth to read or catch up on our podcasts is the one day that our religion makes it really difficult to do so. Here's the prototype. I'd love to get your ideas on fleshing out the podcast. Jewish law and the use of electricity around Shabbat mean that you can't push buttons or take actions. My idea is something like having an offline radio, which is something I've already wanted to do, which pulls new episodes as they are released from the RSS feed and stores them locally. Not to avoid using the internet per se, which programmatically isn't a problem, but because I think it would make this use case more resilient and widely applicable. My idea is to have something like a little soundbox. Electricity is cheap. And I can't imagine that the running costs from playing a small speaker for 24 hours are all that significant. My idea is that the podcast is always playing. And that you have a box where you can open up the radio, and when you put it back, it's in a soundproof box. a slightly trippier version of this idea is a room with a podcast feed running as a background soundscape. You can physically sit there to immerse yourself, but then you need room-level soundproofing. My radio box is kind of the poor man's or entry-level way to experiment with this idea. The only issue would be, given that the user can't manipulate the device in any way, you can't do the usual user interactions like pausing, changing volume, or skipping episodes. But that actually lends itself well, I think, to the idea that this could be a general-purpose offline podcast player. If you save your listening history, then the background playback mode could specifically stream a randomised series of episodes that you haven't heard yet. And perhaps the data playback database layer could even record whether it was played back in background mode or in regular mode. Because if you listen in background mode, you may not have actually been listening to the device at all, and if you want to hear episodes you haven't yet, you may not have actually listened to it. This is just a very rough sketch and skeleton of an idea that I've had for a while. I'd love for you to flesh out the build from a hardware standpoint and give me your thoughts on how this could actually be a genuinely useful UI for folks like me, especially with ADHD, perhaps, who greatly value the concept of digital disconnection but grow bored when we have no stimulation for 24 hours. I think that, done well, this or some digital reading experience could be a creative way to bridge the chasm between total disconnection and something that already fits with the technologies we love and the content we wish to consume (when we have mental bandwidth and time to do so). ## Show notes A listener wrote in with a build log that's also a legal question and also a small philosophy of attention. He keeps Shabbat — a day of digital disconnection — and noticed the irony that the one day he has the most bandwidth to catch up on podcasts is the day his observance makes it hardest to do so. His proposed device: an offline radio that pulls new episodes from an RSS feed, stores them locally, and plays continuously. No pause. No volume. No skip. You open the box, sound comes out. You close it, the sound is absorbed. That's the whole interface. The halakhic reasoning is the load-bearing wall. Shabbat doesn't prohibit electricity itself — it prohibits certain categories of work, and the relevant one is usually the prohibition on creating or extinguishing fire, which rabbinic authorities extended to completing an electrical circuit. The Shabbat elevator is the canonical accommodation: it runs on a fixed cycle, stops at every floor, and nobody presses a button. The device acts, not the person. The legal concept is grama, indirect causation. A radio that plays continuously without you turning it on or off never changes state based on your action — you're just letting the sound out. The build is almost trivial. A Raspberry Pi Zero 2 W runs a lightweight RSS poller on a timer, downloading episodes to local storage. A two-dollar Class-D amplifier drives a three-inch speaker. Total parts cost: about thirty dollars. Running the Pi and speaker for twenty-four hours draws roughly thirty watt-hours — less than a cent of electricity. The real engineering is the box, which needs acoustic foam or mass-loaded vinyl lining, a gasket seal, and a lid that closes firmly. When open, the box doubles as a speaker enclosure and actually improves bass response. The most interesting design question is what happens to listening data. Most podcast apps assume a play is a listen, but this device plays whether you're in the room or not. The play event happened; the listen event might not have. The solution is a probabilistic model of attention: background plays count partially, active listens count fully, and the user can retroactively mark episodes after Shabbat ends. It's a more honest answer to a question we rarely ask — what does it mean to have heard something you didn't listen to? ## Transcript Corn: Daniel's been thinking about Shabbat again, and this time he's sent us something that's half build log, half legal question, half... I don't know, philosophy of attention. The prompt opens with him saying the show has become a background presence in his life, which I take as the highest compliment, by the way. He and Hannah dip in and out, he sends prompts throughout the day, he never feels pressure to listen in order. It's an archive, not a feed. Corn: And then he gets to the actual question. He keeps Shabbat, which means a day of digital disconnection, and he's noticed the irony that the one day he has the most bandwidth to catch up on podcasts is the one day his religion makes it hardest to do so. Jewish authorities have accommodated technology before, the Shabbat elevator being the classic example, so he wonders if there's a device that fits this specific need. Corn: Here's the prototype. An offline radio that pulls new episodes from the RSS feed, stores them locally, and plays continuously. A little soundbox. The trick is you can't pause, change volume, or skip, because on Shabbat you can't manipulate the device. You open the box, the radio plays. You close it, it's soundproofed. That's the entire interface. Corn: Then he goes trippier. A room with a podcast feed running as a background soundscape, where you physically sit to immerse yourself. Room-level soundproofing, the whole thing. The radio box is the poor man's version, the entry-level experiment. Corn: And then the design questions. How would this work from a hardware standpoint? Without any interactions, how could it be a useful UI, especially for people with ADHD who value disconnection but grow bored without stimulation? Could listening history distinguish background-mode listening from regular listening, and serve a randomized stream of unheard episodes? Could this bridge the chasm between total disconnection and the technologies we love? Corn: So let's start with the law, because the law is what makes this interesting. Herman: The law is the load-bearing wall here. Everything else follows from it. And the first thing to get straight is that Shabbat doesn't prohibit electricity. It prohibits certain categories of work, melakhot, and the relevant one is usually the prohibition on creating or extinguishing fire. Rabbinic authorities extended that to completing an electrical circuit, because closing a circuit is, in a sense, igniting a fire in the wire. So the issue isn't the electricity itself, it's the act of turning it on or off. The manipulation. Herman: The Shabbat elevator is the canonical accommodation. It runs on a fixed cycle. It stops at every floor, the doors open and close automatically, nobody presses a button. You walk in, the elevator does its thing, you walk out. The elevator is doing the work, not you. And the legal concept underneath that is grama, indirect causation. If a device runs on a timer or a fixed loop, the device is the one acting, not the person. You're not completing a circuit, the timer is. Corn: And the debate itself is instructive, because not every authority accepts the Shabbat elevator. Some say you shouldn't use it, some say it's fine, some say it's fine but only in certain buildings. The accommodation is never universal. Which means Daniel's device would land in the same contested space. Some rabbis would look at a box you open and close and say, you're still manipulating something, even if it's just a lid. Herman: Right, and the lid is the interesting question, because opening a soundproof box changes the acoustic environment. Is that manipulation? You're not completing a circuit. The circuit is already complete, the radio is already playing, the amplifier is already running. You're just letting the sound out. That's grama in its purest form. The device is doing everything, you're just... present. Corn: There's a joke in here about a podcast that plays whether you're listening or not, and the rabbi says, but were you really listening? Herman: The joke writes itself. But the legal hook is real. If the radio plays continuously without you turning it on or off, you're not completing a circuit on Shabbat. The Pi boots on Friday afternoon, the RSS poller runs on a timer, the amplifier stays on, the speaker stays driven. You open the box and sound comes out. You close it and the sound is absorbed. The device never changes state based on your action. Corn: That's the legal hook. Now let's build the thing. Herman: The compute is trivial. A Raspberry Pi Zero 2 W, about fifteen dollars, runs a lightweight RSS poller. A cron job or systemd timer that checks the feed every few hours, downloads new episodes to local storage, adds them to a playback queue. A hundred twenty-eight gigabyte microSD card holds hundreds of hours of audio. No screen, no buttons, no keyboard. You configure it once, over SSH, before Shabbat starts, and then you never touch it again. Corn: And the audio path? Herman: A PAM8403 Class-D amplifier board, about two dollars, driving a three-inch full-range speaker. The Pi's headphone jack or a cheap USB DAC feeds the amp. Power is a five volt, two amp supply. Running a Pi and a small speaker for twenty-four hours costs pennies. Daniel's instinct about electricity cost is correct, and I want to underline that, because people consistently overestimate what a small always-on device draws. A Pi Zero 2 W idles at around one watt. The amplifier at low volume draws a fraction of that. You're talking about maybe thirty watt-hours a day. At typical electricity prices, that's less than a cent. Corn: So the running cost is effectively zero. The build cost is maybe thirty dollars in parts. The real engineering is the box. Herman: The box is the interaction. That's the line Daniel gets exactly right. Open it, sound escapes. Close it, sound is absorbed. The box isn't a mute button, it's the entire UI. The physical act of opening and closing replaces play and pause. So the box needs to actually work as an acoustic enclosure. Acoustic foam lining, or mass-loaded vinyl, which is the heavier, better-damping option. A gasket seal around the rim so sound doesn't leak through the seam. A lid that closes firmly, maybe with a latch. When it's closed, you should hear almost nothing. When it's open, the speaker fires out and the box itself acts as a small enclosure, which actually improves bass response. Corn: So the closed box is the pause button, and the open box is the play button, and neither of them is a button. Herman: Neither of them is a button. And the room version is the same idea scaled up. Soundproof a small room, decoupled walls, absorption panels, a door seal. Run the feed as a background soundscape. You sit in the room and the podcast is just there, like air conditioning or a fountain. Architecturally harder, and the cost is orders of magnitude higher, but the principle is identical. The box is the poor man's version, and Daniel's framing is right. It's the entry-level experiment. Corn: The core tradeoff is the thing I keep circling. No pause, no volume, no skip. You can't control what plays or when. That's either a dealbreaker or the whole point. Herman: And I think for most podcast listeners, it sounds like a dealbreaker. We're trained to expect control. Skip the intro, speed up to one point five, jump the ad read, queue the next episode. The entire interface of a modern podcast app is a control surface. This device has no control surface. It's the anti-app. Corn: Which is where the ADHD angle gets interesting, because Daniel names it explicitly. He values digital disconnection but grows bored without stimulation. And the paralysis of choice is real. A queue with fifty unplayed episodes is a decision burden. Every time you open a podcast app, you're making a choice about what to listen to, and that choice has a cost. A device that just plays removes the decision entirely. Herman: This is closer to radio than to podcasts. Radio has always been a background medium. You turn it on, it plays, you don't choose the songs, you don't skip. The constraint is the feature. And for someone with ADHD, the absence of controls removes the thing that makes podcast apps exhausting. You're not scrolling, not choosing, not managing a queue. You're just listening. Or not listening. The device doesn't care. Corn: The device doesn't care. That's the phrase. Most technology cares enormously whether you're engaging with it. It's designed to demand engagement. This thing is indifferent. It plays into an empty room with the same fidelity it plays into a room with a person in it. Herman: And that indifference is what makes the playback database question so interesting. Daniel asks whether listening history could distinguish background-mode listening from regular listening. And the answer is yes, but it requires a data model that most podcast apps don't have. Because a play event isn't the same as a listen event. Corn: Say more about that. Herman: Most podcast apps assume a play is a listen. The episode starts, the app marks it played, done. But on this device, the episode plays whether you're in the room or not. The box is open, the audio is running, you might be cleaning, you might be in another room, you might be asleep. The play event happened, but the listen event might not have. So the database needs to model that distinction. Corn: How would you model it? Herman: Store play events with a mode flag. Background mode versus active mode. A timestamp, a completion percentage. The question is how the device knows which mode it's in. And the honest answer is, it doesn't, not directly. The box being open tells you sound is escaping, but it doesn't tell you anyone is hearing it. So you need a heuristic. Maybe background mode is the default, and active mode is something the user marks retroactively, after Shabbat, when they can touch a screen again. Or maybe the device infers it from patterns. If the box is open for the full episode and no interaction occurs, that's probably background. If the box is opened and closed at specific times, that might be active. Corn: The retroactive marking is interesting, because it means the device is wrong for a full day, and then corrected later. You listen on Shabbat, and on Sunday morning you open a little web interface and say, this episode I actually heard, this one I didn't. And the database updates. Herman: Which is a novel data problem. Most podcast apps assume a play is a listen, and they're wrong a lot of the time. People fall asleep to podcasts. People put on a podcast and then scroll their phone. The play happened, the listen didn't. This device makes that explicit, because it's designed around the possibility that you're not paying attention. Corn: And then the randomized stream of unheard episodes draws from a pool that excludes episodes you've actively listened to, but includes background-mode ones with a lower probability. Weighted, not binary. Herman: Active listens count fully. Background plays count partially. Maybe a background play with the box open for the full episode counts as twenty percent heard. If it plays three more times in background mode, it creeps up. The system is never certain, but it's always updating. It's a probabilistic model of your attention. Corn: Which is a very weird thing to build, and also the most interesting part of the prompt. Daniel is asking, what does it mean to have heard something you didn't listen to? And the device's answer is, it depends on the mode. Herman: The philosophical wrinkle is real. If the box was open while you were cleaning, the episode played, but you weren't paying attention. Is it heard? Most apps would say yes. This device says, probably not, but maybe a little. And that's a more honest answer. Corn: There's a version of this where the device becomes a kind of attention diary. You look back at a month of data and see, this episode played four times in background mode before you actually sat down and listened to it. The data tells you something about your own attention patterns. Herman: And that's where the bridge between disconnection and technology comes in. Daniel's closing thought is that this, or some digital reading experience, could bridge the chasm between total disconnection and the technologies we love. And I think the device does that by reconfiguring the relationship. You're still using a computer. There's a Raspberry Pi in that box, running Linux, polling an RSS feed, decoding audio. But you're not using it interactively. The computer is doing the work, and you're just... present. Corn: The Shabbat constraint forces a design that turns out to be useful for entirely secular reasons. That's the thing I keep coming back to. The constraint isn't a limitation, it's the specification. A kitchen radio for the podcast era. A device that plays without asking anything of you. Herman: And the broader applicability is obvious. This isn't just for Shabbat-observing Jews. It's for anyone who wants a background audio presence without the interaction overhead. Parents who want a device that plays stories for their kids without a screen. Elderly people who find podcast apps confusing. Anyone who misses the radio but wants the archive. Corn: The radio but wants the archive. That's the whole thing in six words. Herman: And the archive is the part Daniel's prompt starts with. He says the show has become a growing library of interrelated topics, searchable, not a feed. The podcast format is a distribution mechanism, but the use case is an archive. And this device is built for the archive. It pulls from the RSS feed, but it doesn't care about release dates. It plays unheard episodes in random order. The archive becomes a stream. Corn: Which is a strange inversion. Podcasts are organized chronologically, newest first. This device ignores that completely. It treats the entire back catalog as a shuffled deck. You get what you get, and the order is irrelevant. Herman: And for a show like this one, with thousands of episodes, that's actually a better way to experience it. Chronological order implies a narrative, but there isn't one. It's an archive. Shuffle it. Corn: Daniel's prompt also touches on something he's mentioned before, this idea that the show is a background presence, something he listens to while cleaning. He says cleaning sounds boring, but if he wants to listen to an episode, now he has a reason to listen while he cleans. The podcast is the motivator. Herman: The device formalizes that. The box is always playing, so the podcast is always available as a background presence. You don't have to decide to put it on. It's already on. You just open the box. Corn: The decision is already made. That's the whole point. The device removes the decision. Herman: For someone with ADHD, removing the decision is the feature. Decision fatigue is real, and podcast apps are full of decisions. What to listen to, whether to skip, whether to speed up, whether to queue. This device has none of that. It's the opposite of a podcast app. It's a radio. Corn: A radio with a memory. A radio that knows what you've heard and what you haven't, and plays the unheard ones. Herman: A radio that admits it doesn't know whether you were listening. That's the honest part. The device is never certain. It's always guessing. Corn: Which is a good place to bring in someone who's been sitting at the desk this whole time, because I think he has a story about a device with no buttons. Hilbert: In 1994 I worked for a company that made talking books for the blind. Four-track cassette tapes, recorded at half speed, so you could fit eight hours of audio on one tape. The machines had one button. Play. You put the tape in and it played until it stopped. No pause, no rewind, no skip. Hilbert: The users loved it. Not despite the lack of controls. Because of it. The library would mail you a new tape when you sent the old one back. You didn't choose what you got next. You just listened. It was the most popular service the company had, and nobody ever complained about the missing buttons. Hilbert: In 1996 the company tried to add a pause button. The complaints were so bad they removed it in the next model. People didn't want control. They wanted the tape to just play. Hilbert: I still have one of the machines in my garage. I think it still works. I've been meaning to test it. Corn: The pause button reversal is the detail I can't stop thinking about. The company added a feature, and the users rejected it. The feature made the device worse for them. Herman: Because the pause button introduced a decision. Do I pause now? Do I rewind? The single button removed all of that. The tape played, you listened, the tape ended. The constraint was the comfort. Hilbert: My brother-in-law repairs audio equipment now. He says the same thing. The more buttons a device has, the more calls he gets from people who can't figure out how to make it work. He says the best devices have one thing they do, and they do it without asking you anything. Hilbert: He's not to be trusted, mind you. He told me my machine was worth forty dollars and then tried to buy it off me. Corn: The garage machine is the proof. A device with one button, from 1994, still works, and the guy who owns it is still thinking about it. Herman: The connection to Daniel's box is direct. The talking book machine played continuously, you couldn't pause it, you just put the tape in. The radio box plays continuously, you can't pause it, you just open the box. The constraint is identical. Hilbert: The tape machine was for people who couldn't see the buttons. The box is for people who can't touch the buttons. Same design, different reason. Hilbert: If Daniel builds the radio box, he should send me a tape. Corn: I don't think the radio box takes tapes, Hilbert. Hilbert: No, but I'd like to see if the garage machine still works. Been meaning to test it for years. Herman: The thing that strikes me about the talking book story is that the users didn't want control, and the company assumed they did. The company thought it was improving the device. The users experienced it as a regression. Corn: Which is the lesson for anyone building this radio box. The absence of controls isn't a limitation to be fixed. It's the specification. Add a pause button and you've broken it. Herman: The playback database is the same kind of insight. Most podcast apps assume a play is a listen, and they're wrong. The radio box assumes a play might not be a listen, and it's right. The constraint forces a more honest data model. Corn: The open question is, what other constraints are we avoiding because they seem inconvenient? The Shabbat elevator and the radio box are both accommodations that turn out to be useful beyond their original context. The constraint is the feature. Herman: The playback database problem, distinguishing play from listen, is going to matter more as ambient audio becomes more common. The device Daniel describes is a prototype for a broader category. Background audio that knows it's background. Corn: The Shabbat elevator stops at every floor so no one presses a button. The radio box plays continuously so no one presses a button. Both are accommodations that turned out to be useful for everyone, not just the people who needed them. Herman: That's the thesis. The constraint is the feature. And Daniel's box is a working example. Corn: Thanks to our producer Hilbert Flumingtop for keeping the show running, as always. This has been My Weird Prompts, the human-AI collaboration podcast. If you want to send us your own weird prompt, email us at show at my weird prompts dot com. We'll be back soon.