Settings Sync : Allow for custom backend service end points

[jmarandet]

According to the Settings Sync Plan #90129 and to the Settings Sync documentation ( https://code.visualstudio.com/docs/editor/settings-sync ) it seems that only Microsoft and public Github account are supported.

What if we wanted to use a Github Enterprise backend, or any other git remote ( Gitlab, Gogs, whatever... ) ?

[sandy081]

We have plans to open backend for other service providers but it depends on the demand.

[vscodebot]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[IllusionMH]

See #84332 (comment)

[sandy081]

Yes. #84332 is for auth provider API. This is one piece of Settings Sync. This issue is for second piece - custom back ends for which we need standardise the settings sync service end point API.

Hence, based on the demand we will look into this.

@Tyriar FYI

[sandy081]

Assigning to @chrisdias, @egamma and @kieferrm.

[borekb]

Is Gist one of such possible backends? Or is it too simple for that?

I love how I can easily view my VSCode settings and the diffs between versions when Gist is used as a storage (this is done via the Settings Sync extension):

[sandy081]

@borekb Same is also supported in the current Settings Sync solution - #85619

[borekb]

@sandy081 I don't see it yet:

But even when this becomes available (and I'm glad for that!), I'd still prefer Gist as a transparent storage for my settings. For example, GitHub's UI is often more convenient / superior for certain tasks.

---

So back to my question, is Gist going to be (at least theoretically) one of the supported backends? Or would it need to be a more complex backend, implementing some prescribed set of APIs?

[sandy081]

I don't see it yet:

Issue was open then. I just enabled remote view and close the issue. You shall see it in next insiders.

So back to my question, is Gist going to be (at least theoretically) one of the supported backends? Or would it need to be a more complex backend, implementing some prescribed set of APIs?

This issue is for tracking the same. Its under discussion yet.

[chrisdias]

This is a good suggestion, but it not currently on the roadmap. We will put it on the backlog and consider it in the future.

[gudvinr]

To be honest, vendor lock-in on Microsoft (using built-in extension rather than opt-in installation) is really not looking good.

From all extensions (except telemetry which is not extension) Settings Sync is the first one which is tightly coupled with Microsoft online services and you can't just "not install" it.

This issue is the one that should be available when Setting Sync will go out in the wild.
Use of plain old directories or raw git access are things that deserve to be built-in and not some vendor specific API.

Relying on single provider is not future-proof solution.

[borekb]

Now that Settings Sync is becoming available in VSCode stable, see 1.48 update, I had to drop my previous sync data to start using the new Insiders service, i.e., a small data loss 😕 (see #104584).

I don't mind losing Insiders settings history too much but still, it made some problems of the current setup more apparent to me:

• I don't like it that my sync history is not owned by me. It is somewhere on Microsoft's servers, in some proprietary format.
• The format is also important – the settings sync extension used Gists which meant that not only I owned my data but also they were in a format that other "clients" could work with, for example, I could use GitHub's user interface to browse the history of my settings or git CLI to e.g. merge between Insiders and Stable.
• The VSCode team decides which "services" are available, for example, what if I wanted to have a third service for GitHub Codespaces?

I understand that custom backends are on VSCode's team mind, just not prioritized yet. My point is only to add some more arguments for support of custom backends.

[Chiramisu]

Just to throw my two cents, I think this is a great ideas for teams to implement a standard base set of Extensions and Settings, especially for new developers, or even to keep them all in sync. I suspect the former would be most probable though as most developers will likely want a quick "getting started" config, then to add or tweak those extensions and settings as they see fit for their own productivity. 😉

[mrdulin]

I want to use my private github repo to store the sync data. Does it support?

[akosyakov]

Hi 👋 is this issue opened for contributions in regards of alternative auth? At Gitpod we are running our Setting Sync Server which is compatible with VS Code and our users would like to be able to sync between local and Gitpod. Right now setting sync provider configuration is hard coded in product.json but it can be rather extended by 3rd party extensions similar to auth.

[scogginsnl]

Seems like any git repo should work.

This would be a great feature for people on closed networks. (yes there are plenty of other problems on closed networks)