What problem are you trying to solve?
Hit a wall rendering file uploads in our chat UI and I think it's a gap in eve, not us.
When a user sends a turn with attachments, eve forwards the file parts to the model fine. But the only thing clients get back is message.received, and that event flattens everything to a string — createMessageReceivedEvent just stores summarizeUserContent(message), so a file part becomes [file: name (type)] placeholder text. The structured part is gone by the time it hits the wire.
So defaultMessageReducer only ever produces a text part for the user message (there's no file in EveMessagePart), and a custom reducer can't help because the data's already been dropped upstream. To show the file the user attached, we end up keeping our own upload catalog on the side, correlating it back to the eve turnId, and regex-stripping the [file: …] text out of the bubble. Works, but it's a hack around missing data.
Proposed solution
Would it be reasonable to carry the non-text parts through on message.received? Something additive like data.attachments: { filename?, mediaType, url }[] plus a text-only data.text, keeping data.message as-is so nothing breaks, and a file variant on EveMessagePart that the default reducer projects. eve wouldn't store bytes — just pass through whatever the client authored (data URL or remote URL).
Mostly want to know if the lossy projection was deliberate beyond "keep the event a simple string," and whether you'd want the authored data passed through verbatim or just metadata.
Alternatives considered
No response
What problem are you trying to solve?
Hit a wall rendering file uploads in our chat UI and I think it's a gap in eve, not us.
When a user sends a turn with attachments, eve forwards the file parts to the model fine. But the only thing clients get back is message.received, and that event flattens everything to a string — createMessageReceivedEvent just stores summarizeUserContent(message), so a file part becomes [file: name (type)] placeholder text. The structured part is gone by the time it hits the wire.
So defaultMessageReducer only ever produces a text part for the user message (there's no file in EveMessagePart), and a custom reducer can't help because the data's already been dropped upstream. To show the file the user attached, we end up keeping our own upload catalog on the side, correlating it back to the eve turnId, and regex-stripping the [file: …] text out of the bubble. Works, but it's a hack around missing data.
Proposed solution
Would it be reasonable to carry the non-text parts through on message.received? Something additive like data.attachments: { filename?, mediaType, url }[] plus a text-only data.text, keeping data.message as-is so nothing breaks, and a file variant on EveMessagePart that the default reducer projects. eve wouldn't store bytes — just pass through whatever the client authored (data URL or remote URL).
Mostly want to know if the lossy projection was deliberate beyond "keep the event a simple string," and whether you'd want the authored data passed through verbatim or just metadata.
Alternatives considered
No response