Feat/channels/assistant

[AnniePachecoJ]

Summary

This PR updates CRUD operations for the Channels (channel type "assistant") module. It enables users to create, read, update, and delete channels of type assistant in the system.

Changes

• Updated createChannel endpoint
• Updated getChannels and getChannelById endpoints
• Updated updateChannel endpoint
• Updated deleteChannel endpoint
• Updated documentation to include new endpoints
• Extended the object Channel and ChannelCreate adding new fields ( description, channel_llm_id, persona_id, files, status, allow_edit and channel_type)
• Updated table Channel
• Created a new table File

Related Issues

N/A

Type of Change

New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING documentation.
• I have performed a self-review of my own code.
• I have added tests that prove my fix is effective or that my feature works.
• I have updated the documentation (if applicable).

Screenshots (if applicable)

Additional Context

Tested locally using Swagger.

[samj]

It looks like you've clobbered OpenAI's openapi.yaml too?

[samj]

Base is develop, not main (which is expected to be a working branch).

[samj]

Curious as to the thinking here. Channels are meant to tell you where the data flows in/out of the system are (for example, an imap email feed, or a web chat interface). Not obvious to me the relevance of e.g. files? Perhaps you're using this in place of an actual assistant (i.e., an instantiated persona)?

[AnniePacheco]

@samj Thank you for the feedback! If you're referring to the files property in the ChannelCreate schema, this array contains the list of filenames that will be used for Retrieval-Augmented Generation (RAG) by the assistant. Essentially, these files represent the knowledge base for the assistant.
On the other hand, as we discussed earlier, the Persona is more of a cosmetic feature—it provides the voice and face, but the actual knowledge and data processing happen at the assistant level, with the files in the channel serving as the primary data sources. I hope we're aligned in this understanding, but please let me know if you had something else in mind.

[samj]

OK so the problem Channels set out to solve is that when you start a service (say, your assistant), it could pop up literally anywhere... on a local port or on a cloud on the other side of the planet. Without Channels, you don't know where to go next. It's a way to show the various flows in and out of the system (I expect it will one day be visual if someone cares enough).

What you're talking about is assets (which could be individual assets as they are today, or collections like "sam's gmail inbox" or even collections of collections like "mycompany.com's employee's inboxes", but I think the problem you're trying to solve is linking certain assets to certain assistants? It's an interesting idea, and indeed if we were to create an assistant datatype then we would have it separate from the URL (Channel) you use to access it, which is probably OK. Either way, the files (or collections of files - in this case a zip file which translates to a directory) should be in assets.

The purpose of personas is so you can define the "look and feel" of an assistant and have it respected by all components that use it. For example, you could create a PAI assistant with a certain look and feel and then later create an SMS chatbot with the same personality, and later a walking, talking metaverse model.

[AnniePacheco]

OK I think we got it, so we may change the name of the field "files" to let's say "assets" which might be an array of directories/paths where my channel_type="assistant" can add it to its knowledge base. That is to say we are going to have this Channel schema:

{
  "name": "pAI-OS",
  "uri": "https://localhost:8080/v1/api",
  "description": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.",
  "channel_llm_id": "7bea4732-214f-40e7-9161-4e7241a2b97e",
  "persona_id": "7bea4732-214f-40e7-9161-4e7241a2b97e",
  "assets": [
    "data\downloads\myKnowledgebase.zip",
    "data\downloads\mySyllabus.pdf",
  ],
  "status": "public",
  "allow_edit": "True",
  "channel_type": "assistant" (or "llm")
}

We also going to specify this it in the yaml file as the following:

assetsPath:
  type: string
  description: >
    An assets path that is valid on macOS, Windows, and Linux. This includes regular file paths.
  pattern: |
    ^(
      (\/[^\0/]+)*\/? |                               # macOS/Linux absolute paths
      ([a-zA-Z]:\\|\\\\[^\0\\/]+\\[^\0\\/]+(\\[^\0\\/]+)*)\\? |  # Windows absolute paths
      (\.\.?\/|\\\.\.?\\|\/|\\)?([^\0/]+\/?)*         # Relative paths for all OSes
    )$
  examples:
    - "/usr/local/bin/myfile"        # macOS/Linux absolute path
    - "C:\\Program Files\\myfile"    # Windows absolute path
    - "./myfolder/myfile"            # Relative path (all OSes)
    - "myfolder/myfile"              # Relative path (all OSes)

[samj]

I think I found a way to reconcile this issue (where we're turning what was meant to be a lightweight list of I/O interfaces into a heavyweight list with all relevant attributes: turn them into resources ala feature/resources

[AnniePacheco]

This PR will be closed due to it was created another PR(#30) which solves the above comments.