Seeing people vs. using modules: member visibility as its own axis

[ulsklyc]

Split out of #869 so the part that is not built has an address of its own. The other two thirds of that thread shipped in v2.62.0; this one was deliberately deferred, and leaving it inside a mostly-answered thread means it reads as forgotten rather than as postponed.

The question

Today, module permissions and being visible as a person are the same thing. If you can open Shopping, you can see that everyone else in the household exists. @aizaimosaou put it plainly in #869: using a shared shopping list does not imply needing to know who else lives here, let alone seeing them offered in every picker.

Those are two different axes and Yuvomi currently has only one.

Why it is not a small change

The household being one visible set is assumed in more places than the permission system:

• assignment pickers (tasks, meals, housekeeping)
• the family widget and the member list
• mentions
• split expenses, where a guest is already a partial exception
• calendar sharing and the "assigned to" colour
• points, statistics and rewards

Any of those, given a member who is deliberately invisible to another, has to answer what it shows. A half-built version is worse than none: a person who is hidden in the picker but visible in a mention is not hidden, they are inconsistently visible, which is the kind of privacy that fails exactly when someone relies on it.

What is deliberately not in scope

Per-member navigation, per-member widget sets and hidden sub-features. That was answered in #869 and the answer stands: each member can already hide modules and arrange their own dashboard, and making the shape of the app a per-member configuration surface is a cost paid on every future feature, not once.

What would help

Concrete situations rather than a model. If you have a household where this bites, the useful thing to post is who should not see whom, and in which screen it went wrong - a picker, a mention, a statistic. The design follows from a handful of real cases much better than from a permission matrix drawn in the abstract.

For reference: docs/SCOPE.md has what the project rules out. This is not on that list. It is open, it is wanted, and it is unscheduled.

[ulsklyc]

A direction for this, decided rather than deferred - and one thing still genuinely open at the end.

The decision: member visibility stays a property of a person, not a relationship between two people.

What that rules out is a "who may see whom" matrix. What it rules in is a third kind of account alongside the two that already exist.

Why, since this was the real fork

Yuvomi has answered this shape of question twice already, and both answers work the same way: a person is in a table, and a global property follows from it. Household staff are filtered out of the member list (/family/members carries WHERE NOT EXISTS (SELECT 1 FROM housekeeping_workers …)), and split-expense guests get access_scope = 'split_guest' from a CASE over split_expense_guest_users. A third value is consistent with that grain. A pairwise matrix sitting next to it would be a second, contradicting system.

Scale is the other half. Eight people are 56 relationships, and the person maintaining them is a parent at the kitchen table, not an administrator. @aizaimosaou wrote it plainly in #869 - "I don't think Yuvomi needs enterprise-style permissions" - and I agree. Family apps generally separate kinds of account; pairwise visibility belongs to products where relationships are the point.

And there is a failure mode I want to name, because it is the one that would actually hurt: half-built is worse than not built. Someone hidden from a picker but visible in a mention is not hidden, they are inconsistently visible - and that kind of privacy fails exactly when a person is relying on it.

Two conditions attached to building it

One rule, one place. Every list of people goes through a single predicate, the way document visibility goes through documentVisibleSql(). This is not theoretical: a review this week found two paths to the same documents giving two different answers, because one of them inlined its own check.

All of it, or none of it. The list in the opening post is the acceptance criteria, not a wishlist: assignment pickers, the family widget, mentions, split expenses, calendar sharing, points, statistics. A partial rollout is the failure mode above.

What this does not cover, deliberately

"My partner can see my cycle data, my mother cannot" is a different axis - content visibility - and it already exists per record: visibility on health and budget rows, family_document_access for documents, per-metric defaults in Settings → Health since v2.62.0. Keeping the two apart is the whole point of splitting this discussion out of #869.

Still open, and it is the part I cannot decide alone

What the third kind of account should actually be. "Uses shared modules, does not appear in member lists" is one shape; there are others.

@aizaimosaou - your question from 26 August is still the one I need answered, and now it has a place to land: who should not see whom, and in which screen did it go wrong? A picker, a mention, a statistic. Two or three real situations will shape this better than any permission model I could draw in the abstract, and I would rather build from your household than from my guess about it.