# V1.1 roadmap defined **URL:** \ **Category:** Specification\ **Created:** [May 12, 2025, 12:48am UTC](https://forum.opencyphal.org/t/v1-1-roadmap-defined/2382 "2025-05-12T00:48:08Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [May 12, 2025, 12:48am UTC](https://forum.opencyphal.org/t/v1-1-roadmap-defined/2382/1 "2025-05-12T00:48:09Z")
On the Friday May 9th, 2025 dev call we discussed several new features that would require additions to the specification and some, non-breaking, changes. There was a general consensus that this work would be better executed as part of a new minor revision, 1.1. @pavel.kirienko reminded the group that V1.0 was not yet officially released. @scottdixon proposed that we then release v1.0 to make way for v1.1 work to proceed. There were no objections to this. As such the consensus is that, once [the remaining v1.0 issues](https://github.com/OpenCyphal/specification/issues?q=is%3Aissue%20state%3Aopen%20milestone%3Av1.0) have been resolved we will officially release v1.0 and begin work on v1.1. The current set of items for 1.0 under discussion are as follows: 1. Improvements to the transfer ID for transports using large identifiers (i.e. , not CAN) 2. Additional DSDL directives focused on system-level and runtime analysis. For example, directives for message publication rates, valid ranges for integer values, and grouping (e.g. tagging messages by sub-system). 3. [Named Topics](https://forum.opencyphal.org/t/rfc-zero-configuration-cyphal-with-named-topics/2376) (mic drop) 4. Secure node authentication 5. Formal proofs of certain protocol features (e.g. proofs for multi-part transfer reassembly reliability) 6. Consensus-based PnP (automatic node ID configuration without a PnP server) 7. More formal definition around Cyphal routing. Please join [our weekly devcall](https://forum.opencyphal.org/t/weekly-dev-call/173) if you want to add to this list or participate in v1.1 standarization. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [May 12, 2025, 1:15pm UTC](https://forum.opencyphal.org/t/v1-1-roadmap-defined/2382/2 "2025-05-12T13:15:49Z")
Slight amendment: Named topics are also meant to include named RPC endpoints. For the rationale and discussion please refer to the [separate topic](https://forum.opencyphal.org/t/rfc-zero-configuration-cyphal-with-named-topics/2376). ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [May 12, 2025, 11:43pm UTC](https://forum.opencyphal.org/t/v1-1-roadmap-defined/2382/3 "2025-05-12T23:43:09Z")
While we’ve been hoping to get to Cyphal/TSN I wonder if we should first tackle Cyphal/IPC? That is, we should have a specification for a zero-copy transport using shared memory to support ARINC-653-like sampling and queuing ports. This would complete a function portability story where the application interface for a given function previously available over a network would remain stable but a performance improvement could be realized by migrating the function to the local compute. ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [May 15, 2025, 8:58pm UTC](https://forum.opencyphal.org/t/v1-1-roadmap-defined/2382/4 "2025-05-15T20:58:36Z")
Another thing to consider, perhaps, in 1.1; canonical storage format for Cyphal. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [May 15, 2025, 10:49pm UTC](https://forum.opencyphal.org/t/v1-1-roadmap-defined/2382/5 "2025-05-15T22:49:18Z")
> [@scottdixon](#): > > canonical storage format for Cyphal Are you talking about traffic dumps like pcap/candump or something else? ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [May 15, 2025, 10:52pm UTC](https://forum.opencyphal.org/t/v1-1-roadmap-defined/2382/6 "2025-05-15T22:52:04Z")
I contemplated proposing routing but in the end decided to shelve it until v1.2. It is fairly clear that routing will be highly affected by the design of named topics; while we probably shouldn’t attempt to formalize routing in any way in the v1.1 spec, we must keep it in mind while working on the named topic protocol. ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [May 16, 2025, 2:02pm UTC](https://forum.opencyphal.org/t/v1-1-roadmap-defined/2382/7 "2025-05-16T14:02:46Z")
> [@pavel.kirienko](#): > > Are you talking about traffic dumps like pcap/candump or something else? Logging that is transport agnostic but which can contain metadata about the transport if needed. Something that includes timestamps, the data type itself, a textual representation of the data, etc. The use case is logging with an ability to perform time-accurate playback in simulations. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [May 16, 2025, 2:13pm UTC](https://forum.opencyphal.org/t/v1-1-roadmap-defined/2382/8 "2025-05-16T14:13:50Z")
Something like this? [Postmortem dump analyzer tool](https://forum.opencyphal.org/t/postmortem-dump-analyzer-tool/2184) One record from there reformatted for clarity: ```json { "_meta_": { "ts_system": 1723389566.189359, "ts_monotonic": 892858.413041906, "transport": { "kind": "can", "source_iface": "slcan0" }, "priority": "nominal", "transfer_id": 4, "source_node_id": 0, "destination_node_id": null, "subject_id": 7509, "dtype": "uavcan.node.Heartbeat.1.0", "payload_hex": "44000000000000" }, "uptime": 68, "health": { "value": 0 }, "mode": { "value": 0 }, "vendor_specific_status_code": 0 } ```