3 ms·
Not tried yet but I’d love to make a JS front end library to “bring your own storage” so that if I provide you with an app online (think SPA) it can then save t
by quickthrower2 6y ago
Not tried yet but I’d love to make a JS front end library to “bring your own storage” so that if I provide you with an app online (think SPA) it can then save the data to where he used wants (s3, Dropbox, local disk using extension, etc.)
Another similar idea is a very simple rest protocol so that you can save to server and then make it easy to self host it.
I like the idea of people building apps as web pages without needing to worry about the server and the user owning their data but having the convenience of a cloud like solution where you just visit the site, log in and work.
- shezi 6y agoSomething like https://remotestorage.io/ https://remotestorage.io/ ?
- mc3 6y agoIt feels a bit like hard work to use. They seem to have support for Dropbox but just as an afterthought and not the main thing. The main thing means running your own server, but it doesn't look easy to set up. I want to think of an approach that is really easy to use so it becomes popular for that reason.
- shezi 6y agoHmm, I have never tried to run a server. At least the integration seems to be fairly easy.
- ohadpr 6y agoI’ve thought about this concept a bunch and I think there are real commercial opportunities there. Namely I don’t want to pay Dropbox a markup over S3 and develop a dependency on them. What I prefer is to purchase the software from Dropbox and self host/store it wherever I want. Same goes for email, office suite, photos, etc.
- oscargrouch 6y agoIm almost finishing something that can do this, and my hope is that it can be a "browser dissident". The storage can be shared through bittorrent with applications and data(files and key-value database) already layed out on top of a userspace filesystem layer (the key-value goes through a sqlite btree). All the data blocks can be shared thought bit-torrent, and everything, including the ui apps and the service application are also shared the same way. When the dev application is launched, there's a middle-man that works like a server instance (the developers have total control into what is handled via RPC and the RPC api layout), and will launch rpc services, where the embedded application will consume by opening a url served/routed through the central host process (that centrally manages applications, processes, ipc, rpc, data, etc) I've made this starting from a Chrome codebase, so its multi-process, with a web engine embedded (that will only be used by the ui application) but that you can control much better through your application api, aka the UI process. The first language that have access to this is swift.. so the devs will deploy in their shared storages code/binaries for the rpc handlers (the app instance or service process) and the ui applications that happen to have full access through an api to the web layer/renderer. It was hard to get where i am right now, but im almost finished, and even now, it looks pretty cool already. I think that with a little more work, it can even serve to create not just p2p applications, but also distributed with pools of servers working through RPC with a help from the p2p layer.
- _theory_ 6y agoThis sounds like a modification of the JAMstack idea.