Feature: Ambient proximity + location detection for auto-logging interactions

Mark commented

2026-05-28 01:13:48 +00:00

Owner

The phone passively detects who you're with and where, building a timeline without manual entry.

Data sources (all opt-in, per-source permission)

Location history: places visited together ("you and Alice were at The French Restaurant on Saturday")
Calendar overlap: shared events in calendars ("you and Bob were both at the conference")
Bluetooth proximity: known devices in range ("you and Sam were together for 3 hours")
WiFi network: same network = likely together (home, office)
Photo location: photos taken at same place/time as another person (shared event, dinner)

What it surfaces

"You were at the same place as Bob for 2 hours on Tuesday — log a catch-up?"
"You and Alice both had Saturday evening free and were near each other — dinner?"
Auto-suggested interaction drafts: place, time, duration, who

Privacy

All on-device processing
Per-source permission toggles
Never shares location with anyone — just makes local correlations
Opt-in entirely, off by default

Value

Catches the interactions you'd never remember to log — the coffee run with a colleague, the chance meeting at the store, the family dinner. The app fills in the blanks.

The phone passively detects who you're with and where, building a timeline without manual entry. ## Data sources (all opt-in, per-source permission) - **Location history**: places visited together ("you and Alice were at The French Restaurant on Saturday") - **Calendar overlap**: shared events in calendars ("you and Bob were both at the conference") - **Bluetooth proximity**: known devices in range ("you and Sam were together for 3 hours") - **WiFi network**: same network = likely together (home, office) - **Photo location**: photos taken at same place/time as another person (shared event, dinner) ## What it surfaces - "You were at the same place as Bob for 2 hours on Tuesday — log a catch-up?" - "You and Alice both had Saturday evening free and were near each other — dinner?" - Auto-suggested interaction drafts: place, time, duration, who ## Privacy - All on-device processing - Per-source permission toggles - Never shares location with anyone — just makes local correlations - Opt-in entirely, off by default ## Value Catches the interactions you'd never remember to log — the coffee run with a colleague, the chance meeting at the store, the family dinner. The app fills in the blanks.

Mark added the

blocked:needs-decision

label

2026-05-28 01:13:48 +00:00

Mark commented

2026-05-28 03:25:18 +00:00

Author

Owner

⏸ Needs Decision

Blocking factors:

Didn't meet auto-approve criteria — scope=medium, risk=medium, spec=partial

Scope: medium Risk: medium Spec: partial Type: feature
Summary: Feature: Ambient proximity + location detection for auto-logging interactions
Suggestion: needs investigation
Rationale:

Action: Review each blocking factor above. Remove blocked:needs-decision label to route back to triage.

## ⏸ Needs Decision **Blocking factors:** - **Didn't meet auto-approve criteria** — scope=medium, risk=medium, spec=partial --- **Scope:** medium **Risk:** medium **Spec:** partial **Type:** feature **Summary:** Feature: Ambient proximity + location detection for auto-logging interactions **Suggestion:** needs investigation **Rationale:** **Action:** Review each blocking factor above. Remove `blocked:needs-decision` label to route back to triage.

Mark commented

2026-05-28 07:23:50 +00:00

Author

Owner

⏸ Needs Decision

What needs to be decided?

Should this be split into smaller sub-issues? If yes, remove the blocked:needs-decision label and the triage will create a decomposition issue.
Do you want to proceed despite the risk? If yes, remove the blocked:needs-decision label and the triage will approve it.

Blocking factors:

Large scope — may need decomposition into phased sub-issues
High risk — needs human sign-off before proceeding

Scope: large Risk: high Spec: partial Type: feature
Summary: Add on-device ambient proximity and location detection from multiple sources (Bluetooth, WiFi, calendar, location, photos) to auto-suggest interaction drafts that the user can review and log.
Suggestion: Phase the implementation: (1) data schema + Dexie stores for raw events and suggested drafts; (2) per-source detector modules as plugins (start with calendar overlap and WiFi as simplest); (3) correlation engine that fuses sources into interaction candidates; (4) suggestion UI with approve/decline/dismiss pattern. Per-source Capacitor native plugins needed for Bluetooth, location, and calendar access.
Rationale: 15+ files needed: new IndexedDB stores, detector modules, correlation engine, permission UI, suggestion feed page, Capacitor plugin wrappers for each data source. Risk is high due to native permission handling (location, Bluetooth), privacy-sensitive data flows, battery-life considerations from polling, and new IndexedDB schema migration. Spec alignment is partial because the feature extends the app in an ambient/detection direction that is adjacent to but not described in the current spec — the spec covers manual interaction logging but not automatic detection.

To unblock: Remove the blocked:needs-decision label. The triage will apply the appropriate outcome based on your choice above.

## ⏸ Needs Decision **What needs to be decided?** - **Should this be split into smaller sub-issues?** If yes, remove the `blocked:needs-decision` label and the triage will create a decomposition issue. - **Do you want to proceed despite the risk?** If yes, remove the `blocked:needs-decision` label and the triage will approve it. **Blocking factors:** - **Large scope** — may need decomposition into phased sub-issues - **High risk** — needs human sign-off before proceeding --- **Scope:** large **Risk:** high **Spec:** partial **Type:** feature **Summary:** Add on-device ambient proximity and location detection from multiple sources (Bluetooth, WiFi, calendar, location, photos) to auto-suggest interaction drafts that the user can review and log. **Suggestion:** Phase the implementation: (1) data schema + Dexie stores for raw events and suggested drafts; (2) per-source detector modules as plugins (start with calendar overlap and WiFi as simplest); (3) correlation engine that fuses sources into interaction candidates; (4) suggestion UI with approve/decline/dismiss pattern. Per-source Capacitor native plugins needed for Bluetooth, location, and calendar access. **Rationale:** 15+ files needed: new IndexedDB stores, detector modules, correlation engine, permission UI, suggestion feed page, Capacitor plugin wrappers for each data source. Risk is high due to native permission handling (location, Bluetooth), privacy-sensitive data flows, battery-life considerations from polling, and new IndexedDB schema migration. Spec alignment is partial because the feature extends the app in an ambient/detection direction that is adjacent to but not described in the current spec — the spec covers manual interaction logging but not automatic detection. **To unblock:** Remove the `blocked:needs-decision` label. The triage will apply the appropriate outcome based on your choice above.

Mark commented

2026-05-31 05:42:02 +00:00

Author

Owner

Settings UI stubs implemented (commit 3f50596):

Added proximitySettings to store with 5 toggles
Location History, Bluetooth Proximity, WiFi Network, Calendar Integration, Photo Location
All default to disabled (opt-in)
Settings page shows Privacy-style section

Ready for native implementation when platform APIs are available.

Settings UI stubs implemented (commit 3f50596): - Added `proximitySettings` to store with 5 toggles - Location History, Bluetooth Proximity, WiFi Network, Calendar Integration, Photo Location - All default to disabled (opt-in) - Settings page shows Privacy-style section Ready for native implementation when platform APIs are available.

Mark added

triage-approved

and removed

blocked:needs-decision

labels

2026-06-06 15:44:39 +00:00

Mark referenced this issue from a commit

2026-06-08 01:11:50 +00:00

feat: proximity detection settings UI stubs (part of #43)

Mark

2026-06-15 04:50:40 +00:00