<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Worm on Momo Engineering Journal</title><link>/tags/worm/</link><description>Recent content in Worm on Momo Engineering Journal</description><image><title>Momo Engineering Journal</title><url>/images/og-image.png</url><link>/images/og-image.png</link></image><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 28 Oct 2026 17:47:15 -0600</lastBuildDate><atom:link href="/tags/worm/index.xml" rel="self" type="application/rss+xml"/><item><title>R10 Phase 4: S3 Object Lock — WORM That Actually Refuses Deletes</title><link>/posts/060-r10-object-lock/</link><pubDate>Wed, 28 Oct 2026 12:00:00 +0000</pubDate><guid>/posts/060-r10-object-lock/</guid><description>Object Lock is the S3 feature regulated workloads ask for first: write-once-read-many retention that the storage server itself enforces, not a policy the client promises to honor. This phase gives momo bucket-level lock enablement at creation, per-version retention and legal holds, and a delete path that answers 403 instead of quietly removing bytes. Teaches: how COMPLIANCE and GOVERNANCE differ in who can override them, why lock state must live beside the version record rather than inside object metadata, and which parts of AWS&amp;rsquo;s surface momo deliberately does not pretend to implement.</description></item></channel></rss>