Evaluate serde instead of flatbuffer #1607

Activity

1. ludfjig

   added this to Hyperlight Roadmapon Jul 1, 2026
2. ludfjig

   added a parent issue on Jul 1, 2026

   • Avoid unnecessary memory copies #671
3. github-project-automation

   added this to Hyperlight Milestoneson Jul 1, 2026
4. github-actions

   added

   lifecycle/needs-reviewThe issue has not yet been reviewed.The issue has not yet been reviewed.

   on Jul 1, 2026
5. ludfjig

   self-assigned this

   on Jul 2, 2026
6. jsturtevant

   added

   lifecycle/confirmedBug is verified or proposal seems reasonableBug is verified or proposal seems reasonable

   and removed

   lifecycle/needs-reviewThe issue has not yet been reviewed.The issue has not yet been reviewed.

   on Jul 22, 2026
7. yoshuawuyts

   added this to the 1.0 milestone on Aug 25, 2026
8. yoshuawuyts commented on Aug 25, 2026

   

   yoshuawuyts

   on Aug 25, 2026

   Contributor

   More actions

   I had a chat with @ludfjig about this yesterday and we concluded this probably sits in the path for 1.0, and might be a good target for a HIP. Before we move to an implementation, what I'd like to see written down is roughly:

   1. What are the problems we have with flat buffers today?
   2. How does serde solve those problems?
   3. Which serde codecs are we considering for evaluation and why? (e.g. postcard, possibly others?)

   It doesn't need to be expansive: just one paragraph per item would be fine imo. But I'd like us to get into the habit of documenting our motivation for changes within the repo, and the HIP process seems like the right way to go for that.