Open Grant Proposal: Cross-Platform FUSE API

[markg85]

Open Grant Proposal: Cross-Platform FUSE API

Project Name: Cross-Platform FUSE API

Proposal Category: Developer and data tooling

Individual or Entity Name: Individual

Proposer: @markg85

Project Repo(s) https://github.com/crazyfuse (This project will be called Crazyfuse and will live in these repositories)

(Optional) Filecoin ecosystem affiliations: None

Technical Sponsor: Dietrich Ayala (@autonome)

Do you agree to open source all work you do on behalf of this RFP under the MIT/Apache-2 dual-license?: Yes (I intent to use the MIT-0 license)

Project Summary

The goal of this project is to create a cross-platform FUSE (Filesystem in Userspace) API that enables developers to create filesystems that work seamlessly across multiple platforms, including Windows, macOS, and Linux. This API will provide a unified interface for interacting with local filesystems, allowing projects to integrate with these systems more easily.

Currently, developing a filesystem that works across multiple platforms is a challenging task, requiring a significant amount of time and effort to implement and maintain platform-specific code. The lack of a standardized, cross-platform FUSE API hinders the adoption of filesystems in various projects, limiting their ability to provide a seamless user experience.

This project aims to create a foundational infrastructural component that extends beyond the scope of Filecoin/IPFS, but rather addresses a widespread need in filesystem development. By providing a cross-platform FUSE API, we can simplify the process of developing and deploying filesystems, making it easier for projects to integrate with local systems.

Impact

The proposed project will have a significant impact on the Filecoin and IPFS ecosystems by providing a standardized, cross-platform FUSE API that enables developers to create filesystems that work seamlessly across multiple platforms. This will simplify the process of developing and deploying filesystems, making it easier for projects to integrate with local systems.

The benefits of this project include:

• Simplified development and deployment of filesystems
• Much improved integration with local systems
• Potential adoption of filesystems in various (namely, but not exclusive to, distributed storage) projects

The risks of not getting this right include:

• Continued fragmentation of filesystem development
• Limited adoption of filesystems in various (namely, but not exclusive to, distributed storage) projects

Success for this project can be measured by the adoption of the cross-platform FUSE API in various projects and the simplicity of developing and deploying filesystems.

Outcomes

The final outcome of this project is a new, well-documented, cross-platform FUSE API that enables developers to create filesystems that work seamlessly across multiple platforms. To demonstrate the effectiveness of the API, a proof-of-concept example implementation will be provided, which will work on at least Linux and Windows. This implementation will be a fully functional filesystem, featuring:

• Files and folders appear locally on the user's computer, visible in their file browser of choice (e.g., Windows Explorer, macOS Finder, Linux file managers), giving users a seamless and intuitive experience.
• Users can interact with the filesystem using standard file system operations, such as drag-and-drop, copy-paste, and file system navigation, without needing to learn new commands or interfaces.

The API will be thoroughly documented on a website, providing clear instructions and guidelines for developers to create their own filesystems using the API. This will enable developers to build a wide range of applications and services that can leverage the power of filesystems, without requiring users to have extensive technical knowledge or experience.

By providing a low-barrier-to-entry solution for users to interact with filesystems, we can increase adoption and usage of decentralized storage solutions, and enable a wider range of use cases and applications that can benefit from the power of filesystems.

Adoption, Reach, and Growth Strategies

The target audience for the cross-platform FUSE API are projects that manage user data in various forms. The primary goal is to enable these projects to make their data accessible to users on their local file browser.

To promote the adoption of the API, I will employ the following strategies:

• Outreach: Relevant projects and organizations will be contacted directly to inform them about the API and its benefits.
• Blog posts: Articles will be written and published on the project's website to showcase the API's capabilities, provide tutorials, and share success stories.
• News articles: Efforts will be made to get the API featured in news articles and publications that cater to the target audience.
• Conference engagement: Throughout the project, I plan to attend relevant conferences, such as IPFS and Filecoin events, to keep the community informed about the project's progress and generate interest. This may include networking, informal discussions, and potentially giving talks or presentations, depending on the project's progress and opportunities.
• Onboarding: The ultimate goal is to make the API an attractive solution for any project that wants to provide seamless access to user data across multiple platforms. This includes a wide range of potential candidates, such as decentralized storage solutions (e.g., Filecoin, IPFS, StorJ, Sia, Arweave), smart contract data, and even traditional web2 storage giants (e.g., Dropbox, OneDrive, Google Drive). By adopting the cross-platform FUSE API, these projects can simplify their development process, reduce maintenance costs, and expand their reach to users on all supported platforms. As an example, a project like IPFS, which already has a FUSE implementation, could clean up its codebase and rely on the new API, thereby gaining the same benefits.

Note: The projects mentioned above are just a few examples of the many potential candidates that could benefit from this API. However, it is essential to contact and engage with relevant persons in each of these projects to gauge their interest, gather feedback, and ensure that the API meets their specific needs and requirements.

Development Roadmap

The development process will be broken down into 5 milestones, with estimated timelines and resources required for each milestone.

Milestone 1: Windows Backend Implementation

• Tasks: Design and implementation of Windows-specific backend for the FUSE API
• Estimated duration: 1.5 months
• Resources: Myself, with expertise in Windows development
• Dependencies: None
• User Engagement: An installable wizard will be provided, allowing users to easily install the plugin to test the Windows implementation.

Milestone 2: Linux Backend Implementation

• Tasks: Design and implementation of Linux-specific backend for the FUSE API
• Estimated duration: 1.5 months
• Resources: Myself, with expertise in Linux development
• Dependencies: None
• User Engagement: The plugin will be made available in Archlinux package repositories, providing a straightforward installation process for users. Other distributions (Fedora, Ubuntu, etc.) will be supported in the future.

Milestone 3: macOS Backend Implementation

• Tasks: Design and implementation of macOS-specific backend for the FUSE API
• Estimated duration: 1.5 months
• Resources: Myself, with expertise in macOS development
• Dependencies: Availability of alternative filesystem implementation for macOS (due to Apple's deprecation of kernel drivers)
• User Engagement: An app package, potentially with an installer wizard, will be provided to simplify the installation process for users.

Milestone 4: FUSE API Development

• Tasks: Design and implementation of the cross-platform FUSE API
• Estimated duration: 1 month
• Resources: Myself, with expertise in API design and development
• Dependencies: Completion of at least two backend implementations
• User Engagement: During the development phase, instructions will be shared in the GitHub repository for compiling and running the project on Archlinux. Note that this is a high-risk phase, and users should be aware that things may break.

Milestone 5: Proof of Concept and Documentation

• Tasks: Implementation of a working proof of concept that demonstrates the FUSE API's functionality on at least two platforms without code changes, along with comprehensive documentation of the API and its usage
• Estimated duration: 1.5 months
• Resources: Myself, with expertise in API testing and documentation
• Dependencies: None
• User Engagement: While there will be no user engagement during the development phase of this milestone, the completed repository will contain scripts and instructions for compiling the entire project on each supported platform.

Assuming all milestones can be completed as planned, the total project duration is estimated to be approximately 7 months.

Total Budget Requested

I request funding on a month-by-month basis for the duration of the project, which is currently estimated to be approximately 7 months. Each month, an automatic transfer of €20,000 will be required to ensure the project's continued progress. The total amount of money requested for the entire 7-month period is €140,000.

To ensure the project's success, I propose that we schedule a monthly call to monitor progress, discuss any challenges or risks, and make adjustments to the project plan as needed. If there is a risk of the project taking longer than estimated, we can decide together whether it makes sense to continue with the project and allocate additional funding.

Milestone #	Description	Deliverables	Completion Date	Funding
1	Proof of Concept and Documentation	Working proof of concept and comprehensive documentation	-	-
2	FUSE API Development	Cross-platform FUSE API	-	-
3	Linux Backend Implementation	Functional Linux backend for FUSE API	-	-
4	Windows Backend Implementation	Functional Windows backend for FUSE API	-	-
5	macOS Backend Implementation	Functional macOS backend for FUSE API	-	-

The milestones are in the most likely order of development. In reality though the API (milestone 2) along with the proof of concept (milestone 1) and and running it on one of the platforms (say milestone 3) will be very intertwined. It's when this development is complete that the development of a subsequent platform (ex. 4 or 5) is more scoped down.

Maintenance and Upgrade Plans

To ensure the long-term sustainability of the FUSE API, I plan to leverage the open-source nature of the project to encourage community involvement and contributions.

• Community-driven maintenance: I hope that developers who implement the API will take an active role in reporting bugs, submitting patches, and contributing to the project's maintenance.
• Personal investment: As the project's creator, I will continue to be personally invested in the project's success and will contribute to bug fixes and releases to the best of my abilities.
• Commercial support: For organizations that require priority support or custom development, I will be available for hire to work on fixes and features.
• Community building: I aim to attract a small community of developers who can contribute to the project's maintenance and future development. By hosting the project on GitHub, I hope to foster a collaborative environment that encourages contributions and feedback.

By relying on a combination of community-driven maintenance, personal investment, and commercial support, I believe that the FUSE API can continue to evolve and improve over time, even after the initial development phase is complete.

Team

Team Members

• Mark Gaiser

Team Member LinkedIn Profiles

• https://www.linkedin.com/in/markgaiser/

Team Website

Crazyfuse.net. Right now it has the design document for this project. Once this project starts the site will change into a blog style where all design choices will be documented.

Relevant Experience

I have experience working on projects that aim to make decentralized technologies more accessible to the average user. In the past, I have worked on integrating IPFS protocols into existing tools, such as ffmpeg and curl. I am confident that I can bring this project to a successful end.

Team code repositories

• https://github.com/markg85/ (general code braindumps)
• https://github.com/crazyfuse (This project will be called Crazyfuse and will live in these repositories)

Additional Information

Please contact me at markg85@gmail.com for discussing the grant agreement and general next steps.

Although the project will be developed under the terms of the MIT/Apache-2 dual-license, I personally prefer to release my work under the MIT-0 license.

Throughout the development of this project, I intend to attend all relevant Filecoin and IPFS conferences to share the project's progress and engage with the community. I would greatly appreciate sponsorship for attending these events, covering travel costs, accommodation, and event registration fees. Please note that the time spent attending these events will not be included in the project's milestones and duration.

By supporting this project, you will not only be contributing to the development of a vital piece of infrastructure but also enabling me to share this work with the broader community, fostering collaboration and growth in the ecosystem.

[markg85]

I updated the following sections:

• Adoption, Reach, and Growth Strategies (specifically the onboarding part is new). I'm in the process of collecting feedback from relevant parties (besides IPFS/Filecoin) to quote them in the same section. I'll update that section once i have collected their feedback.
• Development Roadmap specifically the User Engagement bullet in each of the milestones is new.

In terms of budget/time (given that this is quite a bit higher then the 50k max). This is a huge project where 7 months is the bare minimum. It cannot be easily split up in smaller scoped grants because of inter-dependencies. The API development is dependent on at least windows and linux. Mac is a bit of a weird one here because it has just (in sequoia) introduced a new API for writing user space filesystems but it's not fully documented yet. My focus will be on Windows+Linux initially regardless, mac will be done last anyhow.

[markg85]

A couple updates:

• Added @autonome as technical sponsor.
• Hopefully clarified the milestones a little to be in the most likely order of development (and described that too). The order is fluid though and should be seen as a list of items to build for this grant in no particular order.
• Referenced crazyfuse.net as that's where this project is going to live (and on github, the site is just a more pretty visualization of the same data).

[autonome]

Some questions maybe worth integrating into the proposal, to better understand the impact and how this would fit into the various roles and data flows in the IPFS and Filecoin ecosystems.

• Would be good to understand how/where this helps w/ data onboarding, if at all. Eg (handwaving wildly) can these be used for temporary mounts for per-deal transfers or some other approach to address known pain points in the ecosystem?
• Could this help SPs managing data across sectors/deals/etc somehow? (more handwaving) eg virtual/programmable mounts like deal-size mounts or region-locked mounts?
• How does this align w/ the current approach to retrieval, which seems to be moving towards extra-chain networks, custom http gateways, etc
• Maybe interesting to explore CAR+fs interactions here? Or followup work if the core FUSE bits need to be in place first

[ErinOCon]

Hi @markg85, thank you for your proposal and for your patience with our review. Unfortunately, we will not be moving forward with supporting your project at this time.

In case you have an interest, I have sent you a message to discuss other ways to potentially partner with the Filecoin community. To contact our team with inquiries regarding our review or grants program, please send an email to grants@fil.org.