diff options
Diffstat (limited to 'docs/MESHBAY_DESIGN.md')
| -rw-r--r-- | docs/MESHBAY_DESIGN.md | 46 |
1 files changed, 25 insertions, 21 deletions
diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md index 052570a..8293493 100644 --- a/docs/MESHBAY_DESIGN.md +++ b/docs/MESHBAY_DESIGN.md @@ -3326,7 +3326,7 @@ are two albums. ### 9.12 Photo backup (Android) The Android application sends the photos taken on the phone to **one folder of -one group**, chosen by the member, once a day. It is a client feature over the +a group the member owns and is the only member of**, once a day. It is a client feature over the upload path that exists: a backed-up photo is a `file_upload` into a writable root under a slot the node granted, with every rule of §6.4, and its owner is recorded as for any upload. **No message, no node state and no hub state was @@ -3345,9 +3345,24 @@ object — absent, not refusing (§11.3). **Where it lives.** Its controls are on a page of their own, **Android Sync**, under a **Phone** heading of the side menu (`android-sync-page.js`), shown only -where `platform.photoSync` exists. Settings holds what the account prefers on -every client; this page holds what one phone sends, and is where whatever else -the phone sends will go. +where `platform.phoneSync` exists. Settings holds what the account prefers on +every client; this page holds what one phone sends: photos, contacts (§9.13), +and the kinds to come (messages, calendar, files). + +**One destination for every kind.** The top of the page chooses it once: a +group and one of its writable folders (`Destination.kt`, `sync-destination.js`). +Each kind goes into its own folder under it, `<folder>/<account>-photos`, +`<folder>/<account>-contacts`, made if missing. Only a group **the account owns +and is the only member of, with nobody invited**, is offered, because what a +group's folder holds every member can read, and none of this is the group's. +The hub's member list is asked again **at every run, before anything is +read**: a group that has gained a member, an invitation or another owner stops +every backup (`not_private`, a lasting refusal said once) rather than being +read from then on. Moving the destination is a fresh start for every kind: +each is told, forgets what it sent (its ledger belongs to the old place) and +runs at once; what was sent stays where it is. The page says so before it +happens, and says too when the group's Photos tab does not show +`<folder>/<account>-photos`, since photos there are kept but shown nowhere. **When.** A run is due 24 hours after the last run that *finished*; an interrupted one is retried at the next chance, at most every fifteen minutes. @@ -3364,19 +3379,15 @@ node's partial upload resumes it (§8.5). like a member sending by hand and gives it back, so a family's daily backups never occupy the node's upload pool ahead of a person. -**Where.** The member chooses the group (one per phone) and a folder among -those that are writable, available and shown by the group's Photos tab — a -folder outside those would take the photos and show them nowhere. Inside it, -each photo goes under `YYYY/YYYY-MM` from when it was taken, because an album is a +**Where.** Under `<folder>/<account>-photos` of the destination, each photo +goes under `YYYY/YYYY-MM` from when it was taken, because an album is a directory (§9.9) and one folder of twenty thousand is a slow album. Albums on the phone are chosen too; the camera alone is the default, because screenshots and saved images are where photos nobody meant to share live. **By default the photos already on the phone are sent, newest first**, then each new one; "from -now on" is an option. A confirmation is drawn **when the destination or the +now on" is an option. A confirmation is drawn **when the backup starts or its starting point changes, never per run and never for a change of albums alone**: -it names the group, its owner, its member count, the folder, the count and size -about to go, and says that members can download them and that what they -downloaded cannot be taken back. +it names the folder and the count and size about to go. **Additive by construction.** The backup never deletes, renames or replaces anything on the node: `photo-sync.js` reaches no such operation @@ -3419,15 +3430,8 @@ path, additive, once a day, the page doing the sending and the phone handing bytes over by token (`/phonesync/<token>`, `phonesync/` in the Android package, `phone-sync.js` on the page). Messages follow the same design. -**Only a group the person is alone in.** What a group's folder holds every -member can read, and an address book is not the group's. The set-up offers -only groups whose member list is this account and nobody invited, and every -run asks the hub again before reading anything: somebody who joins later stops -the backup (`not_private`, a lasting refusal said once) rather than reading -every copy from then on. Any writable folder of that group is offered, not -only the ones the Photos tab shows. - -**Where.** `<folder>/<account>-contacts/`, made if missing. Each copy is a new +**Where.** `<folder>/<account>-contacts/` of the destination every kind shares +(§9.12), checked at every run the same way. Each copy is a new file named for when it was taken (`contacts-2026-10-10-0900.vcf`), never a replacement: restoring is importing the newest one, and an older one is there if a phone sync went wrong. |