Introduce UID for Messages

[OskarStark]

We propose introducing UIDs for messages, which would be particularly beneficial in a frontend context. This approach would enable more efficient message handling by reducing unnecessary back-and-forth communication between the client and backend, especially when only the latest updates need to be tracked or pushed to the frontend.

Whenever responding to the frontend, we could push only the new messages.

The UID should ideally be generated based on the content of the Message. Initially, I considered using ULIDs, as they are sortable. However, ULIDs only work when generated on the fly with new, which isn’t feasible for our case since we need to be able to “recalculate” the UID when necessary.

Otherwise, we’d need to implement our own logic to handle this.

cc @silasjoisten as you’re working on the frontend
@DZunke for your awareness

One thing we’re uncertain about is whether we can send UIDs to the LLM or if they should be removed before querying the LLM.

[DZunke]

Would it really be useful to implement UID within this library? Just asking because the library is not delivering a persistence, so every message in the bag would get a UID, yes, but for what would it be utilized?

I think the UID is more useful when you bring this stateless library to a point to have a state. This is why i have wrapped an ExtendedMessage around the Messages that enhances the Message, that is put in there, with a UID to make the message storable in the storage of my application and so to have always the same identifier for each message.

Also when you want to just push new messages to a frontend you would have to have a storage with the already sent messages, or at least, identifiers in it, but, as mentioned ... such persistence is from my PoV more a concern of the application implementing this library 🤔

[silasjoisten]

Having a UID natively generated by the library can significantly simplify and standardize how messages are managed across various applications using the library. While it’s true that applications can wrap messages and generate their own UIDs, having a native solution reduces the burden on developers to implement this logic repeatedly in every use case. It ensures consistency in how messages are identified and tracked, regardless of the implementation context.

Moreover, even if the library is stateless, the UIDs help in creating a more predictable and reliable flow of messages between different parts of an application (or even between different systems). This is especially important when dealing with distributed or real-time systems, where keeping track of the order and uniqueness of messages is critical. In these cases, the frontend can easily recognize and handle only new messages or changes without additional overhead in comparing message content manually.

Additionally, having a UID allows for the potential future enhancement of the library, like built-in persistence layers, caching strategies, or easier debugging capabilities, since each message could be traced back more easily. Overall, the idea is to provide a more cohesive and feature-complete experience to developers, who can then build upon it without reinventing the wheel each time.

[OskarStark]

Just asking because the library is not delivering a persistence, so every message in the bag would get a UID, yes, but for what would it be utilized?

Right now not, that's true, but I plan to implement on to be able to have a "thread" wrapped around the messages.

This is why i have wrapped an ExtendedMessage around the Messages that enhances the Message, that is put in there,

Can you show an example?

[chr-hertel]

In general i'd like to better understand the use case since the models and the lib don't have any stakes to that UID.
But also I feel like we should consider the use-case of having additional state per message.

My current standpoint would be: we should make it simpler to have custom state at the message and with the current setup a custom implementation would need to reimplement the interface - which is to be fair only the getRole(). but still i'm wondering if a base Message class, open for inheritance would be an easier way in general. extending the message would not do the job tho, since we have specific subclasses. which i'm totally in favor bc of that better defined state and purpose.

... not done thinking here ...

[OskarStark]

It could make sense to always generate a UID for each message, regardless of persistence. This UID would serve as a unique identifier for tracking and managing messages. Then, you could introduce a method such as MessageBag()->messagesNewer($ID) (dummy code) that allows you to retrieve messages that are newer than a certain UID.

This approach would ensure:

• Consistent identification of messages.
• The possibility of efficiently tracking updates or changes in the message flow.
• Flexibility for those who want to extend the library with their own persistence solutions, without having to re-implement UIDs from scratch.

Additionally, generating UIDs would future-proof the library for potential enhancements like state management, persistence, or real-time message handling, which might require more structured identification and tracking of messages.

[DZunke]

Hm. Sorry for the long latency here but i do not really get it. When there will be a use case for persistency or sth. like this, hey... fine! No critics from my side 🚀 but for the given thoughts i do not get it.

A functionality to get a "newer" message from the message bag would require, from my PoV, a date based uid (which would force the format?) or an additional timestamp in the messages which would then also be something that is maybe not needed currently? From my PoV the integer keys of the bag has the same stability as uids currently even it sounds not that "modern" but the order does not change between the serializing processes.

Flexibility for those who want to extend it, is also now working for some use-cases at least. I just know my usage and not yours, so sorry when i do not get it - i am sure we differ in complexity. So like mentioned before, i have created an ExtendedMessage on top that is maybe a bit messy currently because of prototyping myself but it looks like this (cause you asked):

<?php

// [..]

use PhpLlm\LlmChain\Message\MessageInterface;

class ExtendedMessage implements JsonSerializable
{
    public string $id;

    public function __construct(
        public readonly MessageInterface $message,
        // Some additional domain specific data like utilized documents, images, tools, etc. for generating the message
    ) {
        $this->id = Uuid::v4()->toString();
    }

    public function jsonSerialize(): array
    {
        return [
            'id' => $this->id,
            'message' => $this->message,
            // [...]
        ];
    }
}

Something a like is adapting the MessageBag and what i then do is handling the given response from the package and recording some additional data that is then all put together to the extended message i have and this is persisted. So no real magic here but hiding the packages interface a bit behind some classes and working with my own in the rest of the application.

In general i will surely not block with hard discussions an approach to UIDs directly in the messages. I just try to understand the need that could not be covered currently without bloating the existing stuff 😉

So ... go ahead and have fun with what we love to do. In the end i am more with Christopher's last message. Have more customization and extension possibilities with the messages itself for "maybe" later extensions that should also be optional to have simple to complex use cases available. Support all of them with a wild mix of message possibilities.