Endpoint PUT conversation history

[pieroit]

As suggeste in #889 , we could add an endpoint to impose a convo history.
(GET and DELETE already exists).

As for the payload, not sure if we can have a custom Pydantic model replicating this structure:

{
    "who": who,
    "message": message,
    "why": why,
    "when": time.time(),
    "role": Role.AI if who == "AI" else Role.Human,
}

Or try to reuse the objects already established to deal with conversation turns:

• CatMessage
• UserMessage
  (see here)

[dave90]

I’d like to work on this issue . Could you please assign it to me?

[pieroit]

I’d like to work on this issue . Could you please assign it to me?

Thanks @dave90, I'm not sure about the data model here. What do you suggest?
We can mock internal objects like I suggested above or align convo history with the openai/ollama standard

Assigned to you, but please let's design before writing ;)

[dave90]

I think that the best solution is using :

{
    "who": who,
    "message": message,
    "why": why,
    "when": time.time(),
    "role": Role.AI if who == "AI" else Role.Human,
}

This format ensures consistency with the objects that are returned in the GET /conversation_history endpoint.

[dave90]

I think the best approach would be to use the following Pydantic class model for the endpoint PUT /conversation_history:

class HistoryMessage(BaseModel):
    who:str
    message:str
    why: Dict 

What do you think @pieroit ?

[pieroit]

I think the best approach would be to use the following Pydantic class model for the endpoint PUT /conversation_history:

class HistoryMessage(BaseModel):
    who:str
    message:str
    why: Dict 

What do you think @pieroit ?

Hi @dave90 thanks and sorry for the dealy
Have a look at the vision branch, @Pingdred is adding support for images and made a tweak on those structures

After that, do as you whish on this endpoint, we can have it without documenting it, trying it out, when we are ready we document it

Also please note from the next release on it will be possible to add custom endpoints (#964 ), so in the next months we can focus on having fewer endpoints, but more solid and with types - in line with the work you started months ago ;)

[dave90]

I think the best approach would be to use the following Pydantic class model for the endpoint PUT /conversation_history:

class HistoryMessage(BaseModel):
    who:str
    message:str
    why: Dict 

What do you think @pieroit ?

Hi @dave90 thanks and sorry for the dealy Have a look at the vision branch, @Pingdred is adding support for images and made a tweak on those structures

After that, do as you whish on this endpoint, we can have it without documenting it, trying it out, when we are ready we document it

Also please note from the next release on it will be possible to add custom endpoints (#964 ), so in the next months we can focus on having fewer endpoints, but more solid and with types - in line with the work you started months ago ;)

Hi @pieroit thanks for the update!
Regarding the multimodality PR (#967), I noticed the change to the history list type in WorkingMemory. So in my opinion, it makes sense to wait for that to merge before starting on the new PUT history endpoint to maintain consistency with the updated data type.

[pieroit]

Hi @pieroit thanks for the update! Regarding the multimodality PR (#967), I noticed the change to the history list type in WorkingMemory. So in my opinion, it makes sense to wait for that to merge before starting on the new PUT history endpoint to maintain consistency with the updated data type.

Ok sounds the right strategy.
Thanks ;)