Private contents in a shared installation

[Malte]

I thought you may want to think with me into the direction of realizing something like _private "Notes"_ with DeepaMehta 4.1. Assuming them as exemplary for private contents in DeepaMehta per se, this could be a real breakthrough for using DeepaMehta also as a multi-user environment.

[jri]

Maltes Input

Background in #405 I said: I wouldn't mind if all contents where still publicly readable, if I just wouldn't need to bother with the topicmaps/views of other users after I am logged in. First I thought it may be way more in reach for us now to realize personal views on public contents first and personal contents in public views then. But after thinking about it for a while, this is probably not the best step to take right now, since more fundamental paths need to be laid out first and those may render my concern unproblematic.

Maybe the question which gets us 2 steps forward here might be something like: "What would be the easiest way to realize e.g. private "Notes"? (because a "Note" is an exemplary TopicType? which might all workspaces will share but any user other wants to take private ones first and share them later.

Practically thinking from DM4.1 and ACL of how it is now (with Workspaces and Types at the core), I was thinking about if there might be a way into the direction like, let's say "user workspaces", where:

• each user becomes it's own "user workspace" which is not viewable and can not be revealed by any other user
• each of that "user workspaces" becomes the TopicType? "Note" assigned (so it is shared among many workspaces and thus many members)
• but in each "workspace" the TopicType? Note is available with different Access Control Entries?

That way anyone could have _private notes_ in his/her "private" workspace and still creating/editing and sharing public "Notes" while being in active in a e.g. "community workspace".

The interesting part for me then comes in when, from a UX perspective, we can discuss on how to make a "private note", first "shared" and then "public" (as laid out by JuergenN here).

So what are your toughts on: "What would be the easiest way to realize e.g. private "Notes"?

Thanks for sharing your thoughts on this.

[jri]

The canonical way to have real private content would be to extend DM's Access Control mechanism with the missing READ permission. Currently only WRITE and CREATE exists. READ is currently implicitly allowed, so all content are public readable. A variable READ permission is not yet implemented.

Remember ACL exists at both levels:

• at type-level (e.g. who is allowed to create an instance of that type?).
• at instance-level. Each topic/association has an individual ACL setting.

However, configuring the individual ACLs via GUI is not yet implemented. So, the default ACLs are in effect. These are aimed at collaborative work, on the basis of DM Workspaces.

So, real privacy would be achieved by:

1. introduction of the READ permission.
2. ACL configuration via GUI.

You mentioned another interesting aspect: users must not see all topicmaps but only her own ones as well as shared (and/or published) ones. Because Topicmaps of course also have individual ACLs this would not too difficult to implement. Its more or less a matter of adapting the GUI, namely the Topicmaps menu. Requirement is implementation of 1. and 2. as mentioned above.

When it comes to GUI adaption another aspect arises: the Workspaces menu. It should list only workspaces the user is a member of. And the Topicmaps menu in turn, should only list topicmaps that belong to the selected workspace (besides fulfilling the access control criteria mentioned above).

So, these GUI related things are required to be implemented:

3. restrict the items listed in the Topicmaps menu
4. restrict the items listed in the Workspaces menu

From my point of view the implementation of these 4 tasks would provide the basis for fine-grained access control and real privacy and would even improve usability and scalability (hundreds of workspaces, thousands of maps?).

[JuergeN]

Hi Malte, I agree with your effort. I would suggest to create a workspace for every user when creating the user. This workspace could be called "home (|username)" or "home of username" - as we cannot call it "private" yet due to missing ACL options.

The only user assigned to this workspace is the user itself. This workspace is the "default" workspace for every user after the login. Only the user itself can create new topics and topic types in her workspace.

Second I would per default create a "public" workspace. All users are assigned to this workspace automatictly on creation of a new user. The public workspace is also the default workspace anonymous (not loggen in) users can see (read) if not configured otherwise.

Third, for the purpose of FF-MAP, there could be community workspaces for each community, where all members of a community get assigned to, when adding themselves as a member to this community.

[jri]

Yes, a home workspace for every user is a good idea. And, as soon as the READ permission is implemented it could be a true private workspace.

Then, model-wise the question arises: how to control weather an user is allowed to join an arbitrary workspace? Instead of introducing different types of workspaces, this could be handled by terms of ACL as well. We could exploit the CREATE permission (for the moment it is applicable only for types) for that:

When a workspace's ACL contains a CREATE permission for the USER role, every (authenticated) user is allowed to join. If, on the other hand, that ACL entry is missing no one is allowed to join, what results in a home/private workspace.

So, the CREATE permission applied to workspaces could be read as "who is allowed to create a membership to that workspace?".

Together with the tasks 1. to 4. (see comment:2) this concept could be a "real breakthrough for using DeepaMehta also as a multi-user environment", as Malte put it. Real privacy included.

I'm quite eager to implement this. We could make this one main feature of the next 4.2 milestone.

[Malte]

Thanks for pickin up and bringing some substance into the case around an important question. You indirectly answered my original question to that extent, that "private notes" could/would be realized (from the technical side) through allowing users ACL'configuration on instance-level, of which I was not aware that this is possible with DeepaMehta already.

I was a bit surprised that you deleted my brainstorm wiki page, which (in contrary to a ticket) appears in the "Journal" when edited/updated. I think deletion in (trac-)wiki's is a bad practice, also because now it was impossible for me to reconstruct what I'd actually written that day, the notes are just lost.

Furthermore, since I am now listed as the "Creator" of this ticket here (which I wasnt), I hope it's OK for your when I give this ticket a title that I think is fitting/specific.

And I don't see this ticket as a the breakthrough for using DM as a multi-user environment anymore, since I also see "locked for writing" (topics) and "input validation", which are both untracked/unspecified yet, as required to get there too.

And thanks for the elaboration of this task.

I would think;

• introducing a private workspace sounds like a convenient solution
• allowing 3rd party plugins to set ACL-configurations on instance-level (via REST-API) is what we want (and which may already possible)
• if we exploit the "CREATE" permission, how users then could "Create new Workspaces"; doesn't this interfere? And is a new workspace always a "public" one?

Another question: Is it the case that a topic can be assosciated with many workspaces at the same time, thus allowing me to share an editable-note with various working-groups?

[jri]

Private and shared workspaces are finally realized in DM 4.5