Making sharing explicit in Tidefern
Category-scoped grants, revocation, and a private journal boundary in a cycle, pregnancy, and family tracking product.
Tidefern is a cycle, pregnancy, and family tracking product I'm building. Before the everyday screens, I needed an answer to one question: when someone invites a partner, what can that partner see?
A person might share today's cycle summary while keeping symptom history private. Someone helping with a child's care might need access to that child's information without seeing every other record in the account. Calling both people a "partner" doesn't answer either request.
Give the permission a shape
The policy checks who is making the request, the action they're taking, and the resource category. These are separate inputs to the decision.
A grant names its owner and recipient, a category, and a level: summary, read, or contribute. Child-related access also names a particular child. Owners retain control of their own resources, and guardians have an explicit path for the child they care for.
Revocation takes the grant out of the decision.
Seeing a summary and editing a record need different permissions. The policy answers that question before a screen decides which controls to show, so each component doesn't have to work out its own meaning of "partner."
The implemented policy keeps private journal entries outside sharing grants. A grant doesn't let its recipient share onward or delete the owner's data. Unknown or unmatched access is denied.
Keep the rule below the screen
An edit button helps someone understand their access. The service still has to check the request against the actual resource. Hiding the button leaves that job undone.
The same decision needs to work for the calendar and family pages, and for requests made through the typed API client, so keeping it below those interfaces gives them a shared permission contract.
Be precise about encryption
Private free text uses application-layer envelope encryption with versioned keys. The service can decrypt content for an authorized request, so this isn't end-to-end encryption.
Reminders need their own disclosure limit. An email can tell someone to open the app without copying a sensitive entry into it. The amount of information that belongs in a reminder is smaller than what belongs on the page it opens.
Where the project stands
The public site, API foundation, policy layer, and design reference are in place. I'm still building the authenticated everyday screens. A complete walkthrough of the planned product flows is pending.
Next is the sharing interface. It needs to tell someone what they're granting and who receives it, with a clear way to take that access back.