[Platform] Add ID to message bag

[lochmueller]

Q	A
Bug fix?	yes
New feature?	no
Docs?	no
Issues
License	MIT

Add ID to the message bag.

[OskarStark]

Please add some tests

[OskarStark]

@Guikingone we should leverage this new id in the chat component then

[Guikingone]

@OskarStark Hum, yes and "maybe no" 😅

If we're setting the id at the bag level, how do we pass it to the store / chat one?

We're ending in the same discussions that we've faced in #254, if the bag is the object storing the current conversation identifier, we should/must have an identifier at the Chat / MessageStore level (in this case, coming from the bag level), the Store level is not an issue (as it's the default behavior) but the Chat one is an issue we've discussed (if I'm right, @chr-hertel was also in the loop and again, if I'm right, we were on the side of not storing identifiers at Chat level).

Not to mention that at MessageStore level, we're not storing the bag but each messages individually (as they already have an identifier), I'm not sure that storing the bag is a good approach (just my POV here) as AFAIK, the bag is just "a transport layer" for messages that we can merge, prepend and so on.

If @lochmueller has a POV on this issue, I'll be more than happy to discuss around it as this is something that we're facing in #821 (the fork approach allows to prevent storing an identifier at the Chat level, only the MessageStore knows it).

I dont want to "lock this PR in endless debates" but I already faced this situation and I'm still equally open to add an identifier at bag level (because this could lead to a solution) and opposed to add it as I don't see the benefits against the disadvantages 😅

[chr-hertel]

Yea, we're coming back to a previous discussion - but that's fair.

Let's bring in that ID

[Guikingone]

We might need to update the normalization process, maybe creating a new MessageBagNormalizer that can handle the normalization of the bag then call the MessageNormalizer to normalize messages then send the whole payload to stores?

Could be handled in another PR but might be worth the work to ensure that we don't miss the id during normalization.

[chr-hertel]

@Guikingone regarding the chat component you mean?

[Guikingone]

@chr-hertel Yes, after thinking about it, the id in the message bag could lead to a solution.

Let's agree on the fact that messages are identified using an UUID, now, we're adding an UUID to the message bag, this could create a OTM-like relation between bag and messages, so now, we have the "id" of a chat, we could store it in message stores as a "foreign-key like" identifier used by each messages and retrieve each messages linked to this bag, this storage part will require a new normalizer to handle the "bag -> messages" relation, that's why I was thinking about a MessageBagNormalizer.

The only issue that we're facing now is "how to keep this id at Chat level", I was looking at the Cache component last night and especially at the TagAwareAdapter, what if we implement a IdentifierAwareChat that keep the id of the current message bag?

This lead to a stateful service but stores are already stateful, messages store are also stateful (as they store the identifier of the queue / table / etc) but it will allows to "switch / fork / othermethodname" between bags (maybe we can list bags in a command like ai:chat:list) while relying on UUIDs?