Owning Your Content | TokiStorage

The point of this essay: most people don't realize they're renting space on a platform, not owning their content. For what you write to remain yours, you need to design where the data lives. Platforms are for rendering. They are not for ownership.

1. If that service disappeared, what would remain?

Many people have experienced a blogging service shutting down. Articles gone. Years of accumulated content, vanished. Only those who had backed up their data managed to take anything with them.

Social media accounts get suspended without warning. Followers built over years, every post — gone overnight.

These aren't accidents. They're structural problems. The moment you choose to put your content inside a platform, the dependency begins.

2. The difference between owning and using

When someone says "my content," what do they actually mean?

Usually, it's "my page inside that service." Accessible. Editable. Publishable. But when the service ends, access ends. When the platform changes its rules, the presentation changes. When the account is suspended, everything is lost.

This isn't ownership. It's use. More precisely, it's a lease. You can stay as long as you keep paying rent — but the landlord can ask you to leave.

Truly owning content means the data is under your own control. When a service disappears, the data remains. When platforms change, the content doesn't.

2.5 The era of trying to automate through it

There was a time when Medium, note.com, and Notion were all in use. And with each, there were attempts to reduce operational costs through automation — using tools that could automate keyboard and mouse operations, scripting posting, updating, and management.

It worked for a while. Then the same thing kept happening. The service interface changed. The sequence of operations changed. New constraints were added. Each time, the automation scripts needed maintenance.

Automation built on top of an external UI breaks every time the external UI changes. It wasn't automation — it was "continuously fixing things that keep breaking."

After designing TokiStorage, something became clear. The problem wasn't the method of automation. It was the structure of dependency itself. As long as the automation depends on an interface, any change to that interface generates cost. Anything where control lives outside your own boundary — no matter how automated — never fully escapes maintenance cost.

Medium, note.com, Notion — all discontinued. Not a problem with the tools. A problem with the design. Having a boundary — clearly separating what is under your own control from what isn't — was the answer.

3. Git as a foundation

As a place to keep content, a Git repository is an excellent choice.

Markdown files open in any environment — text editor, terminal, browser. No particular software required. They'll be readable twenty years from now. The format is stable, mature, settled.

GitHub hosts the repository, but the important thing isn't GitHub itself — it's the Git underneath. If GitHub disappears, the repository remains locally. It can be moved to another hosting service. It can be distributed across multiple locations.

Content (Markdown) → your own Git repository
↓
Rendering → platform (Zenn, GitHub Pages, others)

When this structure holds, the platform becomes "a place to display." If it disappears, display it somewhere else. The content itself is never lost.

4. Why Zenn

For technical writing, Zenn is the platform of choice. The reason is simple.

Zenn is designed to publish Markdown from a GitHub repository as articles. The content lives in GitHub. Zenn reads it, formats it, and displays it — nothing more.

So if Zenn disappears, the articles don't disappear. The GitHub repository stays. It can be republished elsewhere. If Zenn's rules change, the Markdown files don't change. No format lock-in.

This is fundamentally different from most platforms, which keep content inside themselves. Zenn references an external repository instead of holding the content. That single design difference changes the dependency entirely.

5. How Zenn differs from Medium and note.com

There's a common objection: "Export functions exist, so it's fine." Many services do offer data export. But being able to export is fundamentally different from the data being yours from the start.

They look similar. The design philosophy is opposite.

Medium / note.com: content lives inside the service → they let you take your bags when you leave
Zenn: content lives in your own GitHub from the start → there's nothing to take out

An export function is an exit. Having an exit matters, but it doesn't resolve the dependency. When a service shuts down suddenly, there may be no time to export. The exported data may not be fully reproducible elsewhere.

With Zenn, the concept of "migration" doesn't arise in the first place. The content has always been in your own GitHub. If Zenn disappears, another service reads the same repository. That's all.

Medium and note.com are content hosting services. Zenn is a content rendering service. That difference is where the external dependency gap lives.

6. External dependency as a concept

Software design has a concept called external dependency — how much a system depends on external components. More dependencies mean more exposure to outside changes.

The same concept applies to content publishing.

Content that only exists inside a specific service has high external dependency. Service specification changes, price increases, shutdown — all of these become direct risks.

Content that exists in your own repository, where the platform is only the display layer, has low external dependency. When platforms change, the content is unaffected.

7. A unified design for voice memos, essays, and technical writing

When this thinking is taken seriously, the design of content publishing changes entirely.

Voice memos accumulate in a private Git repository. Essays live on a GitHub-hosted site. Technical articles are read by Zenn from GitHub. All content exists in Git repositories under personal control.

Platforms are a layer on top. Use one when it's useful. Switch when it stops being useful. The content is bound to nothing.

This is the content version of "tools wear out, infrastructure grows." Platforms are tools — they wear out. Data is your own infrastructure — it grows.

8. Resisting vendor lock-in

Vendor lock-in describes the state of being dependent on a specific vendor's products or services, making migration difficult. Commonly discussed in cloud computing, it applies equally to content publishing.

Content written in a proprietary format can only be read in that service. Even when export functions exist, complete reproduction is rarely possible. Years of accumulated content becomes bound to a specific service.

Writing in a standard format (Markdown), managing with version control (Git), hosting on an open platform (GitHub) — this is design-level resistance to vendor lock-in.

9. The foundation for lasting a thousand years

TokiStorage is built around the mission of preserving things for 1,000 years. Thinking that far ahead, none of the platforms that exist today will still exist. Companies disappear. Services end. Formats become obsolete.

This is why separating content from platforms matters. Own the data. Use standard formats. Distribute across multiple locations.

Even over ten years — far shorter than a thousand — the same logic holds. Whether a service used today still exists in ten years, no one can say.

Build the place where what you write doesn't disappear. Design it yourself. That is what owning your content means.

Platforms are for rendering. They are not for ownership. As long as the data stays under your control, no service disappearing can take your content with it.