Salasilah · How it works

Building a family tree, together

Hand a relative one branch to fill in — and pull their work back into the main tree only when you say so. Here is the whole idea, one layer at a time.

✎ Draft. The mechanics are accurate; Layer 6 (the philosophy) is a first pass for you to rewrite.
SimpleDeep

Each layer stands on its own. Read the first, stop whenever you have enough, or open the next to go deeper.

1 The one sentenceYou share the work, not the risk

Your family tree is yours. You can give a relative their own working copy of just one part of it — say, "you take your father's branch and add your side" — and let them fill it in at their own pace.

When they're done, you review what they added and merge it back into the main tree. Until that moment, nothing they do can change your tree.

The promise: collaboration that can never quietly break the tree you've built. You stay the keeper of the master copy.
2 The three movesAssign → Fill in → Merge back

Two people, three steps. You (the owner) bookend the work; your relative (the contributor) does the filling-in in the middle.

1
Owner

Assign a branch

Pick a person as the anchor and how many generations up or down to include, then send it to your relative's email. They get an editable copy of only that slice.

2
Contributor

Fill it in

They open the link and work in their own copy — adding people, dates, photos. You can watch their progress read-only, but they're never editing your live tree.

3
Owner

Merge it back

When it's ready, you press Merge back. Salasilah shows you exactly what would change before anything is written. You approve; only then does the master tree grow.

Loaned, not given. The copy is your assignment on loan, so you can see it and you start the merge. A relative who wants a fully private tree of their own makes their own instead.
3 Why a copy, not shared live editingRecoverable beats real-time

The obvious design would be to let a relative edit your tree directly, with limits on what they can touch. We deliberately chose not to. The reason is recovery, not capability.

With live shared editing, a single missed permission check — or a well-meant mistake — changes your real tree, mixed in with your own edits, and untangling it later is genuinely hard.

With a copy that merges back:

Your tree can't be corrupted from outside — a contributor edits a different set of records entirely, so there's nothing to collide with.
The merge is one controlled moment. That makes it a natural checkpoint: Salasilah quietly snapshots your tree the instant before a merge, so a single Undo puts everything back if you don't like the result.

Same safety as a full change-history system, at a fraction of the complexity — because we only have to protect one moment, not every keystroke.

4 How a merge decidesIt compares three versions of each person

For every person the contributor touched, Salasilah looks at three versions of each detail and works out what to do:

  • Was — the value when the branch was handed out.
  • Theirs — what the contributor has now.
  • Mine — what's in your master tree now.
What happenedResult
Only they changed itTake theirs
Only you changed itKeep yours
You both changed it, differentlyAsk you to pick
A brand-new personAdded in
A person they removedProposed only — never auto-deleted
You are never surprised. Every conflict and every proposed deletion is put in front of you on a review screen. The safe choice (keep what's in your tree) is always the default.

If the contributor adds someone who already exists elsewhere in your tree, the review flags it as a possible duplicate so you can link the two instead of creating a copy.

5 The same engine, everywhereMerging any two trees

The merge machine isn't only for contributor branches. It joins any two trees — including two you built yourself (a mother's side and a father's side, or a small tree a relative emailed you). What changes is only how it figures out who is who.

Related trees

It already knows

When one tree came from the other (a contributor branch, or a duplicate you made), Salasilah remembers which person is which. It uses the precise three-version compare from Layer 4.

Unrelated trees

It has to match

Two trees built separately share no history, so Salasilah proposes matches by name, dates and parents — and you confirm every single one. It never fuses two people on its own.

When there's no shared history, Salasilah won't guess who edited a detail last. If your tree already has a value, a difference becomes a question for you — never a silent overwrite. An empty field simply gets filled in.

A small imported tree can therefore add a lot and overwrite nothing you didn't approve.

6 The philosophy · draft — please rewriteWhy we built it this way
✎ This layer is a placeholder in your voice-to-be. The principles below are the ones the design already follows; the wording is yours to shape.
Stewardship
A family tree has a keeper.
Many hands can build it, but one person holds the master and decides what enters it. Collaboration in Salasilah is help offered to a steward, not shared ownership that dilutes responsibility for the record.
Reversibility over power
We'd rather you can undo than move fast.
Every design choice favours being able to step back over being able to do more. A lineage is a long-lived record; the ability to recover from a mistake matters more than raw speed.
Never guess
When in doubt, ask — don't assume.
If Salasilah cannot be sure whether two people are the same, or whose edit should win, it hands the decision to a human. The list of questions is the honest price of not quietly getting it wrong.
Nothing is lost
A contributor's work always survives.
Undoing a merge never destroys the relative's effort — it still lives in their copy, ready to be fixed and merged again. Contributing should never feel risky.

— Placeholder closing thought: a family record is trust made durable. The tools should protect that trust before they do anything clever. (Rewrite freely.)