Multi-user / permission support

[deajan]

So basically I wrote about this earlier in zadam's post about trilium's maintenance status.

This has been one of the major feature quite a lot of people asked for.
Making trilium multi-user friendly, eg:

• Add a permission system for notes (ie CRUD permissions)
• Add user authentiication in order to get permission on a per user basis
• Optionally add groups

The major benefit I see here is the traction that TriliumNext would get, ie it would be used in enterprise where people usually document with wiki like systems (ex docuwiki).

Someone stated in the original issue that Trilium is a PERSONAL knowledge base, but IMO tadding optional permissions wouldn't bother people who like to use it that way.
Still il would allow sharing the same knowledge base accross multiple users, personal or professionnal wise.

From a developper point of view, I think the major problem here is that notes hierarchy isn't fixed, and notes can be cloned, so the most complicated part would be to make permissions inheritance on notes that have multiple parents.
This could perhaps be solved by having a note owner, which is the only user which permissions are being inherited.
That of course would also need a way to change the ownership of the notes.

Anyway, I am really hoping this idea to get picked up, since it would probably mean way more people attracted to the project.

[rauenzi]

I think this in general is a very good idea to include. As you said, it's probably the most asked for feature from what I've seen. But even from what you've described, there's multiple ways this can be handled. We can have multiple users using the same instance but completely different databases, or we can have them split up but within the same database, or we can do as you suggest with a full permission system that would have users potentially working in the same hierarchies.

There's a lot to think about here. The simplest one to do is have multiple users on the same "instance" but using separate databases. That would still allow it to be a personal database rather than a collaboration platform that has users on the same hierarchies.

[meichthys]

An even simpler implementation may be to just allow password protecting of individual notes using a password other than the instance password. This way multiple users could share the instance password, and then still define their own passwords on portions of the hierarchy. This would allow limited collaboration (not real-time of course).

[zadam]

I'll add my 2 cents.

I'd start by gathering what use cases would Trilium Next want to target. "multi-user" or "permissions" are very generic terms which can span from very simple multi-tenancy to extremely complicated systems. It would be good to find a good balance of the most useful use cases covered, fit to the existing Trilium features / philosophy, and the implementation cost needed.

The other thought I have is this - it looks like the new org highest priority is refactoring. I'd recommend focusing on that first before tackling such major features as multi-user. It's good of course to think about the future, but not diverting attention into 10 different directions is IMHO an important consideration too.

[alrhalford]

For what it's worth, I don't think full multi-user stuff is useful. Being able to share a specific note(tree) as editable, maybe, but not fully fledged notion style support. I would be supportive of being able to export and import trees to/from some text format though, that would be nice.

[meichthys]

it looks like the new org highest priority is refactoring

could you link discussions about this?

@rmkni See here:
https://github.com/orgs/TriliumNext/discussions/26

https://github.com/orgs/TriliumNext/discussions/4

[meichthys]

I would be supportive of being able to export and import trees to/from some text format though, that would be nice.

I think we can already do this with the normal import/export feature, no?

[alrhalford]

Quite possibly, I haven't used that functionality - apologies if it is!

[maphew]

Looking for shared trees is what brought me to this thread. My use case is: the hub of my star topology is at home on my NAS, with spokes being desktop, laptop, phone, and work computers. Where I want to be is that, plus: an Trilium server that has only certain branches of my database. These branches would be used as Shared, giving me a website of my knowledgebase but not risking exposing everything should the public server be compromised.

I think this scenario could dovetail nicely with multi-user. Imagine certain branches being tagged #sync:https/hostname.net/path/ and automatically synchronized using the regular mechanism. Each sync host manages their own permissions locally no different than now, with one new password / authentication mechanism just for the sync api.

(Thinking more broadly, the destination for this imagined #syncTarget tag need not be restricted to http. e.g. it could be another sqlite db on disk, or even a 'real' rdbms like postgres, an rsync daemon, or scm like fossil or git.)

That said, as much as I would like this tomorrow! I agree the current refactoring effort should have priority.

[eliandoran]

@sigaloid , as developer of trilium.cc, what's your take on this?
Without going in too much detail, how does trilium.cc achieve multi-user support?
Is there something we can implement in the server to ease multi-user support?

[sigaloid]

Unfortunately, I don't do any real multi-user support - I simply dockerize each server and run each one separately (with separated data volumes).

I wouldn't want to have one server with multiple users anyway - the containerization is very helpful in terms of security (a vulnerability in the code base isn't remote shell - just a docker container).

side note: this is also why I've been researching alternative runtimes like deno or bun - I pay the Node runtime cost for every single container which means compute is far more than ideal. Also why I've looked into writing a Rust backend as a sync target.

[deajan]

Some kind of multi-tenanncy can be be achieved by running multiple trilium instances with different trilium-data dirs.
Realtime collaboration is another beast, which is FAR from the most needed I guess.

@rauenzi Having the same database for multiple users would be the best IMO.
The usecase I'm targetting here is sharing notes with family / collegues, for them to see and/or edit, depeding on permissions.

[meichthys]

Having the same database for multiple users would be the best IMO.\nThe usecase I'm targetting here is sharing notes with family / collegues, for them to see and/or edit, depeding on permissions

Yes. This seems to be the most requested use case from what ice seen in past issues.

[alrhalford]

I would be interested to know the extent to which people want to collaborate on an entire instance. A couple of thoughts:

The ability to share an authenticated link that gives the recipient r or r/w access to a particular note tree, a bit like google docs does. The downside of this is that it becomes difficult to say "they can read this note tree, but only edit this subtree, etc", but the upside is that it should be easy to implement, and permissions are easy (if not super expressive).

The idea of "remote notes" in your own trilium instance that reference a note tree that is stored elsewhere. The downside is that you need your own trilium instance, but the upside is that it slots in quite nicely without re-engineering the existing stuff too much.

[deajan]

As of today, links to note trees are a simple HTML representation of the notes, without any editor function.
Having an authenticated link like you suggest would mean for a foreign user to get access to the whole Trilium interface, with all the frontend JS/plugins, which would probably lead to major security issues.

Also, "remote notes" could simply disappear without further notice, which is also not a good practice in terms of note taking.

From what I understand, the major multiuser need here is to have multiple users collaborate on the same Trilium instance.
Each user could have private notes, and view/edit group notes.
@meichthys What's your take on this ?

[alrhalford]

To be clear, I personally don't see the value in multi user, but to address your points:

Authenticated links: Clearly the authenticated link would not work now, work would need to be done to allow such links to be scoped to particular note trees, and the backend would only return the note trees that are within scope.

Remote notes: you're right, somebody could delete a remote note and it would disappear, but this is not so different from normal collaboration tools - if you and I collaborate on a Google doc/notion etc, I could just wipe/delete a page and it would disappear for you (local backups, versioning, etc notwithstanding).

[meichthys]

@deajan I do agree that multi user had significant benefits in cases like a small office, or family scenarios where there are multiple people who are expected to have read write access on a regular basis.
I have a deployment in a small office and we currently only have one way to restrict access to certain note trees (password protecting with the instance password). We logged in each user with the instance password (but never gave the password to them h this way we can 'reuse' the password to lock down 'IT or sensitive sections' of the notebook.

Some multi user discussions happened here: zadam#3921 <–– see this discussion for a list of old issues requesting this kind of feature
zadam#1375
zadam#3024

To me it breaks down to two categories: users that want to be able to just have two databases on the same instance (multi tenancy), and users who want some kind of better collaboration (whatever collaboration means).
A read\write authenticated link would satisfy a portion of the use cases, but not most from what I've seen in previous requests for these kinds of features.

[GitTimeraider]

Can add a vote for this.
But I also have to agree that unless some major parts get overhauled, I feel like most people would be more than fine already with multiple people having acces to the same database data and a very basic permission system (even if it does start off with having to literally tag everything with specific usernames)

More advanced stuff can be kept in mind during development but might not need to be a primary focus.
Not sure how many people are going as far as to suggest "collaboration" options, but not sure whether its to great of an idea to get to far into that.
Im all for more features and if stuff is possible it is nice, but I feel like full-on collaboration projects and notes simply work better in dedicated software so not sure whether that will lead to feeling like to much is crammed into 1 packages while not all of it will be as fleshed out.

[Br0kenSilos]

My use case its pretty simple although the implementation may or may not be. The ability to have multiple family members login using their own passwords. Once logged in, permissions (ie Master, Edit, Read-only, Share) could define their access levels to individual branches of the main tree only and propagate down through the sub-branches. A Primary "Master" would have full access to the whole tree. Then the individuals could further control their own branch downward. So For instance..

ROOT (Master)
\Dad's Notes (Dad)
\Mom's Notes (Mom)
\Kid 1 Notes (Kid 1)
\Kid 2 Notes (Kid 2)
\Family Shared (All Members)

[deajan]

@Br0kenSilos Sounds to be a pretty good usecase. Add "parents" and "children" groups to the permissions, and I'm all in ;)

[CrO2Cl2]

to add something: I think High Availability is a must for multi user support, in case there are any very big instances. You can already "chain" multiple servers together, but it would be nice to be able to make "web" of servers instead of just a chain
(issue that asked for HA: zadam#2654 )