Something I’ve always wanted when syncing data with apps is to have files on my machine and some kind of version control. So I’ve been working on Bind, which is a remoteStorage server that works with git. Been using it for some months and pretty happy with how it works.
Bind links multiple data sources and lets you choose which one when connecting storage to an app. Some consequences of this design:
flexibile enough to give apps sandboxed access or use existing files that weren’t created by a remoteStorage app.
platform tokens move to the server so each developer doesn’t need OAuth registration
apps don’t even know where the data is (not necessarily on account server)
servers don’t need to have ‘custody’ over an accounts data, they just relay between the app and data sources.
better-auth framework enables more extended login scenarios (for now just email/password)
“one-click” packages for Cloudron, Caprover, and Coolify, with secret auto generated on installation
bugs
/public folder access with no token only works if local disk is the data source; need to implement per-source usernames to route when there is no token
GitHub REST API is a bit slow, but hopefully usable
I’ve been using self-hosted Gitea repos synced via Git over HTTPS with much better performance, but it’s still undocumented/private as I need to implement an interface to enter credentials.
I could use some help with testing. Does it work? Any security considerations I’ve missed? Or architecture issues that will come back to bite me later? I’ve disabled GitHub issues on the repo because I want to use something else to manage that; still figuring out where so maybe just reply here for now.
Message me with your email address if you want me to invite you to the community server, which should become open access once social logins are implemented.
Lot of stuff missing probably but I think it’s important to put this out in case anyone finds it as useful as I do.
connecting technologies brings their users together, now I might be able to convince developers to use it because we could make Google Drive, and GitHub login work, hopefully sometime iCloud as well.
Google Drive and iCloud should definitely be in there. The sign in should already be possible with better-auth’s built-in adapters, which means it’s just a matter of mapping a handful of methods like get/put/list/remove/meta… I try to balance between framing Bind as ‘what it is’ versus ‘what it could/should be’, but definitely lean towards this kind of thing. If you want to contribute iCloud or Google support for example, let’s talk about it so we can plan together.
This also highlights some important tradeoffs: the rs.js + widget integrations with Dropbox/Google enable sync without intermediary but requires individual app/developer participation, and client-side/unhosted support can be hostile or with issues; moving integrations to a server solves some of that and allows any remoteStorage app to “work with Dropbox” without extra work for the developer – everything syncing via the predictable/open remoteStorage API means a more consistent app experience not complicated by platform specifics.
It’s interesting going through the GitHub issues, including the closed ones, for iCloud I’d expect at least the same amount of issues, as the DX is usually pretty bad for their products.
If we added iCloud auth to the servers instead of clients it might let people ship for Apple without having to pay 100$ a year, that would be huge.
Wouldn’t users have to make an extra step if Dropbox, Google Drive and iCloud were moved to the server? Because they would have to Sign-In with an intermediary?
I’m usually trying to make it the 1-click Sign-In that people know.
Thank you. This looks great.
I would love a git backend, but I also have considered doing this entirely client side - without an intermediate hosted broker. And started speccing this out for github/codeberg/Forgejo/gitlab. Though I’m not entirely sure it is possible. Has this been tried?
The idea being that the whole implementation lives in rs.js.
Also considering LFS as is may simplify things, and versioning is not critical for what I’m building - or I would prefer versioning to be a separate feature not tied to a backend.
Concerning ‘bind’ as a general broker to storage backends, its a cool idea. It would be amazing to plug this into rclone or something that already supports 100+ providers. However I think I would still want it configured via the browser, and not on the server somehow. For example the user would enter their s3 credentials via web/admin, not as an env var. That way the broker could serve many accounts across many services.
I wanted that as well. I tried to figure it with FAR but went the server route because it was important to support GitHub social login and it seems to require passing a secret. You can see on the FAR readme there’s a matrix of options with GitHub, but it all seems not friendly to pure client-side UX. Another approach could be isomorphic-git.
I think when things break or change, it’s easier to update the server than several decentralized clients, and prefer having easy to self-host options that can open up possibilities and make switching between them easier.
Will look into rclone, I was only aware of unifile which is inactive. I’m trying to remove the need for setting env variables so that it’s only the encryption secret that’s necessary, and I’ve already generated that one automatically on install.
Something I’m hoping I can work out is “bring your own credentials”, so that not only the self-hoster can connect to services but anyone with an account can as well. Perhaps this could be useful also in rs.js, for example if an app developer hasn’t supplied a Dropbox token, that the widget has an option for the user to supply their own one.
FAR looks interesting. I knew something like this must have been tried before, but could not find it in the forums. So I couple days ago I attempted some github experiments that seems to have arrived at similar conclusions:
Github oauth wont work since its cors blocked.
You can use PAT tokens instead. its less secure but gets the job done.
In 2025 github discussed creating a new workflow for authenticating Github Apps specifically to support SPAs, but I tried it and it did not work (yet).
If I were to go the full client side route I would probably stick with PAT for now.
Oh wow, never heard of isomorphic-git. Very intersting. I wonder how browser storage would keep up a large repo of git objects though. This has the potential to break down the barriers between git services, so you dont have to implement oauth for github, codeberg, etc. Has anyone tried working on that? It seems like it would kind of be parallel to remotestorage.js, but not really part of it.
This is interesting. So it seems like FAR would be something someone hosts for themself that only they would use to authenticate. But are you saying there would be a way to host a single instance that many people would use? And if so, wouldnt you be concerned that everyone’s credentials are going through your proxy?
Another thing I learned is that the OAuth access you get from GitHub and Gitea social login tends to be all repos, and I think for many people that do lots there it’s a bit too much exposure to leave that in local storage. You might be able specify more granular access somehow, but I think it’s not so straightforward and certainly not the default. Similar issue IMO to trusting any web app with an entire Dropbox folder. Servers enable scoped access and also can present an interface to select which repo you want an app to use (which I think would be too much to include in rs.js).
I didn’t use Personal Access Tokens because I want to help people who would at most know how to sign in with GitHub, but I this is also another good case for “Bring your own tokens”.
FAR was not really something to use, but just an exploration of how far I could get without needing a server; I hoped it could prove that a client-side app could request authorization and read/write data. I ended up with an accompanying “FAR server” for cases like GitHub that require secrets, but basically for my use case it made more sense to just do that as part of a remoteStorage server, rather than a separate single-purpose thing since someone already would have to expend effort to self-host; if I was more familiar with serverless functions as you are, I might have done something different .
I think I imagined the server component to be shared but yeah, it’s “people sending tokens through your proxy”… Maybe I hoped there would be some more sane way to do that if I got further.
The single instance that many people could use is now Bind and I think the usability for me as a developer (“change nothing”) and end-user (“link your account”) is orders of magnitude smoother than “generate your access token to start” / “trust my proxy with your credentials” / “do complicated OAuth for every app” / “trust a web app with too much access”. So far I’m happy with the tradeoffs.
.