gitcoinbot
commented
2 years ago Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Workers have applied to start work.
These users each claimed they can complete the work by 1 day, 11 hours from now. Please review their action plans below:
1) cazuky has applied to start work _(Funders only: approve worker | reject worker)_.
This seems like a fun project, I'm super excited to work with the Fair Data Society team to build Fairdrive personal storage application with offline, I think this solution will empower a lot of users to securely and privately access and store their data.
My work plan:
- Meet with the Fair Data Society team to understand needed levels of approvals and project requirements;
- Setup project management and main extension features;
- Learn more about dfs, Fairdrive, and HTTP API reference;
- Design the solution, wireframe, and data management;
- Build the solution following the project requirements;
- Meet with the Fair Data Society team to present the project for review and QA.
- Work improvement, etc... 2) theosch has applied to start work _(Funders only: approve worker | reject worker)_.
I can make a FUSE driver for fdp-storage for Linux and equip it with convenient tools to set it up and mount/unmount a storage. 3) shr1ftyy has applied to start work _(Funders only: approve worker | reject worker)_.
I will attempt to write a FUSE driver for swarm storage. I've integrated an IPFS backend to duplicity before (see https://gitlab.com/duplicity/duplicity/-/merge_requests/42) , but have never worked with FUSE before so this would be a great opportunity to do so. 4) tms1337 has applied to start work _(Funders only: approve worker | reject worker)_.
Who will work on the project
We are a team and a consulting company consisting of people with 5+ years working in the crypto industry.
We are all full-stack and smart contract developers (at least the core team). We can of course extend team and add additional frontend and backend people as needed, since we have a good personal network of developers.
We also have a lot of both developer and business experience. We usually do consulting, specifically in the domains of crypto, software architecture, and financial risk management. But we also like to build our products or do the outsourcing of the fun ones.
As a side-note we also are in the field of education where we make bootcamps and courses for coding (including smart contracts).
Here are some points that might distinguish us from the rest of the applicants:
- we’ve been in crypto development space for 5+ years, working in some of the big names
- we do TDD, meaning we first write end-to-end tests in Selenium, cypress etc, but these tests also serve as a feature documentation and good way of communicating the definition-of-done (DoD) with a client
- we try to use immutability and functional programming to ensure testability and/or provability of the software correctness, we call the approach “as functional as needed, but not more“
- we do visual analysis and design of the project before starting using mocks as a communication tool, we think this way there is no place for confusion of requirements up-front
- we have feedback round at each stage of the project and have intense communication with the client where needed
- we are versatile and can use variety of programming languages ranging from cpp to Scala, which can come in handy when handling OS level stuff
Description and user flows
You can see the sample demo at: // TODO: add sample demo video url Below are descriptions of some of the common user flows that we expect to have. Note that some parts are semi-technical, but that is expected for this type of project.
Installation:
- we need to be as frictionless as possible!
- easiest way: just visit the website
- visit https://myfds.xyz (we bought the domain already)
- after the first visit, website will automatically make a cached copy so that this site is available even when offline
- it will also download web workers, they can call .wasm files so we can use even non-js languages if needed
- web workers will periodically do tasks required in the background, even when website is closed, but browser opened
- this approach makes it scalable to extend and add any background tasks required in the future (every process can be a separate web worker)
- this approach also makes updates trivial, each time connected to the internet, website and webworkers will download the latest versions
Usage - initializing mount folder:
- step 1 is to login with your fds credentials
- after login, user will be able to enable the auto-sync and files mounting (toggle button of some sort, see demo)
- when activated, auto-sync will start in the background via the webworkers
Usage - configuring the mounted folder:
- user will have several configurable options in the web app
- one of them will be toggling auto-sync or maintaining the sync on-click, this could be useful for some cases where do not want a large amount of data to be transfered
- user will be able to encrypt/decrypt the mounted folder, so that even if the local computer is compromised, the data will be safe (self-ransomware if you will haha)
- user will be able to unmount/delete the mounted folder
- user will be able to see the list of actions needed to be taken in order to sync the local and network versions of folders (useful for manual sync on-click to see what will be synced, also handy for tracking progress percentages of files synced)
- when logged out, auto-sync will stop
- [optional] perhaps it would be nice to be able to limit the amount of data synced for some use cases…
Usage - access data while offline:
- if logged in: same options as in online mode, except that sync can’t be done
- if logged in: files can still be encrypted/decrypted
- folder can still be accessed/opened locally (unless encrypted, then still can be found but if not logged in no way of decrypting the files)
Milestones and timeline
Here are the steps that we plan to undertake (in chronological order):
- make the prototype that does dummy actions and tests the OS specific APIs that need to be used
- do the design and analysis, output of which are end-to-end tests and mocks that are used as documentation and communication tool
- plan the architecture, setup the collaboration tools and workflow
- implement end-to-end tests (fail first), so that we know we are done when all the tests are passing
- make website with dummy connectors
- write connectors library/SDK
- connect website to real connectors
- do additional manual testing
- (if possible based on architecture) try to prove some properties of the system
Technical plan and details
Here are some optimization and implementation ideas we already bounced around:
- we can use checksums and hash trees for efficient diff checking
- [optional] we can pre-encrypt the files so that when encrypting they are already there, we just remove the unencrypted versions (we can have naming convention, plus hide these in the actual explorer)
- sync() will calculate the diff, based on it generate actions to be undertaken, and then would try to run them all in parallel, N at a time to be faster
- execute({action}) will be system specific and is easy to extend even for some future OS that we need to support 5) chipelll has applied to start work _(Funders only: approve worker | reject worker)_.
I am the leader of my 10-20 member committee of developers, we have done a couple of work similar this, but this is a little bit different because we're are mounting it as a drive. Anyways experience will make us deliver a better project and also deliver faster because we would have learnt from our mistakes. Be guaranteed to have the best project on time
Learn more on the Gitcoin Issue Details page.
tms1337
Motivation / background / user story:
There are many instances in which people do not have access to the internet and therefore cannot access data that is not stored locally. To empower user's with not only private and secure data is one thing, to enable user's access to said data while offline is another problem to solve for. To aid in the growth of Web3, this bounty will allow user's to access their data in Fairdrive personal storage while temporarily unable to access the internet.
As a User, I would like to access my Fairdrive personal storage even though I'm offline, so that I can securely and privately access what I need without internet access.
Tasks
Approving criteria
Timeline
This bounty is estimated to take between 80-160 hours.
Deadline: 4 calendar weeks after approval
Compensation: In BZZ tokens in amount of 4000 DAI for each OS implemented at the date of payment (as of the price of BZZ / DAI on the day of the payout as determined by Fair Data Society).
Bounty process
References
Use the Fair Data Society Discord for more information and support.
Mind the Fair Data Society Principles in your tasks.