Repository navigation
Serialize and deserialize custom extensions #628
Description
Is your feature request related to a problem? Please describe.
I work in a large enterprise, and we have a few custom extensions defined. With the given structure, we can just extend the CloudEventV1 interface, add our extensions, hand that to devs, and they can just create CloudEvent's with that options interface. Super lightweight. Awesome. 🥳
What I don't love is that there's no clean way to inject our custom extensions into the transport layer, specifically for deserialize.
For example, we define a tags extension, which is simply a [key: string]: string object, that we encode. Easy to kinda handle for serialize via a toJSON() implementation. But for deserialize (and proper serialize support - binary + structured) to decode tags, we're going to have to, for example, wrap the HTTP deserialize function, then provide our own Binding for HTTP and have folks use that custom binding. Doable, but I don't love having to wrap the existing functions and then maintain our own Bindings, all for each transport.
Describe the solution you would like to see
It would be cool to be able to define an Extension, something like this, patterned after the Binding interface:
interface Extension {
// CE Extension's key/name
key: string;
deserialize: ExtensionDeserializer;
serializeStructured: ExtensionSerializer;
serializeBinary: ExtensionSerializer;
}Then be able to "register" those extensions with the transport code, then have the transport code exec the correct supplied extension code when it sees an extension key that matches a "registered" extension.
I realize the interface above is a bit naive. We'd want a way to be able to implement that interface per-transport type, but hopefully that's enough for you to kinda see where I'm headed with this.
Is that sort of interface something you would entertain?
Activity
[-]Formalise an Extension[/-][+]Serialize and deserialize custom extensions[/+]duglin commentedon Oct 7, 2025
Ping @lance
gradybarrett commentedon Oct 9, 2025
Adding to this thread since we've had have more conversations since. We'll also want to talk through how to handle multi-attribute extentions such as tracing and data classification. The Java SDK implements, for example, data classification as a single extension with multiple keys, then serializes that extension into multiple attributes on the cloud event. That leads to the existing readFrom and keySet interface. Not sure I'm a huge fan of how that was done, but I get why it was done.
github-actions commentedon Nov 9, 2025
This issue is stale because it has been open 30 days with no activity.
gradybarrett commentedon Nov 9, 2025
Bump
duglin commentedon Nov 9, 2025
ping @lance @lholmquist @fabiojose @danbev
github-actions commentedon Dec 11, 2025
This issue is stale because it has been open 30 days with no activity.
gradybarrett commentedon Dec 11, 2025
Bump
github-actions commentedon Jan 11, 2026
This issue is stale because it has been open 30 days with no activity.
gradybarrett commentedon Jan 11, 2026
Bump
BethGriggs commentedon Jan 19, 2026
Hey, just wanted to drop a comment to help set expectations around maintenance and next steps.
I believe that all of the existing maintainers have mostly changed focus these days, so I suspect it's unlikely they'll be driving or deeply involved in new feature work. That said, as former Red Hat colleagues, I am still in contact with some, and if there were a PR proposal, I could reach out to see whether they would be open to reviewing it.
In parallel, we are seeking more contributors and potential maintainers, including from the broader community and from the team that previously worked on the library, to get familiar with it again (myself included).
github-actions commentedon Feb 19, 2026
This issue is stale because it has been open 30 days with no activity.