@Arthur_Soares did a good job covering some of what I’m about to say in his documentation, but I want to restate it for the benefit of the community–
We don’t mind people tinkering with their own systems, and reverse engineering for the purpose of interoperability is generally not restricted legally unless encryption was broken, which is not the case here, so we are not going to do anything to interfere with this project.
That said, that this protocol is meant to be internal, and we can and do freely change it. We have a system of versioning and managing lockstep releases between clients/servers and we use it to make breaking changes fairly often. While this API exposes a lot of surface area, it does not document how to use the entry points properly, so there are some risks.
Misuse of this protocol can easily cause memory or compute leaks in the Roon Core. This protocol is engineered as an internal interface to be used by trusted code, and is not hardened for 3rd party use. There are requirements that must be followed carefully to ensure proper resource management across the protocol boundary. While Claude is at times a capable reverse engineer, I wouldn’t assume that it nailed the finer points of resource management across the protocol boundary.
The reason we support a more restricted official API is because that’s a surface area that we can commit to supporting indefinitely. This makes it a stable platform for building extensions that last years or decades without maintenance, but it also restricts it to the more core and immutable parts of the product.
In any case, I think that our support team delisted this thread because they weren’t sure about what to do with it. I’m going to make it visible again. Thanks for sharing, and hack on.