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.

[h-2]

Hey, so I am obviously not an expecting anything. Just brainstorming. If you feel that this is going nowhere, no problem!

Changing to what you're proposing would mean having to update EVERYTHING on every single operation and trying to keep it all in sync, constantly.

I don't know what you mean exactly. With the proposed system, jotty knows exactly which files to parse on start of a user session. If you save a file, only that respective .md is updated. If you rename a file, only that user's metadata file would have to be edited. Nothing needs to be synced with anyone else.
If Alice initiates a share with Bob, the global metadata file for the note is changed (adding Bob to the user_readers), and a default metadata file is created for the note in Bob's metadata folder. This could even be empty (meaning "all fields inherited from owner").
If Alices removes Bob's access to the file, the system only needs to remove Bob from user_readers and delete his private metadata file.

Not to mention a system like that means ONE operation outside of the Jotty UI would mean the syncing operations that run on every action won't be there and things will start crumbling..

Hm, so you are saying that right now it's OK to edit the files from outside Jotty? Which operations are currently supported? What happens if I change the UUID in the header of a file? What happens if modify .index.json? Wouldn't that also break everything?

Not to mention I have a feeling people wouldn't like their filenames suddenly changing as soon as you import them in Jotty, the whole appeal is that you control the structure of the files, however you want it to be!

Yeah, I guess this depends very much on the use-case. I think if you provide easy import/export, no one would even notice. I wasn't assuming anyway that I can share the raw-data, precisely because I thought that mucking around in the folders would break something.

[fccview]

Hey, so I am obviously not an expecting anything. Just brainstorming. If you feel that this is going nowhere, no problem!

No please, don't get me wrong, brainstorm IS good, I love brainstorming, bring it on, always!

I don't know what you mean exactly. With the proposed system, jotty knows exactly which files to parse on start of a user session. If you save a file, only that respective .md is updated

Well, kinda.. Folders are their own entity, if you have a uuid.md/uuid.dir the folder files are into become redundant, don't they?

Hm, so you are saying that right now it's OK to edit the files from outside Jotty? Which operations are currently supported?

Well, obviously if you manually change UUIDs inside files OR change the index.json and break the connections it'll break... but if you move files manually between folders or edit files manually from a different editor, or rename files, nothing will break :)

Yeah, I guess this depends very much on the use-case. I think if you provide easy import/export, no one would even notice

Given how many times I had to fix naming conventions of files (between capital cases, dashed or fully freeform - there's even settings for it) I can guarantee I'll start getting a ton of complains in the moment people start noticing their entire file system is now full of uuids instead of file names. If I had done it that way from the get go, it'd have been probably a much better design.

Initially Jotty folders were UUIDs, I wish I had sticked with that design 😆

I wanna hear a bit more opinions if you have multiple ideas but at this stage I don't think re-structuring the whole file system is doable, it'd be a change I am not comfortable with, not gonna lie..

[h-2]

Well, kinda.. Folders are their own entity, if you have a uuid.md/uuid.dir the folder files are into become redundant, don't they?

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.

Well, obviously if you manually change UUIDs inside files OR change the index.json and break the connections it'll break... but if you move files manually between folders or edit files manually from a different editor, or rename files, nothing will break :)

To be honest, I don't think it is a "feature" worth keeping/promoting. Either filesystem-based access is possible and safe. Or it isn't.
That doesn't mean I don't like filesystem-based storage. That is great, independent of how things are named. Because it allows easy backup, and restore, compression... and emergency read-only access if the site is down for some reason.

Given how many times I had to fix naming conventions of files (between capital cases, dashed or fully freeform - there's even settings for it) I can guarantee I'll start getting a ton of complains in the moment people start noticing their entire file system is now full of uuids instead of file names.

But aren't those naming conventions a good example of why some kind of ID would be preferable? Once you remove user-input from the filesystem-hierarchy, you are free to change other things without people noticing. It also frees you from encoding problems and some attack vectors (special characters or commands injected through filenames).

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, whether the new name would conflict with an existing name of one of the people the note is shared with. The current design just becomes very messy as soon as sharing is involved, even without folder- or group-sharing.

I wanna hear a bit more opinions if you have multiple ideas but at this stage I don't think re-structuring the whole file system is doable, it'd be a change I am not comfortable with, not gonna lie..

Understand completely 👍🏻

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.

[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