Stylus: Synchronize style subscriptions across browsers

Created on 6 Jun 2017  ·  24Comments  ·  Source: openstyles/stylus

Is this somehow possible?

enhancement

Most helpful comment

I really like the idea behind a VS Code extension "settings sync", which makes use of Github Gist to synchronize a "cloud" settings.json.

I suggest stylish-chrome could do something similar. It's a clever way to allow syncing with zero server costs, just a Github user and access token. Github Gist even tracks revisions, which can be helpful for tracking changes over time. Users could even open a gist to public for others to import.

Just throwing it out there as an idea!

All 24 comments

Currently you can do it only by manual import/export of the style database.

I really like the idea behind a VS Code extension "settings sync", which makes use of Github Gist to synchronize a "cloud" settings.json.

I suggest stylish-chrome could do something similar. It's a clever way to allow syncing with zero server costs, just a Github user and access token. Github Gist even tracks revisions, which can be helpful for tracking changes over time. Users could even open a gist to public for others to import.

Just throwing it out there as an idea!

browser.storage.sync API

@sabret00the, it's only within one type of browser. The topic however is about browser-independent sync. At least this is how I interpret it. Also, the built-in sync API is too limited. Of course it may be useful in some cases so we'll see.

Any plans to make this happen? I tried to manually sync the local sqlite database (with symlinks and OneDrive) but unfortunately the assigned machine-specific moz-extension UUID is written into the file as well. Firefox reads the file but ignores it because of the different UUID

Well, no one is working on this.
Also, Stylus doesn't use sqlite.

Isn't it just "storage.sync" instead of "storage.local" to enable cloud syncing?

I know that, what I meant is the sqlite file created by Firefox's web extension storage API.

Not, it's not because storage.sync is severely limited so we can safely use it only for small stuff like extension settings.

Oh okay, too bad..

@tophf, couldn't you just sync the name/address of a style (from userstyles.org) and then all we had to do was to update? It would be better than having to export and import stuff.

@FeBe95, you would lose style variables/customizations with that approach so db export is better.

Well, yes you would, it's definitely not a 100% solution, but it would work just fine for people who don't customize. It's much easier just clicking on "update" than having to export the db, move the file to another computer and import the db. Having to constantly do that is a bit annoying.

So you suggest we just ignore the people who do customize their styles? Don't seem to be a good approach.

Well no, of course not. A proper solution should be there, but since it's impossible (for now), why not make some people happy?

I don't see any way of implementing it ("it" being your idea) without pissing off those who do customize styles. Either the customized styles won't be synchronized at all, which is terrible, or their settings won't be synchronized, which is almost as bad.

Hi, I'm interesting in this issue and I'd like to know if there is a problem if I try to implement the browser.storage.sync API into Stylus (thinking firstly on Firefox - I already used it) and push it to the repo.

ps: later I can try to implement the chrome version of it.

@matheusfaustino To quote tophf:

...storage.sync is severely limited so we can safely use it only for small stuff like extension settings.

Not using it for syncing styles was a choice, because many users who create their own styles would have DBs too large for storage.sync.

Pretty sure we're all open to alternative methods of syncing through popular storage sites like Google Drive, Dropbox, or others. A PR for that would probably be pretty popular, but nobody has volunteered, as of yet.

Tampermonkey supports many cloud services, why doesn't Stylus do?

Because Tampermonkey is developed by a different developer who dedicates his time to develop his extension. Stylus is not developed by the same developer. Stylus is a community project and is maintained [mostly] by the former users of Stylish. The core maintainers don't need the cloud sync which is why they don't develop it. It'll be added soon anyway, see the pull requests section.

I can't disagree with it being a different developer with ability to dedicate efforts etc. with Tampermonkey vs Stylus, but I will absolutely disagree with the "can't" comments above. I personally sync a current total of over 400 userscripts between all my Chrome browsers using the Browser Sync API option in Tampermonkey.

That's not all the other cloud backup/restore options (I use both Google and Onedrive for that) - but I find the straight Browser Sync API option to be pretty flawless and after years have yet to run into a single issue or failure with what's being discussed in this enhancement request. Any addition of those other backup/restore options would also make life much easier since many of us have long since (pardon the pun) dropped dropbox. :)

+1 on this being raised in priority. TIA!

I also think this feature should be a priority.

There's a couple of ways to do it.

  1. Sync through a gist. Would be trivially simple to do. Just use the Github API and auth token to push changes to a gist which then could be read in raw format using a url.

  2. I use NextCloud. It's a great open source self hosted cloud platform. I highly recommend it! This method might actually not require any changes if one uses it to host a user.css file. I'm looking into how that works first though. Would honestly be nice if I could just load css from my cloud server instead of from the extension anyway as I could then use scss to better break up my stylesheets and manage them more elegantly.

@narcolepticinsomniac why was this issue closed if it is not resolved? It should be left open so someone can _see_ that this is a feature people want… it's harder for someone in the open source community to contribute when they can't see what needs to be done.

It says "narcolepticinsomniac closed this in #787", meaning this issue was automatically closed when the PR which implements this feature was merged into the master. If you can't tell that much, maybe resist the urge to lecture anybody on how open source works.

Sync works fine in the master, and should be pushed in an update in the near future. We all took a break over the holidays, and we've run into a minor snag with sync compatibility in Opera and beta. One way or another, we'll work it out, but it isn't even something which can be tested in the master.

This is all I can see in the GitHub Mobile app, my apologies. I based my comment on your initial response above + the issue being closed without knowing why.

Now I know that the app leaves out important contextual information, and I'll check the desktop site for things like this going forward.

Again, my apologies.

Was this page helpful?
0 / 5 - 0 ratings