Folders for everything

[guenhter]

A very generic way of supporting folders could make the solution very flexible; or too flexible to make a mess.
My vision goes like this: We support folders, which means in the ui there is the possibility in different places to create folders / subfolders. Those folders could be used:

• organize chats
• contains files; this is a big thing because that means we don't need extra solutions like knowledge bases / libraries to put related files into, but just use folders / subfolders
• maybe they can even help for permissons management like this:
  • users/groups can be given permissons for folders
  • it is possible to also put an assistant in one or more folders (assistant == model)
  • as said, also knowledge bases and other resources might go into the folder
  • as soon as a user has access to a folder, he has access to all the resources of the folder

Sepcially the permissons part might be cool or shit ... I haven't decided yet....

[guenhter]

OptionA: One big folder structure for everything with types

user1-home/
    > some-private-folder/
        > 1.txt
        > 2.txt
    > other folder/
        > 3.txt
group1-home/
    > shared-folder1/
        > shared-file.txt
global-home/
    > some-globally-shared-folder1/
        > foo.txt

A user would then have access to:

• its own home (e.g. user1-home)
• all group-homes he is member of
• the global home (maybe global home is just a default group every user is a mandatory member of)

Inside the different homes, the file system structure is like in a normal file system => files, folders, sub-folders

---

Special folder types

Every folder has types (general, skill, ...)

user1-home (folder-type: general,home)
    > some-folder/ (folder-type: general)
    > some-skill/ (folder-type: general,skill)
        > SKILL.md
        > references/ (folder-type: general)
            > ...
    > another-skill/ (folder-type: general,skill)
        > SKILL.md

Whenever the agentic chat is triggered, it reads all the skills it has access to from the FS.

The main benefit of type approach would be, to have a standardized way to handle file-based resources with the virtual file system. So uploading and reading must be implemented once, and can be reused whenever file-based resoruces are handled. But with the concept of types, we still are flexible enough to distinct different resources and give them special meaning.

---

Virtual files

A file system is here to hold files like pdf, docx, txt, ....

user1-home/
    > folder/
        > some.pdf

But as a file system already gives a very nice file structure, that structure could be used to organize also some non-file concepts e.g. like chat, prompts, ... . In the UI it would like something like this:

user1-home/
    > folder/
        > some.pdf (type: general)
        > chat1 (type: chat)
        > chat2 (type: chat)
        > new-invoidce-prompt (type: prompt)

There are actions when files are clicked depending on their type:

• general: the file (content) is loaded as preview
• chat: the chat is loaded in the main screen. The chat can then be continued
• prompt: the current input prompt will be replaced with the given prompt

It is not clear yet, if the content for those non general types are then also stored as file in the file system, or in the DB.

---

Pro:

• Things (chats, files, ...) which belong together can be kept togeter
• Restructuring the folder hierarchy applies to all types (chats, files, ...)

Con:

• Overwhelming to have all different types mixed in one folder structure (ui topic?)
• If the UI e.g. only shows files but not other types AND the user decides to delete a folder, everything gets deleted inside that folder even non file types

[guenhter]

Option B: The root folder defines the type

user1-home
    > files/
        > somefile.txt
    > skills/
        > some-skill
            > SKILL.md
            > references/
            > ...
    > chats/
        > chat1.json
        > chat2.json
    > prompts
        > primpt1.json
        > primpt2.json
group1-home
    > files/
        > somefile.txt
    > skills/
        > some-skill
            > SKILL.md
            > references/
            > ...

A user would then have access to:

• its own home (e.g. user1-home)
• all group-homes he is member of

Inside the different homes, the file system structure is like in a normal file system => files, folders, sub-folders

Here, the root folder is always the home (user home, group home). The first folder layer inside the home has then a special meaning: It defines a so to say type: files, skills, chats, prompts, ...

In the UI, when the user then opens the "Files" view, he sees the folder structure under "user1-home > files". If the user switches to the skills view he sees "user1-home > skills", but the never sees a overall file system where skills and files are mixed.

---

Pro:

• as everything is treated as a file, concepts like folder hierarchy, upload progress indicator, ... are uniform

[guenhter]

Generic Features valid for OptionA and OptionB

History

If the virtual file system would be mapped actually on the real file system, we could even create a git repo for the file system and would get free history capabilities. So jumping back and forth in history with GIT would then be easily possible....

---

Change Listeners

It can be needed to inform someone if something happens in the file system to certain files or folders. E.g. when a new file is added or deleted, notify a registered listener. This e.g. can be useful to invalidate a cache or update some resource when a file gets updated.

---

Linux Permission system

When thinking of tools like OpenTerminal, it is crucial that the tool doesn't access files it has no access to. We could leverage file access to the same file system the user also sees to by using the linux file system

• whenever a group in modai is created -> the same named group is created in Linux
• whenever a user is created in modai -> the same named user is created in Linux
• when a user gets assigned to a group in modai -> we assign the user also to the group in linux

With this permission handling on linux level, if a script should be executed then we would do:

• run the script but not as root user, but execute it under the linux user
• that means, the process running the script only has access to files he owns or he is in a group with, but no other as the permission system of linux ensures that.

[guenhter]

File System Interface

interface FileSystem {
    list(parentDir, page, pageSize, sorting)
    readFile(path)
}

data class DirEntry {
    type,
    name,
    parentPath,
    attributes,
    permissions
}