Pocket is gone. Omnivore is gone. Your reading library shouldn’t depend on our survival.
Turn Field stores your pages on your device, encrypted with keys only you hold. We can shut down tomorrow — your library stays.
But for me, Turn Field is more than a read-later tool. It is the first practical step toward a question I have been thinking about for a long time:
Can personal data have a digital home that truly belongs to the user?
Not a library locked inside one platform’s account. Not a cloud folder that requires blind trust in a remote service. But a library that lives on your own devices, controlled by your own keys.
Why start with read-later?
I did not originally plan to start with a read-later product.
The trigger came from a conversation with a friend. He used to be a Pocket user, and after Pocket shut down, he still had not found a replacement that felt simple, private, and durable enough.
What he wanted was straightforward: save useful webpages quickly, keep them somewhere safe, read them offline, organize them later, and avoid turning his reading history into another platform-owned profile.
At that time, several core pieces of Myfield were already taking shape: keychains, device authorization, local storage, and encrypted sync. A read-later use case felt like the right first application. It was small enough to build, but still touched the hard problems that matter for personal data tools: privacy, multiple devices, offline access, sync, and long-term accumulation.
So I built an early version and released it in late May. Over the next one to two months, Turn Field’s core experience became more stable, and the underlying Myfield design became sharper through real use.
The local-first choice
Read-later looks like it is only about saving web pages. Most saved pages are public. But the library itself is still sensitive.
What someone saves, and which pages they read again can reveal interests, problems, plans, research direction, and personal context. That is why Turn Field treats the reading library as something personal — not just a cloud bookmark collection.
The core functions run locally: saving, reading, organizing, and searching. Saving a page should be fast. Reading should work offline. Your own library should not disappear when the network is poor. Organizing and searching should not require every action to go through a server.
The current product is mainly delivered through a browser extension and a PWA. This covers desktop usage, offline reading, and basic mobile reading and organization. Mobile saving will be improved further through native mobile apps.
Local-first gives Turn Field speed, offline access, and a clearer privacy boundary. But it also makes multi-device sync harder.
If the cloud is not trusted, but users still need data across devices, how should sync work?
That is the problem Myfield is designed to address.
Not using the cloud service as the trust root
Most products start with an account system: register an email, set a password, log in to a server, and maybe add 2FA or passkeys later. These improvements help, but the platform still remains the root authority for account naming, authentication, recovery, and suspension.
Myfield takes a different approach: user identity starts from the user’s own keys, not from a platform account.
In simple terms, a Myfield ID is derived from an asymmetric public key. Only the holder of the corresponding private key can produce valid authentication and authorization for that ID. Multiple devices can each have their own keys, and a signed verification chain records device additions, key rotation, and authorization relationships.
This information is organized in a DID-document-like structure. It does not require a public blockchain, and it does not require a central server to become the root of identity.
The goal is not to remove all trust from the system. The goal is narrower: the cloud service should not be the root owner of the user’s identity.
No username, no password
In the current version, Myfield first supports Passkey + PRF as the key mechanism.
This is a practical choice. Normal users should not have to remember complex passwords, manage private key files, write down seed phrases, or understand hardware key workflows just to save and sync reading data. Passkeys are currently one of the most user-friendly passwordless options supported by modern operating systems.
In Myfield, users do not register with an email or set a password. The device creates a key through platform capabilities and uses it to sign identity documents and authorization operations.
This creates a username-free and password-free account experience: the ID and authorization come from the user’s own keychain, not from a platform-assigned account.
There are tradeoffs. Passkey + PRF works well on modern iOS, macOS, and Android, but not every system, browser, and authenticator has equal support. Myfield’s underlying design is not limited to this one key type. Over time, I want to support more device keys and recovery methods.
Syncing encrypted data through an untrusted cloud
With identity no longer rooted in a platform account, the next step is sync.
The principle is simple:
The cloud service may store and relay encrypted data, but it should not see plaintext content.
User devices share data keys with each other through end-to-end encryption. Saved pages, topics, summaries, and tags are encrypted locally before syncing to the cloud. Other authorized devices receive the encrypted data, then decrypt, merge, and use it locally.
The cloud service becomes an encrypted relay rather than a data controller. If the cloud infrastructure is compromised, the attacker should get encrypted objects, not readable personal content.
But this creates another difficult problem: how do you merge encrypted data?
If the cloud service cannot read the plaintext, it cannot perform semantic conflict resolution. Turn Field therefore keeps merge logic on the client. The cloud service only stores and forwards encrypted objects. Real merging happens after each device decrypts the data locally.
Merge policy for encrypted data
For Turn Field, I chose an object model with field-level LWW conflict resolution instead of a full CRDT.
This is an intentional tradeoff. Turn Field is currently a personal reading library, not a multiplayer collaborative editor. Most objects change infrequently, and field-level LWW is enough for many common cases.
For example, one device may generate a summary for a saved page while another device adds tags to the same page. Since those changes touch different fields, they can merge cleanly. If two devices update the same field, such as both regenerating the summary, the latest timestamp wins.
For high-frequency collaboration or more complex structured data, CRDTs may be a better fit. But for the current version of a personal reading library, a full CRDT would add unnecessary complexity. Myfield keeps the door open for CRDTs or other sync strategies in future applications.
Why AI exists in Turn Field
From a strict privacy perspective, Turn Field does not need AI.
But from a practical read-later perspective, AI can be useful. Many saved pages are long. Users may not read them immediately. AI can help extract key points, classify unsorted pages, or generate a report from a topic.
So Turn Field includes AI, but treats it as an optional layer, not a core dependency.
The current AI design follows a few rules:
- AI is not required for the basic product.
- AI only runs when the user explicitly clicks an action.
- AI only processes content selected by the user.
- Private pages cannot use AI features and stay local.
- If a request goes through Myfield AI, the service acts as a forwarding layer and does not save or modify the content.
Turn Field includes rules to help classify whether a page is public or may contain private content. Users can also manually mark pages as private. Once a page is private, it cannot be used with AI summarization, classification, or topic reports.
The current default uses Myfield AI for ease of use, especially for public webpages. This is not the final model. I plan to add BYOK and local model support later, so users can choose the AI trust model they prefer.
Lightweight cloud infrastructure
One side effect of this architecture is that the cloud side can stay light.
Most computation in Turn Field and Myfield happens on the client, on the user’s own device. Myfield currently does not run a traditional central application server. The cloud side mainly uses edge Workers for encrypted relay, lightweight coordination, and optional AI forwarding.
For self-hosted mode, the direction I have in mind is a desktop client paired with a minimal cloud deployment — so the cost of running your own instance stays close to zero. This is further out, but the architecture is designed with it in mind.
Current tradeoffs
Turn Field 0.9.0 is usable as a complete read-later tool, but it is still early. Several tradeoffs are worth making explicit.
Trusting web frontend code. Turn Field is currently mainly implemented as a web app and browser extension. Even if data is encrypted locally and the cloud service should not see plaintext, a web app still has a trust problem: if frontend code is loaded from the cloud, the user has to trust that the code being served has not been maliciously changed. The plan is to reduce this risk through open source code, locally installed extension/native flows, verifiable builds, signed releases, and self-hosting.
Limited key types. Passkey + PRF came first because it offers the best user experience for normal users. It avoids email/password accounts and avoids asking users to directly manage private keys. But it also has compatibility and ecosystem limitations. Future versions will add more key and recovery options.
Recovery. Once the server is no longer the root authority of the account, the familiar “forgot password, reset on the server” flow is no longer a simple answer. Myfield’s base design supports multiple keys, multiple devices, and key rotation, so recovery can be built around trusted devices, backup keys, or other recovery mechanisms. But the user experience has to be designed carefully.
Sync strategy. Field-level LWW is simple, lightweight, and understandable for the current personal reading library. But it is not universal. If Myfield later supports more complex collaboration apps, it may need CRDTs, operation logs, or merge policies by data type.
Sync metadata. Turn Field encrypts the object payload before cloud sync, so saved page content, topics, summaries, tags, and other app-level fields are not sent as plaintext. The cloud still sees the minimal sync metadata needed to route encrypted updates between devices. I plan to document this boundary more precisely when the sync API is published.
What comes next
Turn Field 0.9.0 is a starting point.
It is not the most feature-rich read-later tool, and it is not a finished personal data platform. It is a concrete experiment: start with a small but useful product, and use it to test an architecture centered on the user’s own devices rather than a platform account.
I want Turn Field to first become a good local-first reading library. The next steps: open the Myfield API so other local-first apps can build on the same identity and sync layer; add BYOK and local AI model support; and continue improving based on real usage.
If any of this make sense, feedback is very welcome.
I also started a small Discord group for early discussion: https://discord.gg/wRkZpurnqw
You can also reach me at hi@myfield.one.
Many tradeoffs are still open. I would rather make those tradeoffs visible early than pretend they have all been solved.