Feature Suggestion API/JSON/CURL

[azev]

I suggest adding a API functionality so it can be used with curl from the command line.

something like:

curl "https://ffprofile.com?template=high,noannoyances,noaddons" -o user.js

or

curl "https://ffprofile.com?template=my-custom-template" -o user.js

also check https://mycroftproject.com/

[allo-]

Some API is a nice idea, but I think these endpoints do not make much sense, as they would produce a set of static user.js files. And I do not see if there is a demand for this, as the settings files used to generate the result are open source. You could generate a set of all combinations of options and just provide a zip file with a few hundred files to choose from and will not need an API anymore.

I think it may be a good idea to have an api that provides the questions and accepts answers and then generates a user.js file. But on the other hand, when you specify a structured format to transfer the questions, you will end up with something that is basically downloading the settings and profiles JSON files. If the API does not do more than providing these files, I am not sure why you should not generate the user.js file locally. See #169 for the project to create a command line tool.

The download option would make sense for browser extensions or other frontends, that do not want to sync with the source repo. An API to upload your existing preferences and download it merged with new options would be interesting, but for privacy reasons it is probably better to do this locally as well. I want to do this in browser javascript, see #25. Other programs, extensions, ... are welcome to do the same.

[azev]

The API main idea is to get the user.js in a single command (curl). Another very useful API parameter would be the version filter ?ff_version=69.0 so it would discard settings that applies only to prior versions.

?new_log=69.0 show what are the new settings added for the FF v. 69.

You could group the settings into tags so the user can select prefs by tags:

?include=privacy,high-security,main-security,max-security,ui-tweaks,no-candies,no-annoyances

In the .zip file you could include search.json.mozlz4 generated by https://mycroftproject.com/

?searchEngine=mySearchEngineName (from a limited clean list)

Say the user go to the website and generates a customized prefs.js. In the end, you could add an option like key=e72a0139ff03 so the user could:

curl "https://ffprofile.com?key=e72a0139ff03" -o user.js

[allo-]

The API main idea is to get the user.js in a single command (curl).

How do you want to transmit the configuration data?

?new_log=69.0 show what are the new settings added for the FF v. 69.

There is currently no such information. Most stuff keeps working for future versions, some stuff needs to be replaced for newer ones. I guess supporting too old versions is not useful anyway, as bad security (unpatched Firefox) does not go well with good privacy.

?include=privacy,high-security,main-security,max-security,ui-tweaks,no-candies,no-annoyances

This can only include the default settings of each section, because no further settings are given in the commandline.

Say the user go to the website and generates a customized prefs.js. In the end, you could add an option like key=e72a0139ff03 so the user could: curl "https://ffprofile.com?key=e72a0139ff03" -o user.js

This would be possible, but what does you prevent from clicking the final download button? I think I could add this either by encoding the choices into the URL or by creating a link with the session token (which will expire), but when your link is ready, you're on the page with the download buttons anyway.

[azev]

Also, the API could accept custom entries starting with_:

user_pref("app.normandy.enabled", false); -> _app.normandy.enabled=false

curl "https://ffprofile.com?key=e72a0139ff03&_app.normandy.enabled=false" -o user.js

[azev]

This can only include the default settings of each section, because no further settings are given in the commandline.

Also, the API could accept custom entries starting with _:

user_pref("app.normandy.enabled", false); -> _app.normandy.enabled=false

curl "https://ffprofile.com?key=e72a0139ff03&_app.normandy.enabled=false" -o user.js

[azev]

This would be possible, but what does you prevent from clicking the final download button?

The main idea of an API is to automate, instead of visting the website and doing it all manually

[allo-]

It could accept such parameters, but I still do not really get what's the advantage. For this you could just run

$ echo '_app.normandy.enabled=false'|sed 's/^_/user_pref("/;s/=/", /;s/$/);/'
user_pref("app.normandy.enabled", false);

The main idea of an API is to automate, intead of visting the website and doing it all manually

But what advantage does a webservice provide there? You would need a frontend like the project in #169 to automate it and this frontend could use local data without needing an API. The website does not provide anything, that you cannot process locally with the data in this repo.

[azev]

I think you have a great project there. Youd should add a simple API just to see how it goes and add the features slowly. A good one to start would be the What's new: ?new_log=69.0

+ app.normandy.enabled
+ app.some.new.option
+ app.some.new.option2
- app.some.old.option
- app.some.old.option2

[allo-]

There currently is no information about the supported versions for the options. When you want to collect this information for all settings it can be added to the JSON (it could be useful, but it is not important as long as old options do not harm).

When we have this information, it is probably still the best solution for external tools to use the JSON data directly without querying an API. The settings data is static and only the on/off information is used to combine it to a common user.js file.

[azev]

I started this http://configfox.sourceforge.net/ project years ago but I no longer maintain it. If you create an API it would be a next step to create end-user apps that could run based on your API.

[allo-]

A GUI or CLI interface would be nice. But I think it should work with the raw JSON files, this does not require an API. You can just download them or clone the repo. https://github.com/allo-/firefox-profilemaker/tree/master/settings

When there are really several frontends in the future, the settings files and the frontends could be maintained in different repos, so you do not need to clone the django code just to get the files. But I think this has at least time until there are working prototypes for other interfaces, like #169.

[allo-]

I close here for now, until I see a real reason for an Web-API.