不要成為你討厭的平台Do Not Become the Platform You Hate

Remember yesterday’s events for now.

Today, I thought through the architecture of the INN Earth node again. If I do not write it down, a few days from now I may remember only what I finally chose and forget what I was afraid of at the beginning.

Forgetting what you were afraid of is the first step toward a system becoming dangerous.

First, the speed of updates

Instinctively, news should be as fast as possible.

But I kept asking myself today: fast for whom?

INN is not an earthquake alert or a flight-delay service. It wants to deal with things that only slowly become visible after an event is over: who begins rewriting standards after a ceasefire agreement is signed; which supply chains are cut off after a company merger; who still remembers the original version after a report is deleted.

A delay of three hours will not necessarily kill anyone.

But if information is placed in the wrong location, folded away, or rewritten, it may become impossible to find later.

A real-time system needs always-on servers, databases, monitoring, and maintainers. It can break in the middle of the night, or on the evening before an exam.

I am fifteen. My midterm exams are next month.

So the first version will not be a real-time service.

After content is submitted, the system will automatically build a static website. I will accept a delay of several minutes or more in exchange for a system I can genuinely maintain for many years.

Being slow is not the problem.

Pretending that you will never break is.

Content cannot hide inside a black box

I considered using a database. I also considered a more polished content-management system.

They could both work well: fast searches, attractive editors, and easier access for people without technical backgrounds.

But they share one problem: the content becomes separate from the system.

When an article has been edited, data deleted, or a version overwritten, readers usually see only the final version that remains.

That is exactly the problem INN wants to address.

So in the first version, content will be stored as Markdown files in the same public repository as the code. Every change must leave a version record, an explanation of the change, and a content hash. Important versions will also be synchronized to other mirror nodes.

Git is not absolute truth.

History can still be rewritten, and a repository can still be deleted.

But at least anyone can see when an article was changed, what was changed, and who proposed the change.

Truth is not a file that can never be altered.

Truth should be a trail of changes that cannot easily be quietly erased.

The cost is obvious too.

The submission process is unfriendly to people who are unfamiliar with technology. Markdown, field formats, and version commits can each become a gate that keeps people outside.

That is the worst part of the first version.

I will admit it first, and later build a submission entrance that converts forms into files. I cannot pretend the door is open just because the entrance has not been built yet.

Bilingual cannot mean copy and paste

At first, I wanted to connect an automatic translation service.

It is fast, and it looks complete.

But if I cannot understand the English version, how would I know whether it translated “controversy” as “conflict,” or “not yet verified” as “false”?

One mistranslation can make readers in two languages see completely different things.

So the first version will not connect to an automatic translation API.

If a source provides Chinese and English, they will be shown in full side by side. If it provides only one language, the original language and “translation not yet available” will be clearly marked.

It will not look good.

But looking imperfect is better than pretending to be complete.

When the Chinese and English paragraphs do not align, I will not force them together. The missing side will remain blank, with the reason for the omission marked beside it.

Because translation is not just moving sentences from one place to another.

Translation is an admission that people who use another language deserve to be treated seriously too.

The homepage should not decide what matters for readers

At first, I wanted the homepage to display an unlimited stream of articles.

Then I realized that once there are enough articles, they must be ranked.

As soon as ranking appears, who is placed first, who is hidden, what counts as popular, and what counts as worth reading all become new forms of power.

So the homepage will keep only a fixed number of recent articles, with public publication time as the only ordering method.

No popularity ranking.

No recommendations.

No “you may also like.”

Old articles will not be deleted. They will remain in a complete archive that can be searched, downloaded, and mirrored.

Time-based ordering is not neutral either.

It simply avoids judging the value of the content for the reader.

For now, this is the approach I can find that makes the fewest decisions on the reader’s behalf.

A map can assist; it cannot be the judge

The map feature is the most dangerous.

An article mentioning a place does not mean the event happened there. If a piece of data is marked with the wrong location, the people involved could be found, tracked, or misunderstood.

So the map will not use precise locations, and it will not automatically pin every article that mentions a place name.

It will show only region-level information that has been confirmed by a person and whose public display does not create additional risk. Articles whose locations cannot be confirmed will still exist in the news stream and archive; they simply will not enter the map.

The map can help people explore.

It cannot decide whether an article exists.

Performance is not decoration

INN cannot assume that readers use the newest devices, the fastest networks, or live in environments where the power never goes out.

Low-bandwidth support, older devices, reduced motion, downloadable text versions, and offline caching are not “compatibility features.”

They are part of the entrance.

If a news node works properly only on high-end devices, then from its very first day it has already decided who gets to know what is happening in the world.

The final tests

I want to leave the system with a set of troublesome tests.

Not tests of whether it looks beautiful.

Tests of whether it has quietly become the kind of thing I hate.

• When the bilingual content is incomplete, it must not use blank content to pretend it is complete.
• When sources conflict, it must not simply hide the less common version.
• When an article is corrected, the old version must remain verifiable.
• In low-bandwidth mode, the core content must remain readable.
• When the map cannot determine a location, the article must not disappear.
• When users leave the platform, they must be able to download their submissions, revision histories, and cited sources.

As I wrote this, I realized that the entire architecture is really answering one question:

If I were someone without an account, without high-speed internet, without corporate credentials, and without the ability to wait for a system to decide what matters for me, how would this platform treat me?

If the answer is bad, go back and change the code.

The application form is still open.

I know now that I am not applying to build a news website.

I am applying to build a path.

And what matters most about a path is not how beautiful it looks.

It is whether the next person who needs it can actually walk onto it.