Hey Pierre, Thanks for the write up. I am generally an advocate for more modular nifi deployments, and this seems like a good approach.
+1from me for a properties-configured extension registry client. Cheers, Kevin On Thu, Mar 19, 2026 at 7:11 AM Pierre Villard <[email protected]> wrote: > > Team, > > I'd like to start a formal vote process around NIP-4 [1] which aims to > introduce the concept of Extension Registry Clients that would also > deprecate the existing concept of ExternalResourceProvider for future > removal. > > The initial proposal was about introducing a completely new extension point > similar to the existing Flow Registry Clients but following discussion on > the NIP, we would go with a multi-steps approach where the first step would > be a nifi.properties level configuration of the extensions registry > clients. We would then evaluate if it is worth doing the work to add those > as true 1st class components in the NiFi UI - I have been running a POC for > both scenarios for quite some time now but doing so has the advantage of > making it easier to introduce breaking changes if needed. > > This change is also related to some additional work around the ability to > sign NARs [2] and the extension registry clients would support the ability > to only look for NARs that are signed by trusted entities. > > Finally, as we get closer to having the first release of NiFi with the new > concept of Connectors, the Extension Registry Clients would also be a nice > addition to externally retrieve connectors that are also packaged as NAR > files. > > Given that this is not a minor change, this vote is not following the > lazy-consensus approach and I'll leave this open for 3 days. > > The actual PR/code-change will still go through our normal RTC process. > > [1] https://issues.apache.org/jira/browse/NIP-4 > [2] https://issues.apache.org/jira/browse/NIFI-15675 > > Thanks, > Pierre
