My Card is now live at card.myfield.one.
Digital business cards are not new.
Scanning a QR code, opening a page, and saving someone’s contact details are already mature experiences. My Card is about a different question:
If I only want to give my contact information to another person, why should I first give that information to the cloud?
Most digital business card products are cloud-first. You upload your name, phone number, email, company, links, avatar, and other details to the cloud. The cloud generates a profile page, and other people read it after scanning your code. This is convenient, and it naturally supports short links, online updates, and visit analytics. But it changes the original boundary of a business card: “giving my contact information to someone” becomes “publishing my contact information to a cloud platform, then letting the platform distribute it.” The platform can usually read the card content, and it may also see visit time, source, and other metadata.
This is one of the problems with much of today’s personal digital life.
Redesigning from local-first
My Card redesigns the digital business card from a local-first starting point.
In a local-first design, the local device is the default source and owner of the data. Creating and editing cards, saving received cards, recognizing photographed paper cards, and exporting vCards all happen locally first. This reduces the chances for plaintext data to leave the device. Cloud services, P2P, and other mechanisms become optional transport channels: a server can host public pages, relay encrypted content, and improve availability, but it does not need to become the reader of card plaintext.
This is also My Card’s role: it is a small app with a complete boundary, used to test whether personal data can belong to the user’s own devices first, then be shared and synced only when needed.
Two local-first problems
Once data lives locally, an app immediately faces two problems: sharing, and sync with account identity.
A business card is not only for yourself. If the plaintext is not uploaded to a server, how should user A give it to user B?
Users may also have multiple devices, or they may lose or replace a device. Multi-device sync becomes necessary.
Local-first should not mean data is trapped on a single device. But if sharing and sync are solved by going back to traditional cloud accounts and server-side plaintext storage, the boundary is broken.
For these two problems, My Card reuses ideas already tested in Turn Field.
Sharing: give the card to the other person, not the server
The core purpose of sharing is to move information from your device to the other person’s device.
My Card sharing is based on a QR code plus a URL fragment. The fragment is the part of a URL after #. Browsers do not send the fragment to the server when loading a page.
When you share a card, My Card generates a random key in the browser, encrypts the card data, puts the encrypted payload and key into the link fragment, and generates the QR code locally. When the recipient scans the code and opens the link, the server only returns a static page. After the page loads, the recipient’s browser parses the fragment, decrypts the card locally, and displays it.
The complete link itself is the access credential. Anyone with the complete link can open the card, and the channel used to send the link may also see it. Short links do not fit this model either, because a short-link service must first receive the complete original URL, including the fragment. What this design solves is more basic: sharing a card does not require first giving cloud server-readable card plaintext.
Sync: reuse MyField’s end-to-end encrypted sync
What happens after a user creates cards, receives cards, and then changes devices? Can updates sync across multiple devices?
My Card reuses MyField’s end-to-end encrypted sync capability. This capability was first refined in Turn Field: app data is encrypted on the device, and the cloud only acts as an encrypted relay that stores and forwards encrypted data. Other authorized devices receive it, then decrypt, merge, and use it locally.
In My Card, this means My Cards, Received Cards, and photographed card assets can all be encrypted before leaving the device. The server can help sync data to another device and reduce the risk of a single-device failure, but it does not need to read card plaintext.
Sync is still optional. The app itself does not depend on a cloud account to create, edit, or share cards. From the perspective of a local-first app, sync also does not have to be tied to MyField’s current cloud sync mechanism. The same model could later connect to P2P, user-hosted services, trusted device channels, or other transport methods that users are willing to trust.
My Card is not trying to be the most feature-rich digital business card.
It is more like a small proof: a personal data app can start locally, keep data on the user’s own devices, let the user actively hand data to another person when sharing is needed, and choose a sync method that does not make the server a default plaintext reader when multiple devices are needed. This is the direction MyField wants to keep exploring.