Share Folder (Groups)

[PicStaDev]

I have tried Jotty and noticed it's a solid foundation for something great and exactly something for my 3 persons big team. We have to share a lot of information and tasks among us. Where we ran into a limitation that you can't share groups with others to place shared tasks or notes in a custom folder. Either way, I would prefer a function to share groups directly.

The Kanban view drag and drop between states isn't working at the moment. I have seen this got reported as an issue already and confirm this problem exists.

Thanks for the great start of a very useful app. I hope this app evolves over time.

[fccview]

Hey,
I think sharing folders is the next natural step, I am just trying to figure out how to do it without a database, it's always the main challenge 😅

The Kanban status issue is fixed on the develop branch together with some other minor issues, you can check the changes in the active open pull request :)

I can't do a proper release for a couple of days, so if Kanban is important to you, you may want to switch to that branch as for now it should be pretty stable, not much difference from latest aside from these bugfixes

[PicStaDev]

Thanks for your kind reply and of course no stress at all. Private things first, always.

[h-2]

Just adding a Note saying that I'd love to be able to share folders, too!

Thank you!

[h-2]

Some general thoughts about sharing:

Currently, notes that are shared with me are shown very prominently, above all others, plus they are nested multiple times ("Shared with you" → "User name" → "Note name"). This makes them much too important, IMHO. For example, a user shared a "test note" with me, and I can't even get rid of it myself.

Ideally, all of the following would be possible:

• sharing folders
• being able to move notes and folders shared with me into my own folders (without changing anything for the sharing user)
• not highlighting them as prominently
• rejecting/disabling something shared with me

Instead of having the extra folder for received shares, I would just communicate this with icons:

These icons could also be used on folders. Mouse-over tooltip could point out the relationship: "Shared by you with Alice" or "Shared by Bob with you.".

[mariusgoldberg]

I would also love to see this feature. For many use cases, sharing individual notes is a bit fiddly. Sharing a whole folder is often more straight forward. Instead having joint space simplifies many situations.

I also agree with many points that @h-2 made:

• Would prefer to have shared notes and folders integrated in the standard list instead of a separate shared section. Those notes (for a maintained space) fall in the same categories and it is more ordered if the appear at the same position. Instead I would mark them with an icon as @h-2 suggested.
• Being able to remove yourself from shared files/folders is particularly helpful for larger groups of people collaborating.
• Maybe a filter would be helpful to hide shared notes instead of having them in a separate section

[fccview]

I have spent a lot of time on this feature and I just can't see a clean way to do it.

I had an mvp working but it was getting more and more convoluted as it was using the .sharing.json file with a path based system as shared folder key, this is unfortunately not immutable so renaming categories/moving them/deleting them would result in the folders being unshared, which kinda makes the whole thing unstable.

So I started going down the route of edit/renaming operations updating .sharing.json and I slowly started remembering why I moved away from path based approach in favour of uuid.

I'll keep thinking of ideas but aside from symlink (which is hella unsicure) I am not sure what can be done here.

[fccview]

Yes. My suggestion was to not have any real folders. I think real folders are quite difficult to maintain as soon as there is access from multiple users. Also, it means that the URLs are unstable (if folder/file get renamed). With UUIDs all paths are stable.

But this is already how it works!
The uuid is in the file frontmatter, that IS the source of truth, category+slug is legacy behaviour that I'm slowly moving away from. That's what makes jotty different, the way it "magically" handles the file system without compromising on the user folder+clean file structure. That's the biggest point of pride of the app and I'm not moving away from it, it took me forever to design it and frankly it works beautifully (bar the bug you found, but that's easily fixable and it'll be sorted once all legacy behaviour is removed ❤️)

Another issue that comes to mind with the current design: notes shared with me appear in my own hierarchy. If I now create a note with the same name, access to other one is broken, and it looks like I am accessing both at the same time. It's possible to introduce a check to prevent this bug, but you would need to also check when the owner of the shared note renames their note

I replied about this in the bug issue you opened, but what you are saying is simply not the case, the sharing doesn't work via name/folder.. I guarantee you if you share a note with someone and move it around in other folders and rename the file, the other person will still have said note shared with them :) folder+name mean absolutely nothing in jotty (bar the bug you found, but that's not a design issue, that's a bug and I'll sort it out once urls use uuids ❤️)

Regarding other ideas: of course, it would be possible to add some settings to folders so that that files in that folder inherit "sharing properties" from the folder. This would allow sharing folders, but it doesn't seem like a very clean solution.

I wonder if symlinks would actually work, I think with a bit of a security hat on to think of potential breaking points and get ahead if it, it could work well.

I'll give this to whole thing a bit more love

[mariusgoldberg]

I've been thinking about this more and wanted to share my current thinking on why this is tricky and what I think a clean path forward could look like.

The root problem

Folders in Jotty don't have a stable identity — they're just filesystem directories, and their only identity is their path. Notes already solved this with a UUID in their frontmatter, but folders have no equivalent. Any sharing system needs a stable key to reference a folder by, so that renaming or moving it doesn't break the share. The challenge is: where do you store that key?

Two general approaches

Option 1 — Central index (e.g. a .folders.json at the top level, database, ...):
Map each folder UUID to its current path in one central file. Fast and clean from a filesystem perspective — no extra files in the folders. The tradeoff: if you rename or move a folder outside of Jotty, the index goes stale and the share breaks. This approach effectively requires you to manage your folder structure exclusively through Jotty, or live with the fact that things could break on user changes on filesystem level¹.

Option 2 — Per-folder UUID marker (e.g. a .uuid file inside each folder):
The UUID lives inside the folder itself, so it travels with the folder on any rename or move — even outside Jotty. A central file can still be kept as a lookup cache, rebuilt automatically on a cache miss. The tradeoff: users will see .uuid files appear throughout their filesystem, and if they delete or modify one, the link is broken.²

The unavoidable tradeoff

Ultimately there's no solution that removes all tradeoffs here — and I think it's worth being honest about that. The core tension is:

Either you take away the freedom to manage the folder structure directly on the filesystem and route everything through Jotty — in which case a central index works fine. Or you preserve that freedom — but then you have to accept that certain actions taken outside Jotty (deleting order.json, or creating folders that Jotty has never touched) can break or bypass the sharing system.

Way forward

I would argue that the cleanest and most stable way forward would be to manage files through Jotty only and disallow changes on filesystem level. Users can still easily export / backup data as files will still be markdown. You will simply not be able to prevent things from breaking if users edit files and folders directly. And honestly, looking at the system as of today I would already argue to remove that freedom particularly in a multi-user setup. There are already crucial files (.sharing.json, .index.json) and folders (images, files) and users will mess things up. Hence, I personally would go the centralized way.

If you really want to keep that freedom, I would recommend the following approach using things that are in place already (hence, not introduce additional files etc.): piggyback on order.json

order.json already exists inside every folder Jotty manages (it controls sidebar ordering). It already moves with the folder on rename/move. Users already implicitly understand it's Jotty-managed metadata. Simply add a uuid field to it:

{
"uuid": "some-stable-uuid",
"categories": ["Projects", "Archive"],
"items": ["meeting-notes", "roadmap"]
}

No new files. No filesystem pollution. The UUID travels with the folder automatically. A central cache file should still be used for fast lookups, falling back to a full scan when it's stale.

The order.json approach is the best practical middle ground: it keeps the filesystem clean, survives external renames and moves, and the risk of someone breaking it externally is no greater than the risk you already take today by manually editing order.json to mess with their sidebar order, changing frontmatter uuids etc.

I personally, though, would go with centralized, Jotty-managed filesystem to have a more robust system.

Footnotes:
¹ What it does anyhow already today: If user were to change the front-matter of a note or change the .order.json, .index.json or similar, things will already break today
² You kind of live with that issue already today, if users change the front-matter of a note

[h-2]

@fccview: I wonder if symlinks would actually work, I think with a bit of a security hat on to think of potential breaking points and get ahead if it, it could work well.

I don't think security is the problem here. You could have

data/notes/USERNAME/own/...
data/notes/USERNAME/shared_ro_from/BOB/...
data/notes/USERNAME/shared_rw_from/BOB/...

And then have symlinks of either notes or folders into that shared_XX_from hierarchy.

However, I don't see how you can mix symlinks with unstable file/folder-names, especially if you even want to allow filesystem-based access from outside of Jotty.

@mariusgoldberg: The root problem
Folders in Jotty don't have a stable identity — they're just filesystem directories, and their only identity is their path. Notes already solved this with a UUID in their frontmatter, but folders have no equivalent. Any sharing system needs a stable key to reference a folder by, so that renaming or moving it doesn't break the share. The challenge is: where do you store that key?

I agree that this is one of the core problems.

@mariusgoldberg: I would argue that the cleanest and most stable way forward would be to manage files through Jotty only and disallow changes on filesystem level. Users can still easily export / backup data as files will still be markdown. You will simply not be able to prevent things from breaking if users edit files and folders directly. And honestly, looking at the system as of today I would already argue to remove that freedom particularly in a multi-user setup. There are already crucial files (.sharing.json, .index.json) and folders (images, files) and users will mess things up. Hence, I personally would go the centralized way.

Also agree with this. Once you have a multi-user setup, it makes no sense to allow filesystem access.

Hence, I still think that implementing folders as metadata and not as actual folders is the most flexible and future-proof solution. This provides many potential benefits:

• Multi-categories (one note in multiple "folders"; something I despise, but that many people seem to like)
• A shared note being shown in different folders for different users (highly useful!)
• Actual group-ownership (based on SSO/LDAP group) of files/folders
• More fine-grained permissions (e.g. transfer-ownership of note/folder to other user; allow to create notes in shared folder but not edit existing...).
• Other storage-backends in the future that might not support symlinks, e.g. WebDAV, SMB...

You can still offer "Export as zipped hierarchy" in the Web-Frontend, and you could offer a script on the server that creates a human-readable folder-hierarchy for one or all users. You could potentially even create a human-readable hierarchy of real folder and symlinked notes from the metadata and UUID.md files. However, that would have to be read-only view onto the notes.

However, I do realise this may depart from the design @fccview came up with—which is certainly elegant in its simplicity! In the end, every popular project that starts small probably has some tendency to acquire more features when it grows. And I think it is fair to push against that at some point to keep it simple. It's not always obvious where the best tradeoff lies.

But for me, personally, ergonomic sharing is really important to be able to use it productively with family members 🤷🏻 😇

[fccview]

Hey @h-2
Thank you for the detailed reply as always ❤️

I am actually working through a new solution that may be the one, it allows file moves around from the file system, fine grained sharing with folder sharing, and no symlinks.

I'm hoping this is the one, it'll work with an inherited permission system, a hierarchy starting from folder ending to file.

folder -> file
folder -> subfolder -> file

• if user a shares a folder to user b, every file within that folder will be automatically shared.
• If user a shares a file with user b, only that one file will be shared
• if user a shares a folder with user b, all files and sub folders within the folder will be shared and any new files or subfolder will automatically be shared
• if user a revokes sharing permission from one file into a shared folder, that one file won't be shared anymore

This took a few days to think out properly, it involves a .category-info.json file in every category assigning a uuid per category (as per various suggestions in this thread) and a sharedWith entry in the json that assignes usernames.

I'll also add a sharedWith in the individual file frontmatter for individual shares, and IF a file sharing permissions are revoked it'll have a sharedWith: none instead of users.

The idea being, no matter where you move a file, if it's shared it'll always be shared, if you move a folder it'll move the .category-info.json` file with it, everything uses uuid thanks to the changes in #210 (which is being tested now and works pretty damn nicely) and i have fully deprecated canonical category+id combo (file names stay unchanged, category names stay unchanged and I keep my extremely impressive no database/no compromises system going for a little longer 😆)

Let me know what you think, the logic and design is sound, i'm playing around with implementation but it's coming along nicely.

[fccview]

view user: fccview

view user: jodi

You'll see what I went for with this, it's actually pretty stable, i'm super happy with how is turning out ❤️

[fccview]

Hey @h-2 @mariusgoldberg @PicStaDev @seigel as of today this is live on the develop image.
I am still unsure on the stability, I am doing a lot of testing, I have been working on this for 3 weeks nonstop (had to make sure EVERYTHING used uuid now and it was a massive undertaking).

It would be invaluable if you could back up your data and do some testing to let me know how stable it feels ❤️

When you install it it'll go to a migration page right away, it's fairly straight forward and takes a second to run, it's to make sure the old shared notes/checklists will stay in place with the new system :)

[h-2]

This is looking good! I think the design and reasoning are sound. Like I said, I don't think it could have been done with symlinks, but with UUIDs for folders, stored in the folders, it should work (although it is not as flexible, as what I suggested).

In any case, really looking forward to being able to share folders! Thank you so much for working on this ❤️

Since I am on FreeBSD, I cannot test the develop-image unfortunately, and porting a non-release is also not trivial, so I am leaving the immediate testing to others. As soon as it is released, I will update the FreeBSD port and do some testing of my own.

[fccview]

Yes of course!
The first round of testing from some discord members went very well, I have addressed the first list of feedbacks today and we'll see how it proceeds!

For the sake of transparency here's the list I fixed:

[mariusgoldberg2]

Finally found the time to backup, switch to develop and migrate. Will give it a try. But initial experience looks nice and functional.

[fccview]

Hey this is actually released ♥️

[h-2]

Great to see folder sharing in the release, much appreciated!

I have encountered some problems, but I will open separate issues for those.