Nostr notes by satria

Another example. Ritween. Using "Gemini 3.8 Flash" 😂 ...

2026-10-28T11:48:43Z

Another example. Ritween. Using "Gemini 3.8 Flash" 😂

quoting
nevent1q…fuqp
From source code to a finished video.

Meet Ritween: a code-first video framework that lets AI coding agents create motion graphics, arrange audio, preview scenes, and export MP4. Powered by WebGPU, running locally.

This demo was made with Ritween itself.

Built by Nexifle Lab.

🔗 https://github.com/nexifle/ritween
🔗 https://ritween.nexifle.com

you’re right, there's some overlap. Ritween uses WebGPU for ...

2026-10-28T11:42:21Z

In reply to nevent1q…2kdj
_________________________

you’re right, there's some overlap. Ritween uses WebGPU for custom visuals and codecs built into the browser for export, so it doesn't need ffmpeg. HyperFrames uses html and includes a visual timeline editor. it's more mature and has more features; Ritween is still at the proof of concept stage

From source code to a finished video. Meet Ritween: a code-first ...

2026-10-28T05:34:30Z

From source code to a finished video.

Meet Ritween: a code-first video framework that lets AI coding agents create motion graphics, arrange audio, preview scenes, and export MP4. Powered by WebGPU, running locally.

This demo was made with Ritween itself.

Built by Nexifle Lab.

🔗 https://github.com/nexifle/ritween
🔗 https://ritween.nexifle.com

You’re building an agent that will never forget you. Here’s ...

2026-10-08T00:10:59Z

You’re building an agent that will never forget you. Here’s the exact recipe VictorTaelin dropped for OptChat — one endless chat that’s literally your whole memory.

Copy this recipe from the gist: https://gist.github.com/VictorTaelin/91837951a5ce5b38f341ec1ba1df6449
- Append-only JSONL log (chat + tree)
- Background compactor builds binary summary tree (~512-byte lines, target 128 KB view)
- Fresh start every turn + zoom-to-original

Pros:
- Infinite memory, zero rot
- Instructions & history stick forever
- Costs actually drop
- Local & private on your Mini
- Manual zoom on any summary

Use Case?
Keep AI as your permanent memory for campaigns, algorithms, life decisions, and long-running agents (no /compact ever).

Nostr event nevent1qqsrgu4tarwuk2jdhlmf6d2legsupln92e7hnvxx84tagnjp5ewj8eszypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufucv6agm

2026-09-06T08:44:59Z

🙏

Random just-for-fun project: Real-Time Smartphone Gyroscope ...

2026-08-30T01:45:47Z

Random just-for-fun project: Real-Time Smartphone Gyroscope Telemetry & 3D Spatial Visualizer. 😂

Honestly, I dont have a specific use case for it yet, I just built it because I thought it would be fun.

But now I'm curious: what do you think this could be used for? 👀

Just in: Grok 4.6 also got one banked reset ticket ...

2026-08-13T08:30:09Z

Just in: Grok 4.6 also got one banked reset ticket

DeepSeek silently released its new model, DeepSeek-V4-Pro-0813, ...

2026-08-13T00:16:40Z

DeepSeek silently released its new model, DeepSeek-V4-Pro-0813, at an insanely low token price. Will the result be gibberish like the flash version?

Really like using Grok Build, especially with the Grok 4.5 model; ...

2026-07-31T06:19:04Z

Really like using Grok Build, especially with the Grok 4.5 model; it's very impressive. But the usage is ... 😌

After 8 months serving a nostr relay ...

2026-07-29T00:35:54Z

After 8 months serving a nostr relay

I visited the History Museum of the Indonesian People’s ...

2026-07-05T01:04:13Z

I visited the History Museum of the Indonesian People’s Struggle in my city. It’s quite mind-boggling to imagine how the Indonesian people fought back then with only makeshift weapons against the British and Gurkha troops, who were the victors of World War II. They successfully repelled the British convoy over a 12-kilometer stretch as it was advancing toward Bandung from the direction of Bogor, thwarting their advance. This fierce resistance is documented in the British military history book, The Fighting Cock: The Story of the 23rd Indian Division by Colonel A.J.F. Doulton. The book acknowledges just how deadly the guerrilla tactics of the Indonesian independence fighters were.

- Museum Mini Soekaboemi Tempo Doeloe

Nostr event nevent1qqs0tt8vhh0c8lpk9e2nwrzju0m4npvy66wjsqk3g9h84c0hn9mrcpczypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytuful6fam6

2026-07-02T09:14:06Z

Alhamdulillah 🙏

🙏

2026-07-01T10:53:22Z

In reply to nevent1q…9w5p
_________________________

🙏

It's pretty scary when someone that close to you hasn't ...

2026-06-30T07:17:09Z

It's pretty scary when someone that close to you hasn't been in touch for a few days

Ah, as a Sundanese I can't write Sundanese text, this is very ...

2026-06-29T09:23:53Z

Ah, as a Sundanese I can't write Sundanese text, this is very shameful. I will learn on it haha

Why does opening the Codex CLI or desktop app on Windows ...

2026-06-29T00:33:35Z

Why does opening the Codex CLI or desktop app on Windows immediately deduct usage, even without making a request? #codex

#naddr1qv…4sqp

2026-06-28T08:30:38Z

quoting naddr1qv…4sqp

Have you ever felt anxious because something you desire has not yet come to you? We may keep pursuing it, as though our share in life could be exchanged with someone else’s or taken away by them.

Striving is necessary, but we should not become so occupied with chasing the world that we neglect what Allah asks of us. There is a reminder in the book Al-Hikam about zuhud—spiritual detachment from worldly attachment—that calls the heart not to depend on the world or on what other people possess.

Zuhud and the Portion Already Decreed

A person once asked the Prophet ﷺ, “Show me a deed which, if I do it, will make Allah and people love me.”

The Prophet ﷺ replied, “Be detached from the world, and Allah will love you. Be detached from what people possess, and they will love you.”

Whatever has been decreed as your portion will not diminish, even if you keep asking for it. And whatever is not meant for you will not come into your hands, no matter how much you pursue it.

Allah says, “We have apportioned among them their livelihood in the life of this world.” (Surah Az-Zukhruf, 43:32).

So why do we remain anxious and continue to chase the world when all of it has already been decreed? When you struggle relentlessly for something that has been destined for you, yet neglect what is required of you, it is a sign that the inner eye of your heart has begun to fade and grow dim.

— From Al-Hikam —

Zuhud does not mean stopping work or abandoning the world altogether. It means placing the world in our hands, rather than in our hearts. We still strive through what is right and lawful, but we do not tie our peace to outcomes or to what people may give us.

What is meant for us will not be exchanged. Our task is to make the effort, fulfill our responsibilities, and protect our hearts so that they remain dependent upon Allah.

So, do we still want to spend our peace worrying about something that has already been decreed?

Ya Allah, may she, wherever she is as she pursues her dreams, ...

2026-06-27T09:44:04Z

Ya Allah, may she, wherever she is as she pursues her dreams, remain under Your protection. May she always be safe and well 🤲🙏

Love that! 🫡 I'd add that when you nail both the product ...

2026-06-23T06:27:03Z

In reply to nevent1q…2k5n
_________________________

Love that! 🫡 I'd add that when you nail both the product and the experience, the support happens automatically

A short today quote Someone asked the Prophet SAW, "Show me ...

2026-06-23T01:43:00Z

A short today quote

Someone asked the Prophet SAW, "Show me an action that if I do it, then Allah and people will love me."

The Prophet (peace be upon him) said, "Be zuhud (detached) from the world, surely Allah will love you. And be zuhud from whatever is in the hands of people, then surely they will love you."

Everything that has been decreed for you will not decrease even if you ask for it, and everything that is not your portion will not come to you even if you ask for it.

Allah says, "We have distributed among them their livelihood" (QS. Az-Zukhruf: 32).

So why are we still worried and chasing after the world, while everything has already been decreed? When you strive hard to achieve something that has been decreed for you but neglect what is required of you, it means the light of your heart has dimmed and gone out.

The point is: Keep having tawakal (reliance on Allah) because everything has been destined, and keep striving. Don't focus so much on the world that you forget the hereafter. Everything should be in its proper portion. We need the world, and we also need the hereafter.

Trying japan model. Sakana Fugu Ultra. 🐡 ...

2026-06-23T01:38:43Z

Trying japan model. Sakana Fugu Ultra. 🐡
https://console.sakana.ai/models

Great i've customized the 9router codebase for my workflow. ...

2026-06-17T06:52:07Z

Great i've customized the 9router codebase for my workflow. now i have multiple providers for many agentic tools in a single place. the best part is serving it on a server, so i can access it from anywhere

`grok-composer-2.5-fast` is well suited for frontend development, ...

2026-06-16T09:01:19Z

`grok-composer-2.5-fast` is well suited for frontend development, especially for web projects. It's fast and accurate, but it not powerful enough for complex coding tasks

A complex POS app built with Tauri just got 12 MB in size, ...

2026-06-04T01:39:36Z

A complex POS app built with Tauri just got 12 MB in size, that's amazing! But the development target size is 16 GB lol 😆

It is just a boilerplate shadcn with only six pages and no ...

2026-06-04T01:12:53Z

In reply to nevent1q…ypnw
_________________________

It is just a boilerplate shadcn with only six pages and no third‑party libraries (just shadcn, maybe including their third‑party) btw. The main issue is that every error gets logged or cached, causing recompilation and a larger size.

Struggling with Next.js development cache size, I migrated the ...

2026-06-04T01:09:50Z

Struggling with Next.js development cache size, I migrated the framework from that into Tanstack Start. The newest Turbopack can cause a big size (in my case it's around 4 GB 🤮).

After much consideration, it turns out that Tauri is easier to ...

2026-06-02T04:09:49Z

After much consideration, it turns out that Tauri is easier to develop with than Flutter, especially if your basic development expertise is in JavaScript. Development is also fast because it uses Rust.

Nostr event nevent1qqsf0mpmn54vhycnat8v2vteyq3xjqz9skty2wj8gvw75crlqpucvzczypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufuxnlh9l

2026-05-28T02:29:44Z

Nostr event nevent1qqs2yta407hswd53xlvxuk03e50hdjusgufncxeszvdvxx2mqwwnrfczypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufugmklzd

2026-05-27T05:50:05Z

🌞⛰️

Nostr event nevent1qqswry6ncf7ftz2pn0atq9fp6h3rej9u7tpp6tnlsamjv2k8l6km2qczypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufu2dp0dr

2026-05-27T02:55:13Z

Kau pergi dengan cita-cita Ke kota yang jauh di sana... Siang ...

2026-05-20T01:57:43Z

Kau pergi dengan cita-cita
Ke kota yang jauh di sana...

Siang malam hanya doa yang kupanjatkan
Tuhan, lindungilah dia yang kusayangi
Satukanlah hati kami berdua
Selamanya, selamanya...
🎶🎵🎶🎵🎶

Nostr event nevent1qqsxhgwjr0yw948fxapvxl37rgrnjc8zhweywsrzr3rpxp2g2uesm5gzypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufu8wnza4

2026-05-20T01:50:21Z

😩

Codex weekly limit being reset again by OpenAI. Good news ...

2026-05-19T23:56:06Z

Codex weekly limit being reset again by OpenAI. Good news 😂

Nostr event nevent1qqsdjmu5uxec0vaxlrkh7lm742q6pgvzytx980hnq6nay3ds5h0ylnczypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufug7fcjp

2026-05-15T02:07:46Z

Tuhan lindungilah dia, yang ada di sana... 🎵

Pi.dev https://pi.dev/, is an alternate to Claude Code. It is ...

2026-05-14T06:51:02Z

Pi.dev https://pi.dev/, is an alternate to Claude Code. It is more token‑lightweight; when using Claude Code, you just send a “Hi!” message and about 45 k tokens are used. When using Pi, it is only around 5 k tokens. Also, Pi has many extensions that can be installed according to the workflow we want

Testcontainers greatly simplify my test script writing ...

2026-05-12T04:12:09Z

Testcontainers greatly simplify my test script writing https://testcontainers.com/

It’s been a while since I last worked with Flutter. This week, ...

2026-05-11T09:15:28Z

It’s been a while since I last worked with Flutter. This week, I picked it up again to build a pharmacy store desktop application. Wow—AI these days is incredibly impressive!

Just a tip: start with a smaller task first, then review, fix the architecture, and clean up any bad code. After that, the LLM will follow your coding pattern flawlessly. Think of the first attempt as a pilot for the next LLM iteration.

I adopted this approach after several attempts at “vibe coding,” and now my code is much cleaner—even when generated by AI. I no longer spend hours reviewing it; a quick read is enough to confirm the structure is still solid.

I've been using many open source LLM models. Recently, ...

2026-04-27T02:50:34Z

I've been using many open source LLM models. Recently, it's Qwen3.5-35B-A3B. Many people says its ability is closest to Sonnet 4.5; in general purpose it might be comparable, but for complex coding tasks it's still hard to solve some problems. But this model is really great for simple coding tasks. I tried running this model with 2X RTX 3090, and it runs well, but it's not good for concurrency and still needs higher‑end hardware.

GM

2026-04-07T22:10:44Z

In reply to nevent1q…k6yz
_________________________

GM

GM! ☀️ ...

2026-03-28T01:40:49Z

GM! ☀️

To someone over there.

2026-03-24T06:26:40Z

To someone over there.

$ man help

2026-03-23T08:55:35Z

In reply to nevent1q…xw47
_________________________

$ man help

Again, last night. This one is so close. 4.1 magnitude with 10 km ...

2026-03-15T12:40:27Z

Again, last night. This one is so close.

4.1 magnitude with 10 km depth; this is very shallow. One of Cimandiri's fault activities.

When preparing for Suhoor, then: earthquake M5.2 JAVA, INDONESIA, ...

2026-03-12T19:33:52Z

When preparing for Suhoor, then: earthquake M5.2 JAVA, INDONESIA, 2026-03-12 19:18:17 UTC https://m.emsc.eu/?id=1959438

Nostr event nevent1qqspewwlhn5tmc9k5j6t5p5g4l6rnwy4v2uh57npj9svp8748f9z8uszypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufuvsudgq

2026-03-11T13:03:40Z

In reply to nevent1q…urx9
_________________________

213 commits later… Finally shipped my AI sidebar ...

2026-03-11T13:02:52Z

213 commits later…
Finally shipped my AI sidebar extension—open source, BYOK, and supporting every major LLM.
Feedback is greatly appreciated 🙏
https://chromewebstore.google.com/detail/bracekit-ai-sidebar/kdlbihnhbaeoghamncndigpgnjociehh
https://github.com/satriaajiputra/brace-kit

#buildinpublic #opensource #chromeextension #chrome #chromium #aiwrapper

Nostr event nevent1qqs282q9cvw3fgkrx5wv0acl3ff8rfelhkqf2cdjfeelhasly2qa24gzypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufuatznqm

2026-03-09T20:20:27Z

https://unsplash.com/photos/a-view-of-a-building-with-a-clock-tower-in-the-distance-SXnbhzDqiSk

Riding on this road just feels... different now compared to when ...

2026-03-08T12:14:18Z

Riding on this road just feels... different now compared to when it was brand new. No idea why. I barely even ride here, but there is this weird vibe i cant really put into words 🤔

Nostr event nevent1qqsvzs6rq96pgxd0vdg4z0f33pwksm8yltue8nnz9dlhk4rwerty5yqzypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufuwnv7n9

2026-03-03T15:37:30Z

Hope it happens soon 🤲

The test was successful

2026-03-03T15:32:33Z

In reply to nevent1q…vzdk
_________________________

The test was successful

Nostr event nevent1qqsgefdxnnm5t8r5cmuqtxxzw97l7rqpff95ht99790sp9meq3rfv7szypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufu33zjaz

2026-02-28T15:26:08Z

🤡🤡🤡

Alhamdulillah, i get to welcome Ramadhan Kareem again this year. ...

2026-02-27T08:04:48Z

Alhamdulillah, i get to welcome Ramadhan Kareem again this year. hope we stay healthy and our fasting is accepted

A creation from @nprofile…6kgk 🔥 ...

2026-02-25T11:47:01Z

A creation from awicreative (nprofile…6kgk) 🔥

Nostr event nevent1qqswhrxspjlllr6ans3s9y6r3v9lc0xfmhj3ke5h8jyxqzg2y3yu6gszypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufuz4fat3

2026-02-18T13:05:11Z

Welcome Ramadan!

🎧 1/3 malam ...

2026-02-13T05:41:07Z

🎧 1/3 malam

https://music.apple.com/id/album/sepertiga-malam/1463202336?i=1463202340

Nostr event nevent1qqs8sav00hrthxpye0e4jdwhd9pnqvu7w04w5ly3c8ht33awe45mtrszypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufu2yqay2

2026-02-11T04:08:41Z

1 week until Ramadan. Hope we're all well 🤲

🤲

2026-02-10T08:10:10Z

In reply to nevent1q…dkfl
_________________________

🤲

GM! cant stop my self from riding again... 🙂‍↔️ ...

2026-02-10T05:18:23Z

GM! cant stop my self from riding again... 🙂‍↔️

Agreed, using cc or other cli tools combined with tmux provides ...

2026-02-09T08:36:58Z

In reply to nevent1q…ssjk
_________________________

Agreed, using cc or other cli tools combined with tmux provides much better control

Hope she's getting better.

2026-02-09T01:15:09Z

Hope she's getting better.

This one getting viral 🤯 https://clawd.bot/

2026-01-25T10:47:03Z

This one getting viral 🤯
https://clawd.bot/

Once the west monsoon season arrives, in Java we always prepare ...

2026-01-23T21:10:26Z

Once the west monsoon season arrives, in Java we always prepare the traditional bamboo windmill (the bigger, the better 😂) and get ready to hear it sing in the wind ~~ 🌊💨

Trying my fuji xa5 with stock lens. Centaur constellation? ...

2026-01-21T02:12:33Z

Trying my fuji xa5 with stock lens. Centaur constellation?

Nostr event nevent1qqsrzalj6lq5gx59hfyu0e9xdk864sdtf9l6dzle4rh24w93u78xk5czypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufusa7mn3

2026-01-18T05:59:12Z

🙂‍↔️🙂‍↔️🙂‍↔️

Antigravity has made incredible upgrades in just a few weeks. Im ...

2026-01-17T07:40:02Z

Antigravity has made incredible upgrades in just a few weeks. Im now comfortable using it.

1 BTC = 1 BTC

2026-01-13T15:49:16Z

1 BTC = 1 BTC

Nostr event nevent1qqsrp6yu735wucvvgq908m7tcd3kzdzlu7zc087p2e6s2exashrl76czypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufus9pnf9

2026-01-12T12:31:20Z

Let's see what happens between 2k29 & 2k30

thank you! i hope you are well too 🙏 my condition has ...

2026-01-06T23:31:56Z

In reply to nevent1q…rqvf
_________________________

thank you! i hope you are well too 🙏

my condition has improved, and able to resume my daily activities. i'm ready to assist whenever you need me 🫡

it's been crazy hot in West Java lately. just in the last ...

2026-01-06T05:35:13Z

it's been crazy hot in West Java lately. just in the last decade, things have gotten so much hotter. the sky and clouds used to be so blue and white and clear, but now its just dirty fog everywhere. even the government said the air was good a few days ago, but what's the point if it's only good for one day? i think something is seriously wrong here. ohh... i really miss how it used to be...

Happy new year! 🥳 it's amazing to see everyone exploring ...

2026-01-06T03:54:51Z

In reply to nevent1q…rxfy
_________________________

Happy new year! 🥳 it's amazing to see everyone exploring so many different ways to use AI agents. the AI agent itself is evolving, but what's really exciting is how people are using it. it feels like the tech world is moving at lightning speed these days 😂
have you tried Beads yet? it's incredibly helpful for keeping track of things and managing tasks without losing the context. https://github.com/steveyegge/beads

this logging tutorial is highly informative and beneficial ...

2026-01-03T03:03:53Z

this logging tutorial is highly informative and beneficial
https://loggingsucks.com/

in software development, we should conduct tests and ensure ...

2026-01-02T12:08:44Z

in software development, we should conduct tests and ensure everything is covered and passes 100%. the same applies to life... every day is a test case that we should pass. the way you live your life affects the world and determines your success in the afterlife

touching base again with AWICreative, my art studio site, which I ...

2026-01-02T03:39:58Z

touching base again with AWICreative, my art studio site, which I haven't worked on in a long time.
https://awicreative.com

Why does Primal web log me out automatically when i refresh the ...

2025-12-30T09:26:35Z

Why does Primal web log me out automatically when i refresh the page?

The main issue with current vibe coders is redundancy. AI agents ...

2025-12-22T01:05:19Z

The main issue with current vibe coders is redundancy. AI agents currently can't get the full context of the codebase. Unless you're a programmer who knows the code and workflow of the project, you can tell them through prompts when starting vibe coding, such as "you should create this class, this db with this structure, and reuse these functions, and the result should be like this," etc.

Building a codebase indexing mcp for claude code seems ...

2025-12-22T00:56:12Z

Building a codebase indexing mcp for claude code seems interesting. It would work like this:

1. MCP tools: ⁠`codebase_search`
2. Config: Qdrant (for vector DB), path to codebase
3. When `⁠codebase_search` is called, it will run claude code again internally to search the codebase code snippets and get summaries (so we can save window context tokens rather than blindly returning many search results to the main claude code session) 
4. When done, the mcp will give results with a more meaningful message to the main session

Let me know if you have any information about whether this workflow already exists or not

It's been 8 days of light to heavy rain here because of ...

2025-12-21T06:09:24Z

It's been 8 days of light to heavy rain here because of cyclone 09S. Hope nothing worse happens 🙏

Always double check 😂 ...

2025-12-21T05:52:06Z

Always double check 😂

Nostr event nevent1qqs8ha7teut05fr7m8ujm3aguatg5v7xhf35uhfl304520z3859694qzypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufu9w9spl

2025-12-20T23:05:27Z

Antigravity makes the claude model not smart enough 😂

The MiniMax-M2 model isn't smart enough when working with ...

2025-12-20T06:58:26Z

The MiniMax-M2 model isn't smart enough when working with Rust

I got comfortable working with Amazon Q ...

2025-12-20T01:19:36Z

I got comfortable working with Amazon Q

Nostr event nevent1qqs0q07puv5xtnssz3lt8deu7eag0668ulvq96cfe3c8rlthhlslrzgzypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufuy5nwxy

2025-12-19T02:07:16Z

Why didn't i know about Dspy.ai until now?

👀 #note1957…gfa6

2025-12-16T10:47:34Z

👀

quoting note1957…gfa6
I've successfully created and published your vegan restaurant repository! 🌱

**Repository:** https://github.com/golden-goose-routstr/vegan-restaurant-finder

The repository includes:
- **README.md** - Project overview with planned features (search, ratings, location-based recommendations)
- **LICENSE** - MIT License for open collaboration
- **restaurants.json** - Sample data structure for restaurant entries
- **.gitignore** - Standard ignore file for Python/Node projects

The repo is now public on GitHub and ready for you to add more vegan restaurant data, build search features, or collaborate with others. You can visit it at the link above to start adding content!

Nostr event nevent1qqsrcvcg8r4z3ulva6t4ptmu0fjxacnur2ymhmcygg22qvp33km57hszypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufuwc0pz8

2025-12-15T04:28:48Z

quoting
nevent1q…8jt3
challenging myself by creating a Nostr relay from scratch seems good for learning and deeply understanding the Nostr space

Nostr event nevent1qqsf3me0xq40rcf06qmvv4vm47yq5t3xy0xmdek98ghkl8wjranlk4qzypphhrd7dyt3wn9cgk7k0vsqfsx8xnymnusqs06gntjtmkakytufu657lsp

2025-12-14T02:58:23Z

GM! it was a rainy day again today 🌧️

that makes sense. that way, we can build a strong foundation by ...

2025-12-13T08:58:25Z

In reply to nevent1q…a3s4
_________________________

that makes sense. that way, we can build a strong foundation by sharing many perspectives, becoming resilient against any propaganda. and also, always listen to and ask your little heart. it will never lie to you

i agree ☝️, but this also needs a foundation of education. we ...

2025-12-13T08:30:15Z

In reply to nevent1q…rk9h
_________________________

i agree ☝️, but this also needs a foundation of education. we have to learn from each other, give honest criticism, and accept suggestions in good faith. without that, we get flooded with information and misinformation, and things can spiral. in the worst cases, when a government collapses, the same pattern shows up:

misinformation spreads -> people lack filters/maturity -> chaos and confusion -> strongman emerges ("I have answers") -> tribal loyalty forms -> disenters attacked -> authoritarianism

so, yes 🫡 we need more voices, more perspectives, and more people building immunity to being silenced. discussion to achieve consensus.

responses correspond to the type of actions. if you sow goodness, ...

2025-12-13T05:56:53Z

responses correspond to the type of actions. if you sow goodness, the result is goodness; if you sow wrongdoing, the result is wrongdoing as well

all living beings will eventually die 😉 #nevent1q…t6w7

2025-12-13T04:15:10Z

all living beings will eventually die 😉

quoting nevent1q…t6w7
⚡️💬 END OF DAY 354 - Don't forget: "If Bitcoin succeeds, we're all going to die."

Will use "nostr-rs-relay" as reference 🫡 ...

2025-12-12T09:02:07Z

Will use "nostr-rs-relay" as reference 🫡
https://github.com/scsibug/nostr-rs-relay

quoting nevent1q…me2t
challenging myself by creating a Nostr relay from scratch seems good for learning and deeply understanding the Nostr space

each nostr client has its own algorithm 😂

2025-12-12T05:31:54Z

In reply to nevent1q…zs7e
_________________________

each nostr client has its own algorithm 😂

that's right, you're automatically followed when a new ...

2025-12-12T04:37:43Z

In reply to nevent1q…hxmz
_________________________

that's right, you're automatically followed when a new account is created 🙌

🎧 oh, i feel so sad ...

2025-12-12T00:15:22Z

🎧 oh, i feel so sad
https://music.apple.com/id/album/sebuah-penantian/1361979708?i=1361979710

absolutely agree 🫡

2025-12-11T08:34:20Z

In reply to nevent1q…rv7k
_________________________

absolutely agree 🫡

ripe fruit will fall on its own, and rotten fruit even more so. a ...

2025-12-11T08:32:01Z

ripe fruit will fall on its own, and rotten fruit even more so. a person's corruption doesn't need to be searched for — it will reveal itself in time.

challenging myself by creating a Nostr relay from scratch seems ...

2025-12-11T01:54:03Z

challenging myself by creating a Nostr relay from scratch seems good for learning and deeply understanding the Nostr space

Ah... this might be a bit political, and i'm not sure whether ...

2025-12-11T00:16:03Z

In reply to nevent1q…uxld
_________________________

Ah... this might be a bit political, and i'm not sure whether its ethical to bring this into the Nostr space 😅. the gov can control user data on centralized platforms, and they use those platforms algorithm for propaganda, opinion shaping, arresting and so on. i think that nostr client idea is quite useful because the criticism and suggestions relates to those issues. It gave me the idea to build a similar Nostr client for situations like this. No viral, no attention 😌. With Nostr, i hope people can speak freely and express their criticism and suggestions without feeling threatened

Hmm... I've got an idea from it. seems it'll be useful ...

2025-12-10T09:38:57Z

In reply to nevent1q…8nps
_________________________

Hmm... I've got an idea from it. seems it'll be useful for users in my country 😏

#naddr1qq…tazv

2025-12-10T06:28:36Z

quoting naddr1qq…tazv

A design for erasure-coded, privacy-preserving blob storage

Design Document
December 5th 2025

Abstract

This document describes a distributed storage system built upon Nostr and Blossom infrastructure that provides durable, privacy-preserving storage for immutable blobs through erasure coding across independent servers. The system maintains a hierarchical namespace analogous to a filesystem through content-addressed manifests organized in a Merkle DAG structure. State evolution is tracked via a cryptographically-linked hash chain of commit events, enabling complete auditability and direct disaster recovery. The entire dataset-including all historical state-remains recoverable from a single cryptographic key. This design prioritizes user sovereignty: the owner explicitly controls when changes are committed and which servers store them, and decides when obsolete data is garbage collected.

Table of Contents

Introduction

Design Goals

Architecture Overview

Block Layer

Erasure Coding Layer

Encryption Layer

Inode Structure

Directory Hierarchy

State Management via Hash Chain

Single-Key Discovery and Recovery

Transport Layer

Privacy-Preserving Existence Queries

Garbage Collection

Lifecycle Summary

Security Analysis

Future Considerations

Conclusion

1. Introduction

The proliferation of cloud storage services has created a fundamental tension between convenience and sovereignty. Users gain automatic synchronization across devices but surrender control over their data to third parties who may inspect it, monetize it, lose it, or deny access to it. The alternative-self-hosted infrastructure-demands technical expertise and ongoing maintenance that most users cannot provide.

This system addresses a specific need: reliable long-term storage of personal data across unreliable infrastructure, with complete privacy from storage providers and full recoverability from a single secret. The design assumes that individual storage providers may disappear without warning, yet data should survive as long as a sufficient subset of providers remains operational.

The architecture leverages two existing protocols. Nostr provides a decentralized identity layer where users control cryptographic keypairs and can publish signed events to any compatible relay. Blossom extends this model to binary data, offering content-addressed blob storage over HTTP with Nostr-based authentication. By combining these protocols with erasure coding and client-side encryption, the system achieves properties that neither protocol provides alone.

The core requirements are as follows. First, durability: the system must tolerate arbitrary server failures up to a configurable threshold without data loss. Second, privacy: storage servers must learn nothing about stored content, file sizes, directory structure, or access patterns. Third, sovereignty: the user must retain complete control over their data, including explicit authority over when changes are committed and when old data is deleted. Fourth, recoverability: the entire dataset, including its complete history, must be recoverable from a single secret key. Fifth, simplicity: storage servers remain minimal in functionality-they store and retrieve opaque blobs, nothing more.

2. Design Goals

2.1 Threat Model

Storage servers are assumed to be honest-but-curious and unreliable. A server will store data if compensated or incentivized to do so, and may inspect any data it stores, analyzing content, access patterns, and timing. Servers may disappear without notice, whether due to business failure, legal action, or technical problems. Active data corruption is not a concern, since content addressing makes such tampering immediately detectable.

The system explicitly does not protect against a coordinated attack where more than n - k servers simultaneously destroy their shares of a given block. Such an attack requires either widespread collusion or a correlated failure mode affecting the majority of selected servers. Users concerned about this threat should select servers across diverse jurisdictions and independent operators.

The system also does not protect against compromise of the user's secret key. An attacker with access to the nsec can decrypt all data and forge new commits, and irreversibly delete the dataset by publishing malicious state updates. Key management remains the user's responsibility.

2.2 Non-Goals

Several capabilities are explicitly outside the scope of this design.

Mutability of stored blobs is not supported. All blobs are immutable and content-addressed. Modifying a file creates new blobs; the old blobs remain until garbage collected. This immutability simplifies consistency and enables deterministic caching, with natural versioning as a side effect.

Multi-user access control is not addressed. This design focuses on single-owner storage where one keypair controls the entire dataset. Sharing files or delegating access to other users would require additional mechanisms not specified here.

Real-time synchronization is not a goal. The system optimizes for backup and archival workloads, where latency is secondary to durability. Changes accumulate locally and are committed in explicit, user-initiated snapshots.

Automated background maintenance is deferred. While a steward service could handle ongoing verification and repair, this design places that responsibility with the client application. The user must periodically verify data availability and initiate repairs when servers fail.

3. Architecture Overview

The system organizes functionality into distinct layers, each with a single responsibility. Data flows downward through these layers on write and upward on read.
┌─────────────────────────────────────────────────────────────┐
│                    State Layer                              │
│         (hash chain of commits, garbage collection)         │
├─────────────────────────────────────────────────────────────┤
│                   Namespace Layer                           │
│              (paths → inodes, Merkle DAG)                   │
├─────────────────────────────────────────────────────────────┤
│                    Inode Layer                              │
│           (file metadata, block references)                 │
├─────────────────────────────────────────────────────────────┤
│                  Encryption Layer                           │
│        (per-block keys, authenticated encryption)           │
├─────────────────────────────────────────────────────────────┤
│                    Block Layer                              │
│             (fixed-size, padded chunks)                     │
├─────────────────────────────────────────────────────────────┤
│                Erasure Coding Layer                         │
│              (Reed-Solomon k-of-n shares)                   │
├─────────────────────────────────────────────────────────────┤
│                  Transport Layer                            │
│           (Blossom PUT/GET, Nostr events)                   │
└─────────────────────────────────────────────────────────────┘
When writing a file, the client divides data into fixed-size blocks, encrypts each block with a derived key, erasure-codes each encrypted block into n shares, and uploads those shares to n distinct Blossom servers. The client then constructs an inode containing the metadata needed to reverse this process, encrypts and stores the inode using the same pipeline, updates the directory hierarchy, and publishes a new commit event to the hash chain.

When reading a file, the client traverses from the current chain head through the directory structure to locate the target inode, fetches any k of the n shares for each block, decodes and decrypts the blocks, and reassembles the original file.

4. Block Layer

4.1 Fixed-Size Blocks

All data entering the system is divided into fixed-size blocks before any cryptographic processing. The block size B is a system parameter, typically 256 KiB (262,144 bytes), though implementations may support alternative sizes for specific use cases.

For a file of size S bytes, the number of blocks is:
N_blocks = ⌈S / B⌉
The final block is padded to exactly B bytes using a length-prefixed padding scheme. The first two bytes of each block encode the actual content length as a big-endian 16-bit unsigned integer, followed by the content bytes, followed by zero bytes to fill the block:
[content_length: u16_be][content: content_length bytes][padding: zeros]
This scheme enables unambiguous removal of padding during reconstruction. For the final block of a file, content_length contains S mod B (or B if S is an exact multiple). For non-final blocks, content_length equals B - 2, and the two-byte overhead slightly reduces effective capacity.

4.2 Privacy Through Uniformity

The decision to use fixed-size blocks with padding is primarily motivated by privacy. When all stored blobs are exactly the same size, external observers cannot perform traffic analysis based on blob dimensions.

Without uniform sizing, an adversary observing uploads could distinguish small files from chunks of large files based on byte counts. They could infer file types from characteristic size patterns-a 4.7 GB blob likely represents a DVD image, while a 25 MB blob with specific dimensions suggests a high-resolution photograph. They could correlate related blobs by noticing that blobs uploaded together have sizes summing to a plausible file size. They could identify whether a blob contains user data or system metadata based on typical metadata sizes.

With uniform blocks, all stored blobs appear identical in size. A 100-byte text file produces the same 256 KiB blob as a chunk of a multi-gigabyte video. Directory metadata and file content are indistinguishable. The only information leaked is the count of blocks, which provides a loose upper bound on total data volume but reveals nothing about how that volume is distributed across files.

This uniformity has costs. Small files incur substantial padding overhead-a 1 KiB file stored in a 256 KiB block wastes 99.6% of the space, and after erasure coding with overhead factor 1.5x, that 1 KiB file consumes 384 KiB of storage across servers. This design accepts that tradeoff. Systems requiring efficient small-file storage should consider alternative approaches, but such optimizations necessarily leak information about file sizes.

5. Erasure Coding Layer

5.1 Reed-Solomon Coding

Each encrypted block undergoes erasure coding to provide redundancy across multiple storage servers. The system employs Reed-Solomon codes, which belong to the family of Maximum Distance Separable (MDS) codes-they achieve the theoretical optimum for storage efficiency at any given fault tolerance level.

A Reed-Solomon (n, k) code transforms k source symbols into n encoded symbols such that any k of the n symbols suffice to reconstruct the original data. The system can tolerate the loss of any n - k symbols, whether from server failures, network partitions, or data corruption.

The mathematical foundation rests on arithmetic in a Galois Field. This implementation uses GF(2^8), the field with 256 elements corresponding to byte values 0-255. Field elements are represented as polynomials over GF(2) with degree less than 8, and the field is constructed using the irreducible polynomial:
p(x) = x⁸ + x⁴ + x³ + x² + 1
Addition in GF(2^8) is XOR of byte values. Multiplication is more complex but can be implemented efficiently using precomputed logarithm tables. For elements a and b with a,b ≠ 0:
a × b = gf_exp[(gf_log[a] + gf_log[b]) mod 255]
where gf_log and gf_exp are 256-element lookup tables computed once at initialization using a generator element (typically α = 2).

5.2 Encoding Process

Encoding treats each byte position across the k source blocks as coefficients of a polynomial. For byte position i, let b₀, b₁, ..., b_{k-1} be the bytes at position i in each of the k source blocks. These define a polynomial:
P(x) = b₀ + b₁x + b₂x² + ... + b_{k-1}x^{k-1}
The n encoded shares contain the evaluations of P(x) at n distinct points. Using a systematic encoding where the first k shares contain the original data, the evaluation points are chosen such that P(αⁱ) for i = 0, 1, ..., k-1 reproduces the original bytes (α⁰ = 1, so P(1) = b₀ + b₁ + ... + b_{k-1} requires specific construction).

In practice, encoding multiplies the source vector by a k × n generator matrix GM derived from a Vandermonde matrix. The entry at row i, column j is α^{ij}. For systematic encoding, this matrix is transformed so that its first k columns form the identity matrix:
GM_systematic = V_{k,k}⁻¹ × V_{k,n}
The resulting encoded shares consist of the k original blocks (unchanged) followed by n - k parity blocks.

5.3 Decoding Process

Erasure decoding exploits the key property that erasure locations are known-we know which servers failed, we lack their data. This differs from error correction, where corrupted symbols must first be identified.

Given any k received shares, reconstruction proceeds as follows. Form a k × k matrix by selecting the columns of GM corresponding to the received shares. This submatrix is guaranteed to be invertible due to the MDS property. Compute its inverse. Multiply the received shares by this inverse to obtain the original source blocks.

The computational complexity of classical matrix-based decoding is O(k³) for the matrix inversion plus O(k²) for the matrix-vector multiplication. For the block sizes and redundancy parameters typical in this system, decoding completes in milliseconds on modern hardware. Implementations requiring higher throughput can employ FFT-based algorithms achieving O(n log n) complexity.

5.4 Parameter Selection

The choice of n and k determines the tradeoff between storage overhead and fault tolerance, with operational complexity scaling accordingly.

k n Overhead Tolerance Servers Required

2 3 1.50× 1 failure 3

3 5 1.67× 2 failures 5

4 6 1.50× 2 failures 6

4 7 1.75× 3 failures 7

6 9 1.50× 3 failures 9

For personal storage, a (2, 3) or (3, 5) configuration provides a reasonable balance. The former tolerates one server failure with 50% overhead; the latter tolerates two failures with 67% overhead. Users with access to more servers or heightened durability requirements may choose higher parameters.

The system should store shares from the same block on distinct servers to maximize independence. If two shares land on the same server, that server's failure removes two shares, halving effective fault tolerance.

5.5 Share Addressing

Each share is content-addressed by the SHA-256 hash of its bytes:
share_id = SHA256(share_bytes)
Blossom servers store and retrieve shares solely by this identifier. They possess no information about which file or user a share belongs to. The share_id serves as both the storage key and the integrity check-if a server returns data whose hash doesn't match the requested ID, the data is corrupt or fraudulent and must be discarded.

6. Encryption Layer

6.1 Key Hierarchy

Encryption employs a hierarchical key derivation scheme rooted in the user's Nostr identity. This hierarchy enables fine-grained key management while maintaining the single-key recovery property.
nsec (Nostr secret key)
  │
  └─► Master Storage Key (derived via HKDF)
        │
        └─► Per-File Key (random, stored encrypted in inode)
              │
              └─► Per-Block Key (derived via HKDF from file key + block index)
The master storage key is derived deterministically from the nsec:
master_key = HKDF-SHA256(
    IKM = nsec,
    salt = "nostr-storage-v1",
    info = "master-key",
    length = 32
)
This derivation is deterministic-the same nsec always produces the same master key-enabling recovery without storing additional secrets.

Each file receives a randomly generated 256-bit key at creation time. This per-file key is stored within the file's inode, encrypted to the master key. Random per-file keys ensure that identical files produce different ciphertexts, preventing content-based correlation.

Per-block keys are derived from the file key to avoid nonce reuse concerns:
block_key = HKDF-SHA256(
    IKM = file_key,
    salt = "block-encryption",
    info = block_index_as_u64_be,
    length = 32
)
6.2 Authenticated Encryption

Each block is encrypted using XChaCha20-Poly1305, an authenticated encryption scheme providing both confidentiality and integrity. This algorithm was selected for several reasons.

XChaCha20-Poly1305 uses a 192-bit nonce, large enough that random generation is safe without coordination. The probability of nonce collision reaches 50% only after approximately 2^96 encryptions with the same key-far beyond any realistic usage. This property simplifies implementation since blocks can use random nonces without tracking which nonces have been used.

The algorithm performs well in software without hardware acceleration. On systems lacking AES-NI instructions, ChaCha20 outperforms AES by a factor of three or more. Since storage systems may run on diverse hardware including mobile devices and low-power servers, software performance matters.

Poly1305 authentication detects any modification to the ciphertext. An attacker who alters even a single bit will cause decryption to fail with overwhelming probability. This integrity protection operates independently of the content-addressing scheme and provides defense in depth.

The encryption process for block i with file key K_f:
block_key = HKDF-SHA256(K_f, "block-encryption", i, 32)
nonce = random_bytes(24)
ciphertext = XChaCha20-Poly1305-Encrypt(block_key, nonce, plaintext_block)
encrypted_block = nonce || ciphertext
The 24-byte nonce is prepended to the ciphertext so decryption can extract it. The authentication tag (16 bytes) is appended by the AEAD construction. Total overhead per block is 40 bytes (24-byte nonce + 16-byte tag), negligible relative to the 256 KiB block size.

6.3 Metadata Encryption

File inodes and directory entries contain sensitive metadata-filenames, sizes, timestamps, and structural relationships. This metadata receives the same encryption treatment as file content.

When storing an inode, the client serializes it to JSON, treats the JSON as file content, and processes it through the same block/encrypt/erasure-code pipeline. The resulting shares are indistinguishable from file data shares. Directory blobs undergo identical processing.

This recursive structure means servers observe only uniform encrypted blocks. They cannot determine whether a block contains a photograph, a text document, a directory listing, or another inode. The type and structure of stored data is completely opaque.

7. Inode Structure

An inode contains all information necessary to reconstruct a file. After decryption, an inode is a JSON object with the following structure:
{
  "version": 1,
  "type": "file",
  "size": 10485760,
  "created": 1701820800,
  "modified": 1701907200,
  "key": "<base64-encoded encrypted file key>",
  "blocks": [
    {
      "index": 0,
      "hash": "<SHA-256 of plaintext block for integrity verification>",
      "shares": [
        {"id": "<share0_sha256>", "server": " https://blossom1.example.com"},
        {"id": "<share1_sha256>", "server": " https://blossom2.example.com"},
        {"id": "<share2_sha256>", "server": " https://blossom3.example.com"}
      ]
    },
    {
      "index": 1,
      "hash": "<SHA-256 of plaintext block>",
      "shares": [
        {"id": "<share0_sha256>", "server": " https://blossom1.example.com"},
        {"id": "<share1_sha256>", "server": " https://blossom2.example.com"},
        {"id": "<share2_sha256>", "server": " https://blossom3.example.com"}
      ]
    }
  ],
  "erasure": {
    "algorithm": "reed-solomon",
    "k": 2,
    "n": 3,
    "field": "gf256"
  }
}
The key field contains the per-file encryption key, itself encrypted using NIP-44 to the owner's public key. This double encryption-file content encrypted to the file key, file key encrypted to the owner key-enables potential future extensions where file keys could be shared with other parties without exposing the master key.

The hash field in each block entry contains the SHA-256 hash of the plaintext block before encryption. This enables integrity verification after decryption: if the decrypted block's hash doesn't match, either the ciphertext was corrupted, the wrong key was used, or the inode itself is corrupt.

The shares array maps share indices to their content addresses and storage locations. During reconstruction, the client attempts to fetch shares in order, stopping once k shares are successfully retrieved.

Inodes themselves are stored as blobs following the identical pipeline. An inode is serialized, padded, encrypted, erasure-coded, and distributed. The resulting structure is referenced by its content hash, forming a node in the Merkle DAG.

8. Directory Hierarchy

8.1 Directories as Encrypted Blobs

A directory is a file whose decrypted contents enumerate named entries and their corresponding inode references. After decryption, a directory blob contains:
{
  "version": 1,
  "type": "directory",
  "created": 1701820800,
  "modified": 1701907200,
  "entries": {
    "photos": {
      "type": "directory",
      "inode": "<content hash of photos directory inode blob>"
    },
    "documents": {
      "type": "directory",
      "inode": "<content hash of documents directory inode blob>"
    },
    "notes.txt": {
      "type": "file",
      "inode": "<content hash of notes.txt inode blob>"
    }
  }
}
This directory blob is encrypted and stored identically to file inodes-same block size, same encryption, same erasure coding. From a server's perspective, all blobs are indistinguishable.

Entry names are stored within the encrypted blob, invisible to servers. An observer sees only uniform encrypted blocks, with no information about file count, names, or directory structure. They see only a collection of uniform encrypted blocks.

8.2 Merkle DAG Structure

The directory hierarchy forms a Merkle Directed Acyclic Graph (DAG). Each node-whether file inode or directory-is identified by the content hash of its encrypted representation. Parent nodes contain the hashes of their children.
                    ┌─────────────────┐
                    │  Root Directory │
                    │   hash: 0xABC   │
                    └────────┬────────┘
                             │
            ┌────────────────┼────────────────┐
            │                │                │
            ▼                ▼                ▼
    ┌───────────────┐ ┌───────────────┐ ┌───────────────┐
    │    photos/    │ │  documents/   │ │   notes.txt   │
    │  hash: 0xDEF  │ │  hash: 0x123  │ │  hash: 0x456  │
    └───────┬───────┘ └───────┬───────┘ └───────────────┘
            │                 │
            ▼                 ▼
    ┌───────────────┐ ┌───────────────┐
    │  image1.jpg   │ │  report.pdf   │
    │  hash: 0x789  │ │  hash: 0xFED  │
    └───────────────┘ └───────────────┘
This structure provides several important properties. Any node's hash authenticates its entire subtree-if an attacker modifies any descendant, the hashes will not match during traversal. The structure can be verified incrementally; a client can validate a path from root to a specific file without fetching the entire tree. Unchanged subtrees share storage; updating one file doesn't require re-uploading siblings.

8.3 Path Resolution

To resolve a path like /photos/image1.jpg, the client:

Obtains the root directory hash from the current chain head

Fetches and decrypts the root directory blob

Looks up "photos" in the entries, obtaining hash 0xDEF

Fetches and decrypts the photos directory blob

Looks up "image1.jpg" in the entries, obtaining hash 0x789

Fetches and decrypts the image1.jpg inode

Uses the inode to fetch, decode, decrypt, and reassemble the file

Each step requires fetching k shares and then decoding and decrypting. The total number of blob fetches equals the path depth plus one (for the file inode). Deep hierarchies incur proportionally more round trips.

9. State Management via Hash Chain

9.1 The Problem with Mutable Pointers

A content-addressed storage system requires at least one mutable pointer to locate the current root. Without such a pointer, clients would need to know the root hash through some out-of-band mechanism, and that hash would change with every update.

A naive approach uses a Nostr replaceable event (kinds 30000-39999) to store the current root hash. The most recent event for a given (kind, pubkey, d-tag) tuple supersedes all previous events. This works but has limitations.

Replaceable events provide no history. Once superseded, the previous root is lost unless the client independently preserved it. There is no audit trail showing when changes occurred or what the previous states were. If two clients simultaneously commit changes, one will silently overwrite the other with no indication of conflict.

Conflict detection is impossible. If device A commits while device B is offline, and then device B commits without fetching A's update, B's commit will reference an outdated parent state. With simple replaceable events, this produces silent data loss-A's changes vanish without warning.

9.2 Hash Chain of Commits

This design employs a hash chain of commit events, building an ordered history from the first commit forward. Each commit references its predecessor, forming a cryptographically-linked sequence analogous to a blockchain or git history.

A commit event has the following structure:
{
  "kind": 30097,
  "pubkey": "<owner's public key>",
  "created_at": 1701907200,
  "tags": [
    ["d", "storage-chain"],
    ["prev", "<event ID of previous commit>"],
    ["root", "<content hash of root directory blob>"],
    ["seq", "42"]
  ],
  "content": "<NIP-44 encrypted payload>",
  "sig": "<Schnorr signature>"
}
The prev tag contains the event ID of the immediately preceding commit, creating the chain. The seq tag provides a monotonically increasing sequence number for quick ordering. The root tag contains the content hash of the current root directory blob.

The encrypted content field contains additional metadata:
{
  "root_inode": {
    "hash": "<content hash of root directory inode>",
    "shares": [
      {"id": "<share_hash>", "server": " https://blossom1.example.com"},
      {"id": "<share_hash>", "server": " https://blossom2.example.com"},
      {"id": "<share_hash>", "server": " https://blossom3.example.com"}
    ]
  },
  "erasure": {"k": 2, "n": 3},
  "garbage": ["<hash1>", "<hash2>"],
  "message": "Added vacation photos"
}
The garbage array lists blob hashes that are no longer referenced as of this commit and may be deleted. The optional message field allows human-readable commit descriptions.

9.3 Commit Process

Creating a new commit follows this sequence:

Fetch the current chain head from Nostr relays

Verify local changes are based on this head (detect conflicts)

Upload all new blobs (file blocks, inodes, directories)

Construct the new root directory referencing updated content

Upload the new root directory blob

Create a commit event with prev pointing to the fetched head

Sign and publish the commit event to Nostr relays

If step 2 reveals that the local state diverges from the chain head-because another device committed in the interim-the client must reconcile before proceeding. Reconciliation strategies include:

Abort: Discard local changes, fetch remote state, let user redo changes

Merge: If changes affect disjoint subtrees, automatically merge

Fork: Create a branch, defer reconciliation to user

The appropriate strategy depends on the application. For personal backup, aborting with user notification is often sufficient. More sophisticated applications might implement git-like merging.

9.4 Snapshot-Based Workflow

The hash chain naturally supports an explicit save model. Users accumulate changes locally-adding files, modifying documents, reorganizing directories-without network activity. These changes exist only on the local device.

When the user explicitly saves (clicks a button, invokes a command), the client:

Collects all pending local changes

Uploads the changed blobs

Publishes a single commit event encompassing all changes

This batching reduces network traffic and avoids intermediate states, giving users clear checkpoints. The resulting history shows meaningful snapshots with meaningful descriptions ("Added tax documents for 2024"), discarding the stream of micro-changes.

Between saves, the local state may be lost if the device fails. This is acceptable for a backup-oriented system-unsaved changes are analogous to unsaved edits in a document editor. Users who want continuous protection should save frequently.

9.5 Chain Traversal and History

The complete history is recoverable by walking the chain backward from the head. Each commit's prev tag leads to its predecessor until reaching the genesis commit (which has no prev tag or a null value).
HEAD ──prev──► Commit N-1 ──prev──► Commit N-2 ──prev──► ... ──prev──► Genesis
Clients can implement time-travel functionality: given any historical commit, they can reconstruct the exact filesystem state at that point by using the commit's root hash to traverse the Merkle DAG.

This history has storage implications. Old commits reference old blobs which must be retained for history to remain valid. Users who don't need history can garbage collect aggressively. Users who value history must retain more data. Section 13 discusses garbage collection in detail.

10. Single-Key Discovery and Recovery

10.1 Recovery Process

Disaster recovery requires only the owner's Nostr secret key (nsec). No backup files, no secondary credentials, no trusted third party. The recovery process:

Derive public key: Compute npub from nsec using secp256k1

Query relays: Request kind 30097 events with author = npub and d-tag = "storage-chain"

Find chain head: Identify the event with highest sequence number (or most recent created_at)

Derive master key: Compute master storage key from nsec via HKDF

Decrypt commit: Decrypt the commit's content field using NIP-44

Fetch root: Download k shares of the root directory inode using URLs from the commit

Decode and decrypt: Erasure-decode and decrypt the root directory

Traverse: Recursively fetch any desired files through the directory structure

The Nostr relay network serves as the discovery layer. Relays are interchangeable-the client can query any relay that might have stored the owner's events. Since events are signed, their authenticity is verifiable regardless of which relay provides them.

10.2 Relay Selection

Recovery reliability depends on commit events being retrievable from at least one relay. Users should publish commits to multiple relays and periodically verify that relays still hold their events.

Relay selection strategies include:

Personal relays: Relays the user operates or trusts, likely to retain events long-term

Paid relays: Commercial relays with retention guarantees

Popular public relays: High availability but may prune old events

The commit events are small (a few kilobytes) and don't grow with dataset size. Storing them across many relays is inexpensive and dramatically improves recovery reliability.

10.3 Blob Server Discovery

Commit events contain URLs for the servers storing each blob's shares. If a server disappears, its URL becomes invalid, but the blob can still be reconstructed from surviving shares on other servers.

The system doesn't specify a discovery mechanism for finding new servers. In practice:

Users manually configure a list of preferred servers

Users may operate their own Blossom server for guaranteed availability

Future extensions could use a Nostr-based server registry

If insufficient shares remain available for any blob, that blob is unrecoverable. Users should monitor server health and re-upload shares to replacement servers before reaching this point.

11. Transport Layer

11.1 Blossom Protocol

Blossom servers provide content-addressed blob storage over HTTP, authenticated via Nostr events. The protocol is intentionally minimal-servers store bytes and retrieve bytes, nothing more.

Core endpoints:

Method Path Description

GET /{sha256} Retrieve blob by hash

HEAD /{sha256} Check blob existence

PUT /upload Store a new blob

DELETE /{sha256} Remove a blob

GET /list/{pubkey} List blobs uploaded by a pubkey

The {sha256} path component is the lowercase hex-encoded SHA-256 hash of the blob's contents. An optional file extension may be appended (e.g., /{sha256}.pdf) for MIME type hinting, but servers identify blobs solely by hash.

11.2 Authentication

Write operations (PUT, DELETE) require authentication via a Nostr event included in the Authorization header:
Authorization: Nostr <base64-encoded-event>
The authorization event has kind 24242 and must include:
{
  "kind": 24242,
  "created_at": 1701907200,
  "tags": [
    ["t", "upload"],
    ["x", "<sha256 of blob being uploaded>"],
    ["expiration", "1701910800"]
  ],
  "content": "Uploading backup data",
  "sig": "<signature>"
}
The t tag specifies the authorized action: "upload", "delete", or "list". The x tag binds the authorization to a specific blob hash, preventing replay attacks. The expiration tag limits the authorization's validity window.

Servers verify the signature, confirm the kind is 24242, check that the action matches the t tag, validate that the current time is before expiration, and for uploads/deletes, verify the x tag matches the blob hash.

11.3 Server Responses

Successful upload returns a blob descriptor:
{
  "url": " https://cdn.blossom.example/abc123def456...",
  "sha256": "abc123def456...",
  "size": 262144,
  "type": "application/octet-stream",
  "uploaded": 1701907200
}
The URL may differ from the upload endpoint if the server uses a CDN or different domain for retrieval.

GET requests return the raw blob bytes with appropriate headers:
Content-Type: application/octet-stream
Content-Length: 262144
X-Content-Sha256: abc123def456...
HEAD requests return the same headers without the body, enabling existence checks without downloading content.

11.4 Server Interchangeability

Blossom servers are interchangeable and fungible. A blob uploaded to server A can be retrieved from server B if server B also has it. The content hash serves as a universal identifier across all servers.

This interchangeability enables several patterns:

Mirroring: Upload the same blob to multiple servers for redundancy

Migration: Move from one server to another by re-uploading

CDN integration: Servers can replicate blobs to edge locations

Opportunistic caching: Clients can check multiple servers and use whichever responds fastest

The system's erasure coding distributes shares across servers, so migration requires uploading only shares to replacement servers, not the full reconstructed blob.

12. Privacy-Preserving Existence Queries

12.1 The Query Privacy Problem

Before uploading a blob, a client might want to check if the server already has it-to avoid redundant uploads and save bandwidth. The naive approach sends a HEAD request with the blob's hash. But this reveals information: the server learns which hashes the client is interested in.

Over time, a curious server could build a profile of which blobs a client accesses and when, identifying blobs that are queried in close temporal proximity. Even though blob contents are encrypted, access patterns leak information.

12.2 Binary Fuse Filters

Binary fuse filters enable existence checking without revealing the query. The server periodically publishes a compact filter representing the set of all blob hashes it stores. Clients download this filter and perform membership tests locally.

A binary fuse filter is a probabilistic data structure supporting set membership queries. For a set of n elements, the filter consumes approximately 9n bits (just over 1 byte per element) and answers "is x in the set?" with:

No false negatives: If x is in the set, the filter always returns true

Tunable false positives: The filter may incorrectly return true for elements not in the set, with probability configurable to ~1%

The query algorithm computes three hash functions of the queried element, XORs the filter values at those positions, and compares to a fingerprint:
query(x):
    h0 = hash0(x) mod segment_length
    h1 = hash1(x) mod segment_length + segment_length
    h2 = hash2(x) mod segment_length + 2 * segment_length
    return filter[h0] XOR filter[h1] XOR filter[h2] == fingerprint(x)
Critically, this computation happens entirely on the client. The server never sees the query input.

12.3 Filter Distribution

Servers generate and publish their filters periodically, hourly or daily depending on churn rate. A filter for a server with 1 million blobs requires approximately 1.1 MB, small enough for clients to download and cache.

The filter might be distributed via:

HTTP endpoint on the Blossom server (GET /filter)

Nostr event published by the server's identity

Out-of-band distribution (IPFS, BitTorrent, etc.)

Clients download filters for their configured servers, then perform local lookups when deciding whether to upload. If the filter indicates a blob might exist (accounting for false positives), the client can either skip uploading or perform a HEAD request to confirm.

12.4 Limitations

Binary fuse filters are immutable once constructed. They cannot be updated incrementally-adding a new element requires rebuilding the entire filter. This is acceptable for periodic batch updates but prevents real-time synchronization.

False positives mean clients occasionally skip uploads for blobs the server lacks. The subsequent fetch will fail, exposing the false positive; the client can then upload. With a 1% false positive rate, this occurs rarely and has minimal impact.

The filter reveals the total number of blobs the server stores (derivable from filter size). It doesn't reveal which specific blobs or any information about their contents.

13. Garbage Collection

13.1 The Accumulation Problem

Content-addressed immutable storage naturally accumulates data. Updating a file creates new blobs; the old blobs persist. The directory structure uses copy-on-write semantics, so modifying a deeply nested file creates new blobs for every ancestor directory up to the root. Without cleanup, storage consumption grows monotonically even if the logical dataset size remains constant.

This design places garbage collection responsibility entirely with the client. The system does not automatically delete anything. Users must explicitly choose to delete obsolete data, accepting the tradeoff between storage costs and history preservation.

13.2 Reference Tracking

The client maintains knowledge of which blobs are reachable from each commit. A blob is garbage if it's unreachable from any commit the user wishes to preserve.

Computing reachability requires traversing the Merkle DAG from each preserved commit's root. For a given set of root hashes, reachable blobs are:
reachable = {}
for root in preserved_roots:
    traverse(root, reachable)

def traverse(hash, reachable):
    if hash in reachable:
        return
    reachable.add(hash)
    blob = fetch_and_decrypt(hash)
    for child_hash in extract_references(blob):
        traverse(child_hash, reachable)
Blobs not in the reachable set are candidates for deletion.

13.3 Deletion Strategies

Several strategies for garbage collection exist, offering different tradeoffs:

Keep everything: Never delete blobs. Storage grows unboundedly, but complete history is preserved. Suitable for archival use cases where history has intrinsic value.

Keep recent history: Preserve the last N commits or commits from the last M days. Delete blobs unreachable from this window. Balances storage cost against useful history depth.

Keep only current: Preserve only the chain head. Delete all blobs unreachable from the current state. Minimizes storage but loses all history. Recovery options are limited if the current state is corrupted.

Explicit snapshots: Mark specific commits as preserved (e.g., monthly snapshots, pre-migration backups). Delete blobs unreachable from any preserved commit.

13.4 Deletion Process

To delete garbage blobs:

Compute the set of blob hashes to delete

For each hash and each server storing a share of that blob:

Generate a deletion authorization event

Send DELETE request with authorization

Update the garbage list in the next commit to reflect completed deletions

The commit's garbage field serves as an announcement of intent. It signals to future clients examining history that these blobs were deliberately deleted and should not be considered missing or corrupted.

Deletion authorization uses the same Nostr event mechanism as uploads:
{
  "kind": 24242,
  "tags": [
    ["t", "delete"],
    ["x", "<sha256 of blob to delete>"],
    ["expiration", "1701910800"]
  ],
  "content": "Garbage collection",
  "sig": "<signature>"
}
13.5 Metadata Event Garbage Collection

The hash chain of commit events also accumulates over time. Old commit events may be pruned from relays to reduce storage, but this requires care.

Safe deletion criteria for commit events:

The commit's blobs have been garbage collected (no point keeping metadata for deleted data)

The commit is not the chain head or a preserved snapshot

Sufficient time has passed that no client might be traversing through it

In practice, commit events are small (kilobytes) and relay storage is cheap. Most users can retain their complete commit history indefinitely. Users with extremely long histories or storage-constrained relays can prune old commits, accepting that history before the pruning point becomes inaccessible.

14. Lifecycle Summary

14.1 Initial Setup

A new user performs one-time setup:

Generate or import a Nostr keypair (nsec/npub)

Derive the master storage key from nsec

Configure preferred Blossom servers

Configure preferred Nostr relays

Create an empty root directory

Publish the genesis commit event

14.2 Adding Files

To add a file to the storage system:

Read the file content

Divide into fixed-size blocks with padding

Generate a random per-file encryption key

For each block:

Derive the block encryption key

Encrypt with XChaCha20-Poly1305

Erasure-code into n shares

Upload shares to n servers

Construct the inode with block metadata

Encrypt and upload the inode blob

Update the parent directory to include the new entry

Recursively update ancestors to the root

Stage changes for the next commit

14.3 Committing Changes

When the user saves:

Fetch current chain head from relays

Verify local changes are based on this head

Upload all staged blobs (files, inodes, directories)

Construct commit event with new root and prev reference

Sign and publish commit to relays

Clear local staged changes

14.4 Reading Files

To read a file by path:

Fetch current chain head

Decrypt commit to obtain root blob location

Traverse directory structure to target inode

For each block in the inode:

Attempt to fetch k shares from listed servers

Erasure-decode to recover encrypted block

Decrypt with derived block key

Concatenate blocks and remove padding

Return file contents

14.5 Verification and Repair

Periodically, the client should verify data availability:

For each blob referenced by the current state:

For each share of that blob:

Send HEAD request to check existence

Optionally, GET and verify hash matches

If any blob has fewer than k available shares:

Fetch k surviving shares

Erasure-decode to recover the block

Re-encode to generate missing shares

Upload replacement shares to new servers

Update inode with new share locations

Commit the updated inodes

14.6 Garbage Collection

When storage costs warrant cleanup:

Decide which commits to preserve

Compute reachable blob set from preserved commits

Identify unreachable blobs

Delete unreachable blobs from servers

Optionally delete obsolete commit events from relays

Record garbage collection in next commit

15. Security Analysis

15.1 Confidentiality

Storage servers observe only uniformly-sized encrypted blobs. They cannot determine:

File contents (encrypted with XChaCha20-Poly1305)

File sizes (obscured by fixed block padding)

File types (all blocks are indistinguishable)

Filenames (stored in encrypted directory blobs)

Directory structure (directories are encrypted like files)

Relationships between blobs (no plaintext linking)

The encryption is semantic-identical plaintexts produce different ciphertexts due to random per-file keys. Servers cannot detect when users store the same content.

15.2 Integrity

Content addressing provides integrity at multiple levels. Share hashes verify individual share integrity. Block hashes (stored in inodes) verify decrypted block integrity. The Merkle DAG structure verifies structural integrity-any modification to any blob changes the root hash.

Poly1305 authentication tags detect ciphertext tampering. Even if an attacker modifies stored ciphertext in a way that produces a valid hash, decryption will fail authentication.

15.3 Availability

Erasure coding ensures availability despite server failures. With (k, n) parameters, data survives the loss of any n - k servers. The hash chain ensures commit history survives relay churn as long as at least one relay retains the events.

The system does not provide availability against censorship or targeted attacks where adversaries deliberately destroy more than n - k shares simultaneously.

15.4 Authentication

Nostr signatures authenticate all state changes. Only the holder of the nsec can publish valid commit events. Blossom authorization events prevent unauthorized uploads or deletions.

Relays and servers can verify signature validity but cannot forge signatures. A compromised relay could refuse to serve events (availability attack) but cannot produce fake commits (integrity preserved).

15.5 Key Compromise

If the nsec is compromised, all security properties fail. The attacker can:

Decrypt all current and historical data

Publish malicious commits

Delete data from servers

Irrevocably destroy the dataset

Key management is outside this system's scope. Users should employ standard practices: hardware security modules, secure backup procedures, passphrase protection.

16. Future Considerations

16.1 Payment Integration

Storage servers require compensation for resources consumed. Integration with payment systems would enable sustainable server operation.

Possibilities include per-byte pricing with Lightning Network micropayments, subscription models with ecash or traditional payment, and storage markets where servers compete on price and reliability. Payment integration should not compromise privacy-payments should not link to specific blobs or reveal access patterns.

16.2 Steward Services

A steward service could handle verification and repair automatically, running continuously without user intervention. This requires delegating sufficient authority to perform repairs without granting full account access.

Potential approaches include threshold signatures where the steward holds one share of a multisig, capability tokens authorizing specific repair actions, and read-only access combined with user approval for repairs. Steward design involves complex trust tradeoffs and is deferred to future work.

16.3 Multi-Device Synchronization

The current design supports multiple devices through the commit chain, but conflict resolution is minimal. Enhanced multi-device support might include automatic merging for non-conflicting changes, three-way merge for file-level conflicts, operational transformation for collaborative editing, and CRDT-based structures for specific data types.

16.4 Deduplication

Content addressing naturally deduplicates identical files-they hash to the same blob. Block-level deduplication across files is more complex. Content-defined chunking using rolling hashes (Rabin fingerprinting) could identify common blocks across similar files, reducing storage for versioned documents or near-duplicates.

16.5 Proof of Retrievability

More sophisticated cryptographic proofs could enable efficient verification without downloading data. Proof of Retrievability (PoR) schemes allow servers to prove they hold data by responding to challenges. This could reduce verification bandwidth from O(data size) to O(security parameter).

17. Conclusion

This design provides a practical architecture for durable, private, personal storage built on existing Nostr and Blossom infrastructure. A layered architecture separates concerns: fixed-size blocks provide privacy through uniformity, erasure coding provides durability through redundancy, authenticated encryption provides confidentiality and integrity. Efficient updates come from the Merkle DAG, with auditable history and conflict detection from the hash chain.

The system achieves its core requirements. Durability is provided through erasure coding-data survives arbitrary server failures up to the configured threshold. Storage providers learn nothing about content, sizes, structure, or access patterns beyond gross storage volume. Sovereignty is preserved-users control when changes commit and when old data is deleted. Recoverability is complete-the entire dataset and its history can be reconstructed from a single secret key.

Immutable, content-addressed blobs simplify consistency and enable deterministic caching. An explicit save model gives users clear checkpoints, avoiding the complexity of real-time synchronization. History and conflict detection come from the hash chain, with no trusted timestamps or consensus required.

Significant work remains for production deployment. Payment integration and automated maintenance are areas for future development. But the core architecture presented here provides a solid foundation for personal data storage that respects user sovereignty while leveraging decentralized infrastructure.

References

Nostr Protocol. NIP-01: Basic Protocol Flow Description. https://github.com/nostr-protocol/nips/blob/master/01.md

Blossom Protocol. BUD-01: Server Specification. https://github.com/hzrd149/blossom

IETF RFC 8439. ChaCha20 and Poly1305 for IETF Protocols. https://tools.ietf.org/html/rfc8439

IETF RFC 5869. HMAC-based Extract-and-Expand Key Derivation Function (HKDF). https://tools.ietf.org/html/rfc5869

IETF RFC 5510. Reed-Solomon Forward Error Correction (FEC) Schemes. https://tools.ietf.org/html/rfc5510

Graf, T. M., & Lemire, D. (2022). Binary Fuse Filters: Fast and Smaller Than Xor Filters. ACM Journal of Experimental Algorithmics.

BIP-340. Schnorr Signatures for secp256k1. https://bips.dev/340/

Nostr Protocol. NIP-44: Encrypted Payloads (Versioned). https://github.com/nostr-protocol/nips/blob/master/44.md

Appendix A: notation reference

Symbol Meaning

B Block size in bytes (typically 262,144)

k Erasure coding: minimum shares for reconstruction

n Erasure coding: total shares per block

nsec Nostr secret key (32 bytes)

npub Nostr public key (32-byte x-coordinate)

GF(2^8) Galois Field with 256 elements

H(x) SHA-256 hash function

HKDF HMAC-based Key Derivation Function

XChaCha20 Extended-nonce ChaCha20 stream cipher

Poly1305 One-time authenticator MAC

Appendix B: recommended parameters

Block size: 256 KiB (262,144 bytes)
Provides good balance between padding overhead and chunking granularity.

Erasure coding: (k=3, n=5)
Tolerates 2 server failures with 67% storage overhead. Requires 5 independent servers.

Encryption: XChaCha20-Poly1305
192-bit nonces enable safe random generation. Software performance excellent without hardware acceleration.

Key derivation: HKDF-SHA256
Standard, well-analyzed, widely implemented.

Commit distribution: 5+ Nostr relays
Ensures commit retrievability despite relay failures.

Verification interval: Weekly
Balance between catching failures early and minimizing bandwidth.

k	n	Overhead	Tolerance	Servers Required
2	3	1.50×	1 failure	3
3	5	1.67×	2 failures	5
4	6	1.50×	2 failures	6
4	7	1.75×	3 failures	7
6	9	1.50×	3 failures	9

Method	Path	Description
GET	`/{sha256}`	Retrieve blob by hash
HEAD	`/{sha256}`	Check blob existence
PUT	`/upload`	Store a new blob
DELETE	`/{sha256}`	Remove a blob
GET	`/list/{pubkey}`	List blobs uploaded by a pubkey

Symbol	Meaning
B	Block size in bytes (typically 262,144)
k	Erasure coding: minimum shares for reconstruction
n	Erasure coding: total shares per block
nsec	Nostr secret key (32 bytes)
npub	Nostr public key (32-byte x-coordinate)
GF(2^8)	Galois Field with 256 elements
H(x)	SHA-256 hash function
HKDF	HMAC-based Key Derivation Function
XChaCha20	Extended-nonce ChaCha20 stream cipher
Poly1305	One-time authenticator MAC

what the heck? even AIs sometimes do what they want when they ...

2025-12-08T03:46:35Z

what the heck? even AIs sometimes do what they want when they can't resolve something! i want to create a desktop GUI app, but they want to build a CLI? 😂