Thanks,
Ararat is fully client-side, so it does not expose an API. I am firm believer that all functionality should be contained within the Incus API itself, and if something isn’t possible that is needed, it would be better to change upstream rather than make a separate backend for Ararat.
While OpenFGA authorization is pretty straightforward to implement, Incus supports a variety of other methods, including scriptlets and restricted TLS clients, and Ararat needs to behave appropriately with those as well. A lot of people use projects to control access as well, so Ararat needs to behave well with those settings. The primary blockers related to authorization have been the scriptlets & project restrictions.
I’ve actually previously discussed a potential new endpoint to help remedy this here: Fine-Grained + Resource Authorization Handling on Incus API , and I think if we bundled some changes to how configurable options are handled alongside that, a lot of this overcomplicated stuff that is causing blockage would be remedied.
I think actually such an effort would generally be beneficial to the Incus community, as the documentation at-present of the various configurable options definitely need an overhaul, and going through each one is a lot of work. This is the perfect excuse to get it done, and I already have quite a head start there with the Ararat implementation as-is 
. I think the hardest part (beyond the deep dive into each existing option) is maintaining backwards-compatibility with the current definition methodology, because we wouldn’t want to break any already in progress PRs or functionality in clients that depend on the legacy system.