We send an event when you insert something using Fig's autocomplete, so we can get a sense for how frequently people use the app. We also send which completion spec (eg. git, npm or cd) was used to generate the suggestions to know which commands to prioritize.
And this is why you're never going to get people to use it. I get that you want to know what is being used, but really -- this is a terminal. You can't have any kind of telemetry for a terminal.
If you had a very big notice when you install, asking for permission to send which commands get autocompleted, you'd have likely been in a better position. Debian does something like this on install -- asking permission to track what packages you've installed. But it very clearly optional. And their level of knowledge is just that a package was installed, not necessarily how frequently it it used. Anything approaching telemetry within a terminal is just a bad idea.
And I fail to see how you couldn't also get the same data from surveys, features requests, issue tracking, etc... It wouldn't be the same quality, but this is really really bad. And because you started out with this major faux pas, you're going to have a major problem with trust going forward.
What does 'prioritize' mean in this context? Other completion tools (like fasd) write command history to a local dotfile so they can build up knowledge of 'frecency'. This makes sense, it's no different to your ~/.bash_history file really. I wouldn't trust any single tool that tried to build a parallel history through an analytics integration.
Fig claims that it 'loads up once then remains entirely local', though, and it's adorned with an icon that suggests it remains offline.
What you're saying here seems to contradict that. If the tool is entirely local/offline, how is it phoning home with the commands you type? And does it send along the arguments you pass to the command if you happened to complete them?
It's one of those things that is just trivial to introduce breaking changes to, though, intentionally or otherwise. And as-is the functionality does share what amounts to the terminal activity in normal cases.
Then why on earth did you go out of the way to implement this in JavaScript instead?
As Fig grows, we want to enable an ecosystem of UI extensions for the terminal that are built to go cross platform. Using web technology here made sense since we can leverage built-in webviews for rendering or bundle a lightweight implementation like Tauri[0].
[1]
This page https://fig.io/docs/getting-started says that Node.js and NPM is required to use Fig. I presumed this meant that Fig was written in JavaScript, but you're saying it's native. Then why is Node required? If you're using web views for UI, wouldn't those web views on each respective platform already have their own JS engines?
As for the telemetry concerns, I totally get that. We've tried to strike a balance and it seems like we've got it wrong. This will be fixed in the next update.