[US-7] As a user, I want my data organized by default into Private, Protected, and Public stores, so I have a built-in mental model of who can see what.

angie commented

2026-08-21 16:52:22 +02:00

Owner

citing @yousef This makes the permission level the "primary hierarchy attribute" of a document, is that really what we want? A few things to think through:

What happens to a project that has mixed visibility; private drafts, team docs, a public spec? Does it get split across three silos, or is there still one place where "Project X" lives?
How do per-doc exceptions work ("share just this file with one person")? And if exceptions exist, can users still trust that the store name tells them who sees what?

citing @yousef This makes the permission level the "primary hierarchy attribute" of a document, is that really what we want? A few things to think through: - What happens to a project that has mixed visibility; private drafts, team docs, a public spec? Does it get split across three silos, or is there still one place where "Project X" lives? - How do per-doc exceptions work ("share just this file with one person")? And if exceptions exist, can users still trust that the store name tells them who sees what?

angie commented

2026-08-21 16:52:45 +02:00

Author

Owner

Citing @jeremiah As a user, this story is not how I think about organizing my data. Often a document starts private to me, is then shared selectively, and then shared broadly. Access is staged without duplicating the document or moving it.

angie commented

2026-08-21 17:36:05 +02:00

Author

Owner

In our last meeting, this was discussed as being part of NextGraph requirements.

angie changed title from ~~[US-7]~~ to [US-7] As a user, I want my data organized by default into Private, Protected, and Public stores, so I have a built-in mental model of who can see what.

2026-08-21 18:07:02 +02:00

niko commented

2026-08-22 17:44:05 +02:00

Owner

To answer @yousef first question : let's say the project is materialized by a Group Store where several users are members. A Group store behaves like the prottected store: it can handle various types of permissions. By default, all the documents of the Group store will be shared with all its members. Each document inherits permissions from the store. Then each document can separately have other permissions. so the use cases you mention are supported. (private draft, public doc...). There is one place where Project X lives, it is its group store.

Per-doc exceptions work with 2 mechanisms: a doc can inherit its permissions from the store, and add more permissions (additive only). In order to remove permissions, we technically have to remove the inheritance from the store, and then only add the specific perms this doc needs.

Maybe we didn't explain well the concept of stores (but it is explained in the NG requirements doc and in the official docs of NG at docs.nextgraph.org). The private store contains all the documents the user wants to wync only with themselve (between their devices) but will never share with anyone. It is not possible to add permissions on a document that is in this Private store. This is where we store contacts, emails, and any sensitive doc the user specifically knows he will never share. This concept has to surface to the UX. Yes it might be a new UX for some, but that's the goal. We want the user to understand this Store is safe. Nothing can escape it. If a document that is in Private store needs to shared later on, it can be moved to Protected store, or any group store. This is an easy action, but an explicit one.

The public store is to be understood as "my public profile", "my blog", "my website". This is another corner of my data space, where I know I am presenting some content to the world. It is part of the social features of ELFA. In this store every document is public, except the drafts the user or any editor is working on. But the drafts are also saved there, and as soon as they are published, they will be public. There is no way to select other permissions here.

The protected store is hosting any document I create and that I want to share with others, as well as any document that was shared with me by someone else, on a case by case basis. I can organize my protected store as I want, and nobody will every see the whole protected store from its root. This is only for me. But the store contains all the shared - isoled - docs.

Then comes the Group stores. At first the user does have any group store, but they can create new groups. I explained above how group permissions are working. They behave like a shared folder. A group has a name, and a hierarchy of documents, curated in common with its members.

Finally, each person I interact with in DMs (one-on-one) has an entry in the messenger, and in addition it has a Dialog store. it contains all the DMs, and also all the docs and links shared between those 2 users. It is similar to when you enter a DM chat in Signal and you click on "all media", but instead of jsut being the list of images and videos shared in the chat, the users have a real store where they can curate documents there. It is like a group, but you can't add more people, and it is created at the first DM you exchange with this person.

All the stores, and all the documents, can have an associated chatroom where all the editors of the doc can chat. This is how DMs, group chat, are implemented. Not all docs have the chatroom activated.

To answer @yousef first question : let's say the project is materialized by a Group Store where several users are members. A Group store behaves like the prottected store: it can handle various types of permissions. By default, all the documents of the Group store will be shared with all its members. Each document inherits permissions from the store. Then each document can separately have other permissions. so the use cases you mention are supported. (private draft, public doc...). There is one place where Project X lives, it is its group store. Per-doc exceptions work with 2 mechanisms: a doc can inherit its permissions from the store, and add more permissions (additive only). In order to remove permissions, we technically have to remove the inheritance from the store, and then only add the specific perms this doc needs. Maybe we didn't explain well the concept of stores (but it is explained in the NG requirements doc and in the official docs of NG at docs.nextgraph.org). The private store contains all the documents the user wants to wync only with themselve (between their devices) but will never share with anyone. It is not possible to add permissions on a document that is in this Private store. This is where we store contacts, emails, and any sensitive doc the user specifically knows he will never share. This concept has to surface to the UX. Yes it might be a new UX for some, but that's the goal. We want the user to understand this Store is safe. Nothing can escape it. If a document that is in Private store needs to shared later on, it can be moved to Protected store, or any group store. This is an easy action, but an explicit one. The public store is to be understood as "my public profile", "my blog", "my website". This is another corner of my data space, where I know I am presenting some content to the world. It is part of the social features of ELFA. In this store every document is public, except the drafts the user or any editor is working on. But the drafts are also saved there, and as soon as they are published, they will be public. There is no way to select other permissions here. The protected store is hosting any document I create and that I want to share with others, as well as any document that was shared with me by someone else, on a case by case basis. I can organize my protected store as I want, and nobody will every see the whole protected store from its root. This is only for me. But the store contains all the shared - isoled - docs. Then comes the Group stores. At first the user does have any group store, but they can create new groups. I explained above how group permissions are working. They behave like a shared folder. A group has a name, and a hierarchy of documents, curated in common with its members. Finally, each person I interact with in DMs (one-on-one) has an entry in the messenger, and in addition it has a Dialog store. it contains all the DMs, and also all the docs and links shared between those 2 users. It is similar to when you enter a DM chat in Signal and you click on "all media", but instead of jsut being the list of images and videos shared in the chat, the users have a real store where they can curate documents there. It is like a group, but you can't add more people, and it is created at the first DM you exchange with this person. All the stores, and all the documents, can have an associated chatroom where all the editors of the doc can chat. This is how DMs, group chat, are implemented. Not all docs have the chatroom activated.

niko commented

2026-08-22 17:50:44 +02:00

Owner

To answer the comment of @jeremiah I think we provide the same kind of features and flow. You can modify the permissions of a document, gradually expending its reach. You do not have to duplicate documents for that.
Most of your documents will be created in the protected store (it should be the default store for any new document). At first they do not have any additional permissions and only you can see them. Then you can add people.
The only specificity with NG is the private store. If you create something there, it won't be sharable. This is a feature. Then if you want to share it (because you changed your mind. when you created it, you wanted this doc to be secret) you will have to move it to the protected store first. This is one easy action. Technically the private store and the other stores are not implemented exactly the same, and the private store preserves privacy more strongly as it doesn't share any metadata with other brokers. In terms of UX, it think it is interesting to propose to users, a "secret vault" where they know, nothing can escape "by mistake". This private store is also what will be used for the password manager I would like to offer one day as an additional app in ELFA.

To answer the comment of @jeremiah I think we provide the same kind of features and flow. You can modify the permissions of a document, gradually expending its reach. You do not have to duplicate documents for that. Most of your documents will be created in the protected store (it should be the default store for any new document). At first they do not have any additional permissions and only you can see them. Then you can add people. The only specificity with NG is the private store. If you create something there, it won't be sharable. This is a feature. Then if you want to share it (because you changed your mind. when you created it, you wanted this doc to be secret) you will have to move it to the protected store first. This is one easy action. Technically the private store and the other stores are not implemented exactly the same, and the private store preserves privacy more strongly as it doesn't share any metadata with other brokers. In terms of UX, it think it is interesting to propose to users, a "secret vault" where they know, nothing can escape "by mistake". This private store is also what will be used for the password manager I would like to offer one day as an additional app in ELFA.

niko referenced this issue

2026-08-22 17:56:18 +02:00

[US-10] As a user, I want every one-on-one conversation to get its own Dialog store automatically, so documents shared with one person stay scoped to that relationship. #14

niko added this to the Product Design PDR project

2026-10-13 13:44:54 +02:00

Rows
Columns

[US-7] As a user, I want my data organized by default into Private, Protected, and Public stores, so I have a built-in mental model of who can see what. #6