Better privacy defaults for new household members

[aizaimosaou]

I’ve been using Yuvomi recently and really like the project, especially the idea of keeping family data self-hosted and private.
There is one thing about the current household model that feels a little uncomfortable to me though: it seems to assume that everyone inside the same household already has a very high level of trust.
That probably works fine for a small family, for example two parents and young children. But once more people are added, things get more complicated very quickly.
A household might include a partner, parents, adult children, siblings, relatives, or other people. They can all be part of the same family without necessarily needing to know everything about each other.
For example, I may want to share cycle or health information with my partner, while also having my parents or siblings in Yuvomi. My partner doesn’t necessarily need to see that those accounts exist, see their names or other information, or even know how many other people are in the household.
As the household grows, I think privacy between members becomes more important, not less.
The biggest issue for me right now is the onboarding of new members.
From what I can see, a newly invited member starts with fairly broad access, and the admin can restrict it afterwards. I would feel much safer if this worked the other way around.
A new member could start with a predefined permission template, for example:
Minimal access
Partner
Child
Relative
Guest
Full access
The admin could choose or adjust the template before sending the invitation, so the correct permissions are already active the first time that person logs in.
I think this is important because permissions can always be opened later, but once someone has already seen private information, that can’t really be undone.
I’d also love to see member visibility separated from normal module permissions.
Being allowed to use Calendar, Tasks or Shopping doesn’t necessarily mean someone should automatically see every other household member.
Something as simple as:
This member can see:

[x] Me
[x] Alice
[ ] Parents
[ ] Siblings
[ ] Other relatives
would already make a big difference.
Longer term, it would also be useful to separate:
Who can I see?

Which modules can I use?

Whose data can I see inside those modules?
For example, someone could be allowed to see another family member’s calendar and shopping items, but not their health, cycle, budget or documents.
I don’t think Yuvomi needs enterprise-style permissions. I actually like that the project is simple and family-focused.
I just think the current model treats the whole household a little too much like one fully trusted group.
Real families often have different trust boundaries between different people, especially as the number of members grows.
A safer default might simply be:
new members start with minimal access, and sharing is added gradually when needed.
I think that would fit Yuvomi’s privacy-focused philosophy really well.
Thanks for building the project — I’m enjoying it so far.

[aizaimosaou]

I also realized that this privacy issue is closely related to usability.
Right now, Yuvomi seems to expose a fairly large part of the application to every household member, and then expects each person to configure what they need afterwards.
For technical users that may be fine, but for many family members it can be quite overwhelming.
For example, one person may only want to use cycle tracking. Another may only want to record their weight and follow their weight-loss progress. Someone else may only care about the family calendar.
Those users do not necessarily need to understand the rest of Yuvomi at all.
This becomes especially noticeable with parents or family members who are not very comfortable with smartphones.
A very realistic situation is:
“My son, I don’t really understand this screen. Can you set it up for me?”
At that point, I would much rather configure everything for them in advance than try to explain a complicated menu structure over the phone on a six-inch screen.
That is another reason why I think member templates could be useful.
A template should perhaps not only define permissions, but also the actual experience that member sees:
which sections are visible
which items appear in the navigation
which widgets appear on the home screen
which features are hidden completely
which sub-features are enabled
For example, a “Weight Management” template could show only:
Home
Health
Weight
Weight history
Progress
while a “Cycle Tracking” template could show only:
Home
Health
Cycle
The rest of the application could simply stay out of the way.
I also think some of the current information architecture could be simplified.
For example, cycle tracking feels more like a part of Health than a completely separate top-level concept.
Something like this might feel more natural:
Health
├─ Overview
├─ Weight
├─ Cycle
├─ Medication
└─ Other health features
But enabling “Health” should not necessarily mean enabling every feature underneath it.
An administrator should be able to choose:
Health
[x] Weight
[ ] Cycle
[ ] Medication
[ ] Other health features
for one member, and a completely different combination for another.
I think this is important because a member’s role and a member’s actual use case are not the same thing.
“Mother”, “partner”, “child” or “relative” describes who that person is.
It does not tell Yuvomi what that person actually wants to use.
A better model might be:
Role:
Mother

Experience template:
Weight management
or:
Role:
Partner

Experience template:
Cycle tracking
The administrator already knows what that person needs, so it would be much easier if the administrator could prepare the experience before sending the invitation.
Then the first time that person logs in, they see a simple interface that already makes sense for them.
To me, this connects directly with the privacy discussion:
people should not only avoid seeing data they do not need — they also should not have to see features they do not need.
Yuvomi can still contain many powerful modules, but each household member could have a much simpler and more personal view of the same system.

[aizaimosaou]

A couple of additional thoughts about onboarding and navigation
I had two more thoughts after using the app a little more.
The first one is about first-time onboarding.
Right now, a new user is introduced to a fairly large application immediately. But in reality, many family members may only want one or two things from Yuvomi.
One person may only want cycle tracking.
Another person may only want to record their weight and follow their weight-loss progress.
Someone else may only care about the family calendar, shopping, or kitchen features.
For those users, most of the rest of Yuvomi is simply not relevant.
I think it could be much friendlier if, before entering the main app for the first time, Yuvomi asked something very simple:
What would you like to use Yuvomi for?
For example:
Health
Kitchen
Calendar
Tasks
Shopping
Documents
...
If the user selects Health, Yuvomi could then ask one more simple question:
What are you interested in?

[ ] Weight
[ ] Weight-loss progress
[ ] Cycle tracking
[ ] Medication
[ ] Other health features
After confirming, the app could show something like:
Setting up Yuvomi for you…
and then open a version of the interface that already reflects those choices.
I think this would be especially useful for parents, older family members, or simply people who do not enjoy configuring apps.
Sometimes the real situation is just:
“I don’t really understand this screen. Can you set it up for me?”
For those users, an administrator could still prepare the experience in advance.
For everyone else, the user could make these choices themselves during first login.
So I can imagine both approaches being useful:

1. The administrator prepares it for the member

or

2. The member chooses what they want during first-time onboarding
   The important part for me is that a user should not have to understand the whole Yuvomi application before they can start using the small part they actually need.
   The second thought is about mobile navigation.
   I think the bottom navigation should adapt to the choices the user made during onboarding.
   For example, if someone says that they mainly want to use Health and Cycle Tracking, I do not think their bottom navigation should still prioritize unrelated defaults such as Calendar, Tasks or Kitchen.
   It could instead become something closer to:
   Home | Cycle | + | More
   If they selected Weight and Cycle:
   Home | Weight | Cycle | + | More
   In other words, the bottom navigation could feel like a result of what this particular user chose, rather than a small representation of everything Yuvomi can do.
   I think the + button could also become contextual.
   For a user mainly interested in Health, pressing + could prioritize actions such as:
   Record weight
   Add cycle entry
   Add medication
   Add health record
   And if some Health features have not been enabled yet, it could also make it easy to add them:
   Add feature

Weight
Cycle tracking
Medication
...
Features the user did not choose do not necessarily need to disappear completely.
They could stay under More, where they are still discoverable without taking space in the main navigation.
I think this would also help reduce menu depth.
For example, it makes sense structurally for Cycle to belong under Health:
Health
├─ Weight
├─ Cycle
├─ Medication
└─ ...
But someone who uses Cycle every day should not necessarily have to navigate through:
Health → Cycle → Record
every single time.
The internal information architecture can have a hierarchy, while the everyday interface can still provide direct shortcuts to the features that person actually uses.
Especially on a small phone screen, every additional menu level adds a little more friction.
To me, the ideal experience would be:
Yuvomi can remain a large and capable application, but each individual member should only need to interact with the small part of it that matters to them.

I'm really excited. There is really a lot of room for the future development of this software. I hope my suggestion will be answered, and I hope I can continue to discuss it

[ulsklyc]

Thank you for writing this up so carefully - and for separating the three questions, because they really are three, and they have very different answers.

Let me start by confirming the part you inferred from the outside, because you got it exactly right, and the reason is worth stating.

Yes, a new member starts with full access to every module. Permissions are stored sparsely (access_permissions): only deviations from the default are written, and a missing row means write for a module, allow for a widget. So an account with no rows configured can see everything.

That was a deliberate decision - but for a different question than the one you are asking. It came with migration v74, which introduced the permission system into installations that already had members. Storing sparsely meant those households behaved exactly as before after upgrading, instead of everyone waking up locked out of a system they had been using for months. That is the right call for existing data.

It then silently became the answer for every future invitation too, and that is not the same question. Your sentence is the argument: permissions can always be opened later, but once someone has seen private information, that cannot be undone. I agree, and I think the invite path should get its own answer rather than inheriting the migration's.

The good news on templates: half of the machinery already exists. access_permissions has a subject_type of either role or user, and resolution runs role profile first, member override second. So per-role defaults are already a real, stored concept - there are seven family roles (dad, mom, parent, child, grandparent, relative, other). What is missing is not the storage but two things: a default that is restrictive rather than empty, and the ability to choose the profile before the invitation goes out, so it is already in force at first login. That is a much smaller change than it looks from the outside.

Where I want to be careful is the boundary you drew yourself: "I don't think Yuvomi needs enterprise-style permissions." I agree, and I would add a specific version of it. Your second and third comments describe something bigger than permissions - per-member navigation, per-member widgets, per-member sub-features, an onboarding wizard, a contextual FAB, and Cycle moved under Health. Each is defensible. Together they are a different product: one where every member sees a different app, and where every future feature has to answer "which experience templates does this appear in?" That is a cost paid on every subsequent change, not once.

So my honest split:

Worth doing, and close to the existing grain

• Restrictive defaults for newly invited members, chosen at invite time from the role profiles that already exist.
• Making the role profiles visible and editable as templates rather than an implicit fallback.

Worth discussing separately, because it is its own axis

• Member visibility as something distinct from module permissions - your "who can I see?" question. Today those are genuinely conflated, and you are right that using Shopping does not imply needing to see that everyone else exists. This one I would rather get right than get soon: it touches assignment pickers, the family widget, mentions, split expenses and calendar sharing, all of which currently assume the household is one visible set.

Not planned as described

• Per-member navigation, per-member widget sets and hidden sub-features as an "experience template". Yuvomi already lets each member hide modules and arrange their own dashboard; that covers the "I only want cycle tracking" case from the member's side, without making the app's shape a per-member configuration surface.

On Cycle under Health specifically: that is an information-architecture question worth its own discussion, and it is not blocked by any of the above.

If you want to take one of these forward, the invite-time defaults are the one I would start with - it is the smallest change with the largest share of your original concern, and it does not require deciding the visibility axis first. Would that match what you are actually running into day to day, or is the member-visibility part the one that bites?

[aizaimosaou]

Thank you for the detailed reply. After thinking through it again, I realized that some of my earlier wording may have made the idea sound more complicated than I actually intended.

Most of these thoughts came gradually from using Yuvomi in practice. I am not asking you to redesign the project around them, nor do I expect them to be implemented together. I mainly want to clarify what I meant, so you can decide which parts, if any, fit Yuvomi and its long-term direction.

1. Restrictive defaults for newly invited members

You wrote that:

“the invite path should get its own answer rather than inheriting the migration's.”

and suggested:

“Restrictive defaults for newly invited members, chosen at invite time…”

I agree with this.

The core of my original concern was simply:

A newly invited member should start with the minimum reasonable access, rather than seeing everything by default.

When I previously mentioned pre-configuration by an administrator, I did not mean that the administrator should permanently maintain a different version of Yuvomi for every member.

Your invite-time restrictive profile sounds like a very reasonable first step.

2. A clearer distinction between personal and household data

After using Yuvomi for a while, I started thinking that there may be value in distinguishing more clearly between a personal space and a household space.

Conceptually:

Personal space
→ join a household
→ participate in household sharing

Joining a household would not automatically make a person's private data household data.

For example, things such as cycle tracking, personal health records, or private documents naturally begin as personal data.

Things such as household expenses, shopping lists, chores, or a shared family calendar naturally make more sense as household data.

So I am not suggesting two different applications. I am thinking more about making the boundary between “mine” and “ours” clearer.

3. Member discoverability

You described:

“Member visibility as something distinct from module permissions.”

This is one of the privacy boundaries I was trying to describe.

Being in the same household does not necessarily mean that every member needs to be discoverable by every other member.

For example, if A is allowed to see B but not C, then ideally C should not indirectly appear to A through Health, assignment pickers, mentions, calendars, expense splitting, or other member selectors.

I understand your point that this touches many existing assumptions in Yuvomi, including:

“assignment pickers, the family widget, mentions, split expenses and calendar sharing”

So I understand that this is not simply a matter of hiding an avatar in one screen.

My point is only that member discoverability itself seems like a meaningful privacy boundary.

4. Seeing a member and seeing that member's data are two different things

You also wrote:

“using Shopping does not imply needing to see that everyone else exists.”

I agree, and I would separate the next layer as well:

Knowing that another member exists should not automatically grant access to that member's private data.

For example:

A, B and C belong to the same household.

A's cycle data
→ shared with B
→ not shared with C

B may know that A exists and may see the specific information A has chosen to share.

C may also know that A exists, but that alone should not give C access to A's cycle or health data.

So I now see these as two separate questions:

1. Which members can I discover?
2. Which data has each member explicitly shared with me?

Data sharing itself might be private, shared with one person, shared with several specific people, or shared with the household.

5. I did not mean a permanently different Yuvomi experience for every member

You wrote:

“Together they are a different product: one where every member sees a different app…”

and mentioned that per-member navigation, widgets and sub-feature templates are not planned as described.

I think my earlier wording caused a misunderstanding here.

I was not suggesting something like:

one maintained interface for Dad
another for Mom
another for a child
another for a grandparent

My idea was much lighter: a simple first-run guide.

For example, on first login Yuvomi could ask:

“What would you like to use Yuvomi for?”

The user could select a few broad areas such as Health, Calendar, Tasks, Kitchen, Documents, or Shopping.

Yuvomi could then use the customization mechanisms that already exist — hiding modules, arranging navigation, and so on — to provide a simpler starting point.

After that, the user would continue managing those choices themselves exactly as they do today.

So the purpose is only to help a new user find the parts of Yuvomi they actually need, not to create a permanent per-member experience-template system.

6. Cycle under Health

You wrote:

“Cycle under Health specifically: that is an information-architecture question worth its own discussion.”

I agree.

My original reason for considering Cycle under Health was mainly related to simplifying the top-level navigation for new users.

It is not a strong requirement. If Cycle works better as its own top-level area, I have no problem with that, and it can remain a separate discussion.

7. A longer-term thought about different sharing contexts

Using Yuvomi also made me realize that real relationships do not always fit into one universally visible household.

For example, someone might have:

their own personal space
a household with their partner
a relationship with their parents
a temporary planning space with friends
a collaboration space with colleagues

A friend invited to help plan a trip obviously should not gain visibility into that person's household members, family finances, health information, or private documents.

I am not suggesting that Yuvomi needs multiple households or arbitrary groups now. That would clearly be a much larger change.

Even within the current single-household model, being able to control:

which members a person can discover
+
which data those members have shared with that person

would already address much of the practical privacy concern I am describing.

Overall, what I am trying to describe is this:

A user starts as an individual. A household is a sharing relationship added later. Household membership should not automatically imply universal member discoverability or access to private data. Member discoverability and data sharing are separate layers.

And the first-run navigation idea is simply intended to make Yuvomi easier for ordinary users to approach; it is not intended to create a permanently maintained set of different Yuvomi experiences.

These are observations from using the software rather than a request for a particular architecture. You know Yuvomi's internal structure, maintenance cost, and long-term direction much better than I do, so I am happy for you to take whichever parts are useful and disregard the rest.

[ulsklyc]

Decided, and it lands close to what you proposed.

The invite path gets its own answer, and the answer is the form. When an admin sends an invitation, the starting permissions will be a visible choice with a restrictive preselection, shown next to the family role that is already there. Nothing changes for existing households or existing accounts: what changes is the default state of a form, not a stored default, so no installation wakes up different after an update.

Why this shape rather than the other two I considered:

• Not restrictive role profiles shipped by default. That would solve it system-wide and break the promise migration v74 made. Households that have been running for months would find members locked out of a system they were using. Shipping them only for new installations would give the same field two meanings depending on install date.
• Not a new permission concept. The machinery you correctly guessed at is all there: subject_type of role or user, role profile first and member override second, and the invite form already carries the family role. What was missing was never storage. It was that the preselection is implicitly "everything" and nobody sees it. Making it visible and starting it narrow is the whole change.

So the admin picks the role as today, sees what that role currently grants, and can widen it in one click before sending. Permissions can still be opened later, which was your argument, and now the widening is a decision somebody makes rather than one nobody notices.

Unchanged from my earlier reply: member visibility as an axis separate from module permissions stays a real open question and a separate one. Per-member navigation, per-member widget sets and hidden sub-features remain not planned as an experience-template system.

My question from last week still stands and is now the more useful one: is member visibility the part that actually bites you day to day, or was onboarding the sharp edge? The first is the harder design and I would rather start it from a real case than from a good argument.