# Consider the implications of renaming the "uavcan" namespace into "cyphal" **URL:** \ **Category:** Development & Maintenance\ **Created:** [September 2, 2023, 1:43pm UTC](https://forum.opencyphal.org/t/consider-the-implications-of-renaming-the-uavcan-namespace-into-cyphal/1975 "2023-09-02T13:43:00Z")\ **Posts on this page:** 9\ **Page:** 1
**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:** [September 2, 2023, 1:43pm UTC](https://forum.opencyphal.org/t/consider-the-implications-of-renaming-the-uavcan-namespace-into-cyphal/1975/1 "2023-09-02T13:43:00Z")
The `uavcan`/`cyphal` duality is considered harmful: > > > Many many reasons why but here are two things that need to be fixed: > > 1. Alway…s recheck and rebuild the database when environment variables change. For example, I just wasted 15 minutes trying to figure out why pycyphal was trying to connect to UDP only to discover that my previous value UAVCAN\_\_UDP\_\_IFACE was somehow part of the db. Once I deleted this and restarted my new environment variables were found. > 2. Always accept "CYPHAL\_" where "UAVCAN\_" is currently required. It's really hard to remember which of the environment variables are UAVCAN and which are CYPHAL. Either should be accepted but CYPHAL should be documented. On the other hand, the possibility of renaming the `uavcan` namespace into `cyphal` raises backward compatibility concerns: > [@Root Namespace uavcan.\* after Rebranding](https://forum.opencyphal.org/t/root-namespace-uavcan-after-rebranding/1644): > > In the past few days and weeks, many projects comprising the OpenCyphal ecosystem have been updated to reflect the new name. Do I assume correctly that the [uavcan.\* root namespace](https://github.com/OpenCyphal/public_regulated_data_types/tree/d0bd6516dac8ff61287fe49a9f2c75e7d4dc1b8e/uavcan) will be renamed as well? If yes, what would be the expected timeline and strategy? Do we want to explore the possibility of safe renaming to minimize the confusion and make the technology more approachable? ---
**Author:** ![erik.rainey](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/erik.rainey/32/20_2.png) [@erik.rainey](https://forum.opencyphal.org/u/erik.rainey)\ **Post date:** [September 2, 2023, 2:27pm UTC](https://forum.opencyphal.org/t/consider-the-implications-of-renaming-the-uavcan-namespace-into-cyphal/1975/2 "2023-09-02T14:27:23Z")
An alias, using or import ability would help but could open the door to some abuse. Each language can already do some of this except C, which would have to make a bunch of macros. Would this be pulled into the dsdl then use language features to replicate? ---
**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:** [September 2, 2023, 2:34pm UTC](https://forum.opencyphal.org/t/consider-the-implications-of-renaming-the-uavcan-namespace-into-cyphal/1975/3 "2023-09-02T14:34:48Z")
I think at the language level this can be addressed in a rather straightforward manner, even if it requires special casing within Nunavut (e.g., alias everything as you suggested). We should rather be concerned about the wire compatibility issues. For example, old nodes follow the current register naming format `uavcan.(pub|sub|cln|srv).PORT_NAME.(id|type)`, `uavcan.udp.iface`, etc.; while after the renaming the format will switch to `cyphal.(pub|sub|cln|srv).PORT_NAME.(id|type)`, `cyphal.udp.iface`, etc. This affects, for example, Yukon, which expects special registers to have the `uavcan` prefix, but as we control Yukon, we can easily implement the required mitigations. The important question is: are there applications out there that will be adversely affected by this change? ---
**Author:** ![aentinger](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/aentinger/32/1428_2.png) [@aentinger](https://forum.opencyphal.org/u/aentinger)\ **Post date:** [September 2, 2023, 3:39pm UTC](https://forum.opencyphal.org/t/consider-the-implications-of-renaming-the-uavcan-namespace-into-cyphal/1975/4 "2023-09-02T15:39:05Z")
> [@pavel.kirienko](#): > > The important question is: are there applications out there that will be adversely affected by this change? Precompiled DSDL for 107-Arduino-Cyphal would need to be recompiled, the changed namespace would constitute a breaking change for all applications that already leverage it. That being said, I’d consider this proposal a “worthy” breaking change. ---
**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:** [September 8, 2023, 8:59am UTC](https://forum.opencyphal.org/t/consider-the-implications-of-renaming-the-uavcan-namespace-into-cyphal/1975/5 "2023-09-08T08:59:02Z")
Another exhibit: > [@Developing pico node using Yukon](https://forum.opencyphal.org/t/developing-pico-node-using-yukon/1978/3): > > Oh my bad. I put cyphal.sub.PORT\_NAME.type instead of uavcan.sub.PORT\_NAME.type now everything works! Thank you! ---
**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:** [September 8, 2023, 5:25pm UTC](https://forum.opencyphal.org/t/consider-the-implications-of-renaming-the-uavcan-namespace-into-cyphal/1975/6 "2023-09-08T17:25:27Z")
I think this is a bit of a non-starter _unless_ we can do this in a phased manner where both are supported for a time. Another thing that might actually help with the problem I was discussing the other day (i.e. that the number of optional types in our public, regulated set are daunting) is to keep only the most fundamental types as `uavcan`. For example, Heartbeat and GetInfo and the types they depend on would remain `uavcan` but everything else would change? ---
**Author:** ![lydiagh](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/l/c57346/32.png) [@lydiagh](https://forum.opencyphal.org/u/lydiagh)\ **Post date:** [September 8, 2023, 5:34pm UTC](https://forum.opencyphal.org/t/consider-the-implications-of-renaming-the-uavcan-namespace-into-cyphal/1975/7 "2023-09-08T17:34:44Z")
This would require a lot of duplicated code, but what if we had a `uavcan` and a `cyphal` namespace in the `public_regulated_data_types` repo. That way, people who are still using UAVCAN can continue to use the `uavcan` namespace and people using Cyphal can use the `cyphal` namespace. Another option is what if we left the `public_regulated_data_types` repo alone and made a new repo called `cyphal_public_regulated_data_types`. Neither of these options are very clever, but might be the most straightforward. ---
**Author:** ![aentinger](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/aentinger/32/1428_2.png) [@aentinger](https://forum.opencyphal.org/u/aentinger)\ **Post date:** [September 9, 2023, 6:46am UTC](https://forum.opencyphal.org/t/consider-the-implications-of-renaming-the-uavcan-namespace-into-cyphal/1975/8 "2023-09-09T06:46:37Z")
> [@scottdixon](#): > > to keep only the most fundamental types as `uavcan` This strikes me as a dangerous half measure. DSDL: Either a hard cut or dual support forever. Devices that are already in the field are unlikely to update to the cyphal namespace anyway. Tooling on the other hand should support both namespaces for quite some time (possibly forever). ---
**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:** [September 9, 2023, 7:00pm UTC](https://forum.opencyphal.org/t/consider-the-implications-of-renaming-the-uavcan-namespace-into-cyphal/1975/9 "2023-09-09T19:00:08Z")
> [@scottdixon](#): > > I think this is a bit of a non-starter _unless_ we can do this in a phased manner where both are supported for a time. There are two aspects: renaming the DSDL namespace itself and renaming the registers. The DSDL renaming can be done by copying all non-deprecated definitions from the `uavcan` namespace into `cyphal` with the appropriate changes to the documentation where the original namespace is referenced. All `uavcan.*` definitions will be made `@deprecated` immediately, with their complete removal deadline set somewhere in the future. The standard register names will be updated from `uavcan.*` to `cyphal.*`. Nodes will be encouraged to support both to enhance compatibility with old tooling, but we don’t want to unnecessarily burden new applications with supporting the legacy register naming scheme, so `uavcan.*`-named registers will be optional, and the new `cyphal.*` pattern will take precedence. The latter change will make new nodes incompatible with the existing tooling, such as Yakut and Yukon. This is easy to address at this stage as these are the main Cyphal tools and we can implement the necessary adjustments fairly easily. In particular, Yakut/Yukon will attempt to query `cyphal.*` registers first and only fall back to `uavcan.*` if none are found. > [@lydiagh](#): > > This would require a lot of duplicated code, but what if we had a `uavcan` and a `cyphal` namespace in the `public_regulated_data_types` repo. That way, people who are still using UAVCAN can continue to use the `uavcan` namespace and people using Cyphal can use the `cyphal` namespace. I think this is sensible as long as we make it clear that the `uavcan` namespace is deprecated and is on its way toward its inevitable EOL. > [@aentinger](#): > > This strikes me as a dangerous half measure. Indeed.