The conclusion first:
three layers, one path.
What we build is not three unrelated products, but three layers of one complete path. We put the conclusion first; the chapters that follow explain why it holds.
Turns intent into a project. Conversation, project files and isolated preview form one loop that produces a complete ofa.js application.
Supplies identity, a virtual file system and peer-to-peer connection, so applications run directly in the browser without a platform database.
Lets an application move from person to person without an app store, reaching the people who actually need it.
Linked together, the three make a path from idea to user that needs no server of its own for each application. That is the story the next chapters unfold.
Who are we?
We are Synchratex. Our purpose is simple: to let data move more freely.
But by “flow” we do not mean data reaching some platform faster, with the platform then deciding who is allowed to see it. We mean a different kind of movement: data sets out from the place that produced it and arrives directly at the people who need it, without first being handed over to a central node.
That sounds like a slogan. But look closely at how today's internet actually works, and you will find it is almost precisely the opposite.
We build NoneOS, Mazmot and Conjure. They look like separate products; in fact they answer a single question: if applications no longer grew around servers, what would the internet look like?
Today's internet
looks more like a tree.
You send a photo to your family over WeChat, WhatsApp or Line. Even if you are sitting on the same Wi-Fi, the photo usually leaves your device first, uploads to the provider's central server, and is then forwarded on to the other phone.
The blogs, posts, videos and music you open are mostly distributed through central servers too. Creators hand their files to a platform; the platform hands them out to everyone.
We are used to calling this network “the internet.” But follow where the data actually goes, and it does not resemble a net at all. It looks more like an internet tree: every user is a leaf and a branch, all data runs along the branches toward the trunk, and the trunk hands it back out.
Central servers are powerful. They connected billions of people at remarkably low cost in the internet's early years. But they also turned the network into a system with a definite center — and a center is, by its nature, a single point.
The cost of the tree
is paid by everyone in the end.
Centralization is not merely a choice of technical architecture. It decides who owns the data, who sets the rules, and who absorbs the loss when the system fails.
Cost does not grow linearly. It grows exponentially.
With a thousand users connected to one another, a well-specced machine is enough. But when a platform serves tens of millions of users a day, hardware, bandwidth and operations expand rapidly. To keep costs down, the platform must field enormous engineering teams to tune scheduling, caching and capacity.
Those costs do not disappear. They return to every user through subscriptions, advertising, or the commercialization of user data.
When the center fails, the service disappears
When a central server goes down, you cannot reach the data stored on the platform, and you cannot keep talking to your friends. In the worst cases — natural disaster, operational accident, or a company folding — years of accumulated content can vanish for good.
Most of the time we do not feel this, because life is relatively stable. But the risk never went away. It was simply pooled and held somewhere else on our behalf.
Ownership is blurry
What you write on a platform lives on the platform's servers, under the platform's rules. Accounts can be banned, APIs shut down, services taken offline. What you hold is permission to use — not ownership of the data itself.
That is why we do not believe “building a better center” is the final answer. The problem is not the size of the center. It is the premise that a center must exist.
Web3 does not have to mean chains.
Web3 originally described a more open web: readable, writable, ownable. But in practice today it is often equated with blockchains, tokens and smart contracts.
Blockchains do offer one route to decentralization. But they bring new thresholds of their own: wallets, gas, private-key management, contract security, and technical complexity that ordinary people cannot reasonably be asked to follow. For most people, it has not made “owning your own data” any easier.
1990s—2004
The read-only web
Users browsed portals and news sites; content was produced and managed centrally by service providers.
2004—NOW
Readable, writable, platform-owned
Anyone could create, but content settled on platform servers and the platform allocated the value.
NEXT
Readable, writable, owned
Identity, data and connection return to the user. No dependence on a central platform, and no need to buy a currency first.
We choose a Web3 built on connected data
Synchratex issues no token and asks no one to understand blockchains. We use what browsers already have: local storage, cryptographic identity, WebRTC and peer-to-peer messaging.
A user opens a web page and holds an identity defined by a key. Applications keep their data locally. When collaboration is needed, the data crosses an encrypted link straight to the other side. A handshake server only helps two parties find each other; it carries no content, and it owns no relationship.
From tree to mesh.
A real mesh should not need a trunk in order to carry anything. Every node should be able to produce, keep and forward data; connections are local, but the network is whole.
In NoneOS, this network is made of three capabilities:
- Identity: a user generates an identity from an ECDSA key pair. Data can be signed with the private key, and any recipient can verify its origin and integrity.
- Connection: a handshake server helps two parties exchange WebRTC connection details, after which data can travel directly peer to peer; when the link is unstable, an encrypted relay carries it instead.
- Ownership: files and applications live in the virtual file system on the user's device, independent of any platform database, and can be exported and migrated.
This does not mean abolishing every server. Handshake and relay still exist, but they recede into lightweight connection infrastructure rather than presiding over data and applications. They can be self-hosted, they can be replaced, and they can be bypassed once the network is stable enough.
When generation gets cheap,
infrastructure should not get expensive.
AI is making “writing an application” cheaper by the day. But most generation tools still serve the old architecture: the code they produce still has to be deployed to a server, and still needs a database, accounts and operations.
If the cost of generation approaches zero while the cost of running does not fall, infrastructure will swallow the productivity AI brings. This is why we build Conjure.
Conjure is not merely a code generator. It closes a loop between conversation, project files and isolated preview, so the result runs directly in the Mazmot / NoneOS browser runtime. When generation is done, there is no server to provision for each application, and no deployment detour interrupting the work.
We believe the next generation of applications will be generated by agents, run in the browser, and move directly from person to person.
This is also why our products are not a set of unrelated features. Conjure turns intent into a project; NoneOS supplies identity, files and network; Mazmot lets an application reach users without passing through an app store. Together, the three form one complete, serverless path for applications.
As for decentralized social networks and the applications beyond them, they are the next residents along this path. What they prove is not only technical feasibility, but another possibility: applications can belong to their creators, and to their users too.
Our commitment.
We do not know how large this mesh will eventually become. But we know what principles it should be built on.
- Users own their identity and their data. The platform is not the final custodian of data; keys and files belong to the user.
- Open standards, not new walls. The core runtime is open source, handshake nodes can be self-hosted, and applications can migrate.
- No new centers. We may have servers, but we will not let servers become rule-makers again.
- Build first, declare later. These are not finished answers, but directions still being tested.
The internet once grew from a handful of portals into a network everyone could write to. The next step should be a network where everyone can own their data and their connections, without handing their fate to a single center.
This is what we are doing: letting data move more freely, and putting applications back in people's hands.