<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>links.lmorchard.com - #localfirst</title>
    <link>/tags/localfirst/</link>
    <description>Recent bookmarks tagged #localfirst</description>
    <lastBuildDate>Mon, 02 Nov 2026 08:24:52 +0000</lastBuildDate>
    <item>
      <title>Submitted for Your Approval</title>
      <link>https://intertwingly.net/blog/2026/01/28/Twilight-Zone.html</link>
      <description>The blog demo was a real Rails application running full stack in your browser. Action Cable over BroadcastChannel. Active Record over IndexedDB. The editor runs on WebContainers — Node.js and npm, entirely in browser memory. The same patterns, the same code structure, no server.&#xA;&#xA;What originally motivated this is now child&#39;s play to build. I want judges to be able to record scores during an event despite unreliable Wi-Fi. Downloading the agenda and that judge&#39;s scores entered to date and then running the existing ERB views over IndexedDB just works. Posting updates in real time when possible and batch when connectivity resumes is straightforward. Since each judge records their own scores, there are no merge conflicts. Mount the resulting offline SPA via Rack middleware, and everything works transparently.&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #localfirst #rails #webdev&lt;/p&gt;</description>
      <pubDate>Wed, 28 Jan 2026 23:49:27 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:38260</guid>
      <category>localfirst</category>
      <category>rails</category>
      <category>webdev</category>
    </item>
    <item>
      <title>LLM APIs are a Synchronization Problem | Armin Ronacher&#39;s Thoughts and Writings</title>
      <link>https://lucumr.pocoo.org/2025/11/22/llm-apis/</link>
      <description>There’s a whole ecosystem that has dealt with this kind of mess before: the local-first movement. Those folks spent a decade figuring out how to synchronize distributed state across clients and servers that don’t trust each other, drop offline, fork, merge, and heal. Peer-to-peer sync, and conflict-free replicated storage engines all exist because “shared state but with gaps and divergence” is a hard problem that nobody could solve with naive message passing. Their architectures explicitly separate canonical state, derived state, and transport mechanics — exactly the kind of separation missing from most LLM APIs today.&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #ai #genai #llms #localfirst #sync&lt;/p&gt;</description>
      <pubDate>Sun, 23 Nov 2025 20:49:38 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:38022</guid>
      <category>ai</category>
      <category>genai</category>
      <category>llms</category>
      <category>localfirst</category>
      <category>sync</category>
      <enclosure url="https://links.lmorchard.com/static/5788a2c287fdce28a3b9be5d264a0e68.png" type="image/png"></enclosure>
    </item>
    <item>
      <title>File over app — Steph Ango</title>
      <link>https://stephango.com/file-over-app</link>
      <description>File over app is a philosophy: if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read. Use tools that give you this freedom.&#xA;&#xA;File over app is an appeal to tool makers: accept that all software is ephemeral, and give people ownership over their data.&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #apps #data #fileoverapp #freedom #localfirst #tools&lt;/p&gt;</description>
      <pubDate>Wed, 24 Sep 2025 21:44:32 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:37751</guid>
      <category>apps</category>
      <category>data</category>
      <category>fileoverapp</category>
      <category>freedom</category>
      <category>localfirst</category>
      <category>tools</category>
      <enclosure url="https://links.lmorchard.com/static/20d288eb47779c4f1b3f36fb86aa7108.png" type="image/png"></enclosure>
    </item>
    <item>
      <title>Learn Yjs by Jamsocket</title>
      <link>https://learn.yjs.dev/</link>
      <description>Learn Yjs starts with the basics of Yjs, then covers techniques for handling state in distributed applications. We’ll talk about what a CRDT is, and why you’d want to use one. We’ll get into some of the pitfalls that make collaborative applications difficult and show how you can avoid them. There will be explorable demos and code exercises so you can get a feel for how Yjs really works.&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #crdt #dev #localfirst #yjs&lt;/p&gt;</description>
      <pubDate>Tue, 21 Jan 2025 18:41:58 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:29703</guid>
      <category>crdt</category>
      <category>dev</category>
      <category>localfirst</category>
      <category>yjs</category>
      <enclosure url="https://links.lmorchard.com/static/5e944f1af261f61443bd02f45395e7f6.png" type="image/png"></enclosure>
    </item>
  </channel>
</rss>
