Future

FamShare currently focuses on family memory preservation, but the underlying architecture supports broader applications.

What we're building now

The current implementation is:

• Peer-to-peer document sync
• Personal device sync
• Document-level sharing permissions
• Markdown files with YAML frontmatter

This architecture is designed specifically for the family memory use case: journaling, photo albums, shared stories, event coordination within trusted groups.

What the architecture could support

The technical foundation (local-first, peer-to-peer selective sync with granular permissions) extends beyond family memories:

• Personal Dropbox replacement (selective sync, no cloud dependency)
• Family wiki and shared knowledge bases
• Collaborative note-taking within trusted circles
• Todo lists that sync to relevant people
• Portable desktop environment (documents follow you across devices)

Where we're stopping (for now)

FamShare uses document-level permissions because they're sufficient for family use cases and easy to reason about. You decide per-document who can see it, when they can see it, and how it syncs.

Projects like Willow Protocol are building more sophisticated permission models with finer granularity. Willow's data model handles namespace-level permissions, subspace ownership, and complex authorization schemes that enable general-purpose collaborative applications.

If FamShare expands beyond family memories into general-purpose document collaboration, adopting a permission model like Willow's might make sense. For now, document-level permissions keep the implementation simple and the user model understandable.

The local-first ecosystem

FamShare is one piece of a broader movement toward local-first software. We're not trying to replace every cloud service or solve every collaboration problem. We're focused on one thing: making sure family memories survive platform shutdowns, device failures, and business driven decisions.

Time Based Permissions

FamShare is exploring permissions that can change over time or trigger on life events: a journal entry that unlocks in 100 years, a document that opens when you die, or content set to delete rather than be inherited.

One idea is that entries could be opened with a sharded recovery key, split between trusted loved ones, or even legal entities that would be trusted with a will. When a vault is opened with the recovery key, entries are marked as deleted. At minimum, the files are just not able to be opened with that key. File deletion would be a famshare specific action but locking entries with different keys should be possible.

Potentially, this could be part of normal file sharing. Select some people you trust and the key will sync to them. As a user, you would need to opt-in to accept this. Selective sync accept is also a feature that needs to built. In this way, people holding shards might not even need to know they have them until needed. Different keys could unlock different content (incapacitation versus death).

This addresses an emerging problem in digital legacy: physical estates had natural access patterns (executor opens the safe deposit box), but digital content needs explicit unlock mechanisms. The OpenID Death and Digital Estate group is working on these questions. FamShare and its technology stack may be a good place to enable a digital lockbox, in a way that bereaved family members don't need to send a death certificate to multiple providers.