├── .github ├── ISSUE_TEMPLATE │ ├── ---security-concerns-.md │ ├── -meta--grant-platform-improvement.md │ ├── bounty-claim.md │ ├── config.yml │ ├── microgrant.md │ ├── open-grant.md │ ├── rfp-proposal.md │ └── tracking-issue.md └── workflows │ ├── generated-pr.yml │ └── stale.yml ├── BOUNTIES.md ├── FUNDING.md ├── MICROGRANTS.md ├── README.md ├── TERMS.md ├── microgrants └── accepted-microgrant-applications.md ├── open-grants ├── README.md ├── [Draft OPEN GRANT] Fierro IPNS Pinning Service.md ├── archived │ └── crystalizer.md ├── completed │ └── ENS.md ├── ipfs-rust │ ├── phase-1 │ │ ├── README.md │ │ ├── media │ │ │ ├── fig1-ipfs-rust-risk-assessment.png │ │ │ ├── fig2-ipfs-rust-implementation-schedule.png │ │ │ ├── phase-1-0-gantt.png │ │ │ ├── phase-1-1-gantt.png │ │ │ └── phase-1-2-gantt.png │ │ └── reports │ │ │ ├── phase-1.0.md │ │ │ ├── phase-1.1.md │ │ │ └── phase-1.2.md │ └── phase-2 │ │ ├── README.md │ │ └── reports │ │ └── phase-2.md ├── open-proposal-4EVERLAND.md ├── open-proposal-agregore-mobile.md ├── open-proposal-agregore-web-demos.md ├── open-proposal-decompose-ml-tasks.md ├── open-proposal-defi-for-sustainable-supply-chains-2.md ├── open-proposal-defi-for-sustainable-supply-chains.md ├── open-proposal-defluencer.md ├── open-proposal-distributed-pinning-protocol.md ├── open-proposal-embedded-ipfs.md ├── open-proposal-emergent-reputation.md ├── open-proposal-ipld-prolly-trees.md ├── open-proposal-memex+ipfs+filecoin+textile.md ├── open-proposal-nft-game-machine.md ├── open-proposal-nix-ipfs.md ├── open-proposal-open-registry.md └── rn-remote-ipfs.md ├── rfps ├── README.md ├── handshake-fallback-resolver.md └── rfp-template.md └── targeted-grants ├── IPFS-Browser-Protocol-Compliance-Suite.md ├── IPFS-mobile-design-guidelines.md ├── IPFS-mobile-design-research.md ├── active-local-discovery-in-brave.md ├── dnslink-multiplatform-update.md ├── omnilingo-IPFS.md ├── open-street-map-ipfs.md └── protocol-handler-api-for-browser-extensions.md /.github/ISSUE_TEMPLATE/---security-concerns-.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "⚠️ Security Concerns?" 3 | about: DO NOT USE THIS REPO! Any sensitive concerns should be emailed to security@ipfs.io 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | 11 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/-meta--grant-platform-improvement.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "[META] Grant Platform Improvement" 3 | about: Suggest a change or improvement to the Grant Platform 4 | title: '' 5 | labels: topic/meta 6 | assignees: parkan 7 | 8 | --- 9 | 10 | 11 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/bounty-claim.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bounty Claim 3 | about: Claim a bounty for completed work 4 | title: 'Bounty Claim: ' 5 | labels: type:bounty-claim 6 | assignees: parkan 7 | 8 | --- 9 | 10 | ### What Bounty is this claiming? 11 | 12 | 13 | ### What PR contains the solution? 14 | 15 | 16 | 17 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/config.yml: -------------------------------------------------------------------------------- 1 | blank_issues_enabled: false 2 | contact_links: 3 | - name: Unsure what to choose? 4 | url: https://github.com/ipfs/devgrants/blob/master/README.md 5 | about: Read more about grant templates here 6 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/microgrant.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Next Step Microgrant Application 3 | about: Submit this issue to apply for a Next Step Microgrant 4 | title: 'Next Step Microgrant: ' 5 | labels: type:microgrant 6 | assignees: erinocon 7 | --- 8 | 9 | ### 1. What is your project? (max 100 words) 10 | 11 | 12 | 13 | 14 | 15 | ### 2. How will IPFS, Filecoin, or related technology be used for this project? (max 100 words) 16 | 17 | ### 3. How will you improve your project with this grant? What steps will you take to meet this objective? (max 200 words) 18 | 19 | 20 | ### 4. Is this project open source? 21 | 22 | 23 | ### 5. Do you agree to share grant reports upon request, including a final grant report at the end of the three month period? 24 | 25 | 26 | ### 6. Does your proposal comply with our Community Code of Conduct? 27 | 28 | 29 | ### 7. Links and submissions 30 | * If your project began at a hackathon, have you submitted it for the relevant Protocol Labs prizes? Include links here if available: 31 | 32 | ### Additional questions: 33 | * For each team member(s), please list name, email, Github account, and role in the project. 34 | * How did you learn about our microgrant program? 35 | * If your project was created as part of an event or hackathon: 36 | * What was the name of the event? (e.g. ETHGlobal NFTHack, Cal Hacks hello:world, Chainlink, CivHacks, GameDevJ, ETHGlobal Scaling Ethereum) 37 | * Please link to your hackathon submission 38 | 39 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/open-grant.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Open Grant Application 3 | about: Submit an open grant application 4 | title: '' 5 | labels: Open Grant 6 | assignees: realChainLife 7 | 8 | --- 9 | 10 | # Open Grant Proposal: `Project Title` 11 | 12 | **Name of Project:** 13 | 14 | **Proposal Category:** Choose one of `core-dev`, `app-dev`, `devtools-libraries`, `integration-adoption` , `technical-design`, `docs` , `community` , `metaverse` , `research` , `green` Learn what these categories are here: {https://github.com/filecoin-project/devgrants/tree/master/open-grants}" 15 | 16 | **Proposer:** `replace with your GitHub username` 17 | 18 | **(Optional) Technical Sponsor:** `If you have previously discussed this project with a member of the IPFS or Filecoin project teams and they have agreed to be a technical sponsor, include their name and/or github handle here` 19 | 20 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT, APACHE2, or GPL licenses?:** Please respond with either "Yes" or "No" 21 | 22 | # Project Description 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | ## Value 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | ## Deliverables 40 | 41 | 42 | 43 | ## Development Roadmap 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | ## Total Budget Requested 54 | 55 | 56 | 57 | ## Maintenance and Upgrade Plans 58 | 59 | 60 | 61 | # Team 62 | 63 | ## Team Members 64 | 65 | 66 | 67 | 68 | 73 | 74 | 75 | 80 | 81 | ## Relevant Experience 82 | 83 | 84 | 85 | ## Team code repositories 86 | 87 | 88 | 89 | # Additional Information 90 | 91 | 92 | 93 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/rfp-proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: RFP Proposal 3 | about: A proposal fulfilling an RFP ⚠️ on hold until Q1 2021 ⚠️ 4 | title: 'RFP Proposal: ' 5 | labels: type:RFP 6 | assignees: '' 7 | 8 | --- 9 | 10 | ## What RFP is this fulfilling? 11 | 12 | 13 | ## Project Description (~500 words) 14 | 15 | 16 | 17 | ## Deliverables 18 | 19 | 20 | 21 | ## Development Roadmap 22 | 23 | 28 | 29 | ## Total Budget Requested 30 | 31 | 32 | ## Team Details 33 | 34 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/tracking-issue.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Tracking Issue 3 | about: Tracking issue for a grant proposal in review (maintainers only, please) 4 | title: "[TRACKING] " 5 | labels: tracking issue 6 | assignees: parkan 7 | 8 | --- 9 | 10 | 11 | 12 | Tracking for 13 | -------------------------------------------------------------------------------- /.github/workflows/generated-pr.yml: -------------------------------------------------------------------------------- 1 | name: Close Generated PRs 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 * * *' 6 | workflow_dispatch: 7 | 8 | permissions: 9 | issues: write 10 | pull-requests: write 11 | 12 | jobs: 13 | stale: 14 | uses: ipdxco/unified-github-workflows/.github/workflows/reusable-generated-pr.yml@v1 15 | -------------------------------------------------------------------------------- /.github/workflows/stale.yml: -------------------------------------------------------------------------------- 1 | name: Close Stale Issues 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 * * *' 6 | workflow_dispatch: 7 | 8 | permissions: 9 | issues: write 10 | pull-requests: write 11 | 12 | jobs: 13 | stale: 14 | uses: ipdxco/unified-github-workflows/.github/workflows/reusable-stale-issue.yml@v1 15 | -------------------------------------------------------------------------------- /BOUNTIES.md: -------------------------------------------------------------------------------- 1 | # Welcome to IPFS Bounties! 2 | 3 | ## Definition 4 | Bounties are simply _incentives for closing (fixing) issues_. Issues with bounties attached to them are listed on the [Bounties project board](../../projects/1). When the original issue is closed by a PR, the author of that PR is considered eligible for the bounty. Bounty rewards typically range from **$50** to **$1000**. 5 | 6 | Bounties are a good fit for simpler tasks like fixing minor bugs, adding test cases, updating or translating documentation, or building small, well-specified features. Projects with good test coverage and automated CI make it much easier for bounty hunters to do their job. 7 | 8 | If your task is larger in scope, ambiguous in specification, or requires a lot of rebasing, it may be better to specify it as an [RFP](rfps). 9 | 10 | Issues tagged ["help wanted"](https://github.com/ipfs/docs/labels/help%20wanted) often make good bounty subjects. 11 | 12 | 13 | ## How to Propose 14 | To propose a bounty simply tag your issue in the "Open Bounties" column on the [Bounties project board](../../projects/1) with the award amount. It's also a good idea to add a comment to the issue linking back to this document so your contributors can learn how to claim the bounty. It is the responsibility of the bounty issuer to disburse the award. 15 | 16 | *NOTE: due to the way GitHub project board permissions work, only authorized contributors are currently able to add bounties to the board. Please email ipfs-grants@protocol.ai to be added. A submission form will replace this mechanism once the platform is fully launched* 17 | 18 | ## How to Collect 19 | * Find an issue that fits your skills and interests on the [Bounty Board](https://github.com/protocol/ipfs-grants/projects/1) and fix it! 20 | * Open a Pull Request with your work (don't forget to include ["fixes #..."](https://help.github.com/en/github/managing-your-work-on-github/closing-issues-using-keywords) in your PR so it automatically closes the issue). Once the PR is approved and merged, simply open a [Bounty Claim](https://github.com/protocol/ipfs-grants/issues/new?assignees=&labels=&template=bounty-claim.md&title=Bounty+Claim%3A+%3CWhat+You+Fixed%3E) issue in this repo to collect your reward! 21 | 22 | ## Support and Payments 23 | Bounties are paid out by the originating party. 24 | 25 | ## Note 26 | Bounties are just one aspect of the IPFS project's overall grant program. Check out the top level of the [IPFS Grant Platform repo](https://github.com/ipfs/devgrants) to see the big picture. 27 | -------------------------------------------------------------------------------- /FUNDING.md: -------------------------------------------------------------------------------- 1 | # Funding Organizations 2 | 3 | ## About 4 | This page lists the major funding organizations backing [RFPs](rfps) and [Open Grants](open-grants). Being listed here is not required to fund grants, but having invoicing and any policy information readily available can help applicants navigate the grant writing process more smoothly. 5 | 6 | If your organization intends to back multiple grants in the IPFS ecosystem, please PR this file with appropriate info. 7 | 8 | ## List of Funding Orgs 9 | 10 | ### Protocol Labs 11 | 12 | **Description:** [Protocol Labs](https://protocol.ai) is a research, development, and deployment institution for improving Internet technology. Stewards of IPFS, Filecoin, IPLD, and more. 13 | 14 | **Invoicing:** after your grant is approved, email ipfs-grants@protocol.ai with a link to the issue and [INVOICE] in the subject. 15 | 16 | **Payments:** wire transfer or cryptocurrency payments are possible, please include your place of residence/registration and any preference with your invoice. 17 | 18 | --- 19 | 20 | **[Add Your Foundation Here!](https://github.com/protocol/ipfs-grants/edit/master/FUNDING.md)** 21 | -------------------------------------------------------------------------------- /MICROGRANTS.md: -------------------------------------------------------------------------------- 1 | ## Thank you for your interest in our grants program! We are currently reviewing a high volume of proposals. Please wait 30 days before checking in on the status of your grant request. 2 | 3 | # Filecoin Grants 4 | 5 | 6 | Welcome to the Filecoin Grant Platform! The Filecoin Grant Platform connects grant makers with builders and researchers in the Filecoin community. Whether you represent a foundation that wants to move the space forward, a company looking to accelerate development on the features your application needs, or a dev team itching to hack on Filecoin tools, you've come to the right place. Take a look at the supported grant types and available opportunities below. 7 | 8 | ## Grant Types 9 | 10 | --- 11 | 12 | ### Next Step Microgrants 13 | 14 | Grants of $5,000 in FIL are available to support those taking the _next step_ after creating an initial prototype with Filecoin, IPFS, or related technologies. 15 | 16 | Since January 27, 2023, microgrants are exclusively awarded for projects within rotating [Microgrant focus areas](https://github.com/filecoin-project/devgrants/blob/master/microgrants/microgrants.md#focus-areas). Applications for the most recent focus area, [Filecoin Virtual Machine](https://fvm.filecoin.io/), are currently being processed. 17 | 18 | If you have (1) a working prototype that matches the current focus area and (2) concrete _next steps_ for your project, consider applying for a microgrant! 19 | 20 | This program is intended for early stage projects. If your project has already received more than $30,000 USD from any source, please apply for an open grant (details below) rather than a microgrant. 21 | 22 | [**LEARN MORE AND APPLY FOR A MICROGRANT**](https://github.com/filecoin-project/devgrants/blob/master/microgrants/microgrants.md) • [**See Accepted Microgrant Proposals**](https://github.com/filecoin-project/devgrants/blob/master/microgrants/accepted-microgrant-applications.md) 23 | 24 | --- 25 | 26 | ### Open Grant 27 | Do you have an idea for pushing the Filecoin ecosystem forward? Grants of $10,000+ are available to support novel ideas that advance the Filecoin ecosystem, bring significant new usage, or directly advance the Filecoin mission statement. 28 | 29 | 30 | [**LEARN MORE ABOUT OPEN GRANTS**](https://github.com/filecoin-project/devgrants/tree/master/open-grants) **AND** [**APPLY FOR AN OPEN GRANT**](https://github.com/filecoin-project/devgrants/issues/new?assignees=&labels=&template=open-grant-application.md&title=) 31 | 32 | 33 | --- 34 | 35 | ### Requests for Proposals (RFPs) 36 | RFPs are grants for specific development work. As the name suggests, we are requesting proposals from teams that want to complete the work specified in each RFP. In these grants, we generally have clearly scoped deliverables, milestones, and funding limits. Some RFPs will ask you to propose your own milestones and funding needs. While there is some flexibility in RFP deliverables, we expect teams will deliver what is in scope in the RFP. Any deviations from the specified scope must be approved between your team and ours before we can approve funding. RFPs may be funded by Protocol Labs, other community members, or a consortium of interested parties. 37 | 38 | OPEN RFPs: 39 | 40 | * [Filecoin-solidity Phase II: Optimization, improvements and maintenance](https://github.com/filecoin-project/devgrants/blob/master/rfps/Filecoin-solidity-Optimization.md) RFP **New! 2023-05-05 ** 41 | 42 | * [**FVM Project Ideas**](https://github.com/filecoin-project/devgrants/blob/master/rfps/fvm-rfp-ideas.md) 43 | 44 | CLOSED RFPs: 45 | 46 | * [**FVM Tooling & Infrastructure**](https://github.com/filecoin-project/devgrants/blob/master/rfps/fvm-open-tools-infra.md) **This RFP is currently closed.** 47 | * [**Green Grants**](https://github.com/filecoin-project/devgrants/blob/master/rfps/green-grants.md) RFP - **The RFP is currently closed.** 48 | 49 | 50 | 51 | --- 52 | 53 | ### Don't see your grant type? 54 | Is your organization interested in offering a grant that doesn't fit into any of the above categories? [Email us directly](mailto:grants@filecoin.org) with your idea. 55 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## IPFS Devgrants 2 | 3 | Developer grants for IPFS are currently on hold during the development of [the new governance structure][governance-post] for the protocol. We look forward to your ideas and projects to make IPFS ever better when we re-open in 2024! 4 | 5 | For now, share your ideas on the [IPFS forum][ipfs-discourse], [Discord][ipfs-discord] or [Matrix][ipfs-matrix]. 6 | 7 | IPFS developer grants currently funded by the [Filecoin Grant Platform][ff-grants] will continue until completed, but no new proposals will be accepted. New proposals that do not have a Filecoin component will be evaluated by the respective IPFS and libp2p foundations once they are launched. 8 | 9 | [governance-post]: https://protocol.ai/blog/advancing-ipfs-and-libp2p-governance/ 10 | [ipfs-discourse]: https://discuss.ipfs.tech/ 11 | [ipfs-discord]: https://discord.gg/vZTcrFePpt 12 | [ipfs-matrix]: https://matrix.to/#/#ipfs-space:ipfs.io 13 | [ff-grants]: https://github.com/filecoin-project/devgrants/ 14 | -------------------------------------------------------------------------------- /TERMS.md: -------------------------------------------------------------------------------- 1 | ## Code of Conduct 2 | 3 | https://github.com/ipfs/community/blob/master/code-of-conduct.md 4 | 5 | ## Legal 6 | 7 | TK 8 | -------------------------------------------------------------------------------- /microgrants/accepted-microgrant-applications.md: -------------------------------------------------------------------------------- 1 | # Accepted Next Step Microgrant Applications 2 | 3 | This page provides an overview of accepted applications and a link to their GitHub repositories. 4 | 5 | ## Table of Contents 6 | 7 | - [2020](#2020) 8 | - [:surfing_woman: First Half 2020](#surfing_woman---first-half-2020) 9 | - [2021](#2021) 10 | - [:surfing_woman: First Half 2021](#surfing_woman---first-half-2021) 11 | - [:surfing_woman: Second Half 2021](#surfing_woman---second-half-2021) 12 | 13 | --- 14 | 15 | # 2020 16 | 17 | ## :surfing_woman: First Half 2020 18 | 19 | | Team | Project | Link | Application Issue Link | 20 | | :--- | :------ | :--- | :--------: | 21 | | [NYC Mesh](https://www.nycmesh.net/) | Mesh Services on NYC Mesh Network | [GitHub](https://github.com/tomeshnet/toronto-community-network/issues/53) | [#11](https://github.com/ipfs/devgrants/issues/11) | 22 | | [Almonit](https://almonit.club/#/) | Almonit: tool for decentralized websites based on ENS and IPFS | [Website](https://almonit.club) | [#31](https://github.com/ipfs/devgrants/issues/31) | 23 | 24 | # 2021 25 | 26 | ## :surfing_woman: First Half 2021 27 | 28 | | Team | Project | Link | Application Issue Link | 29 | | :--- | :------ | :--- | :--------: | 30 | | Endowl | GenFT Studio | [Github](https://github.com/ipfs/community/blob/master/projects/genft.md)| [#76](https://github.com/ipfs/devgrants/issues/76) | 31 | 32 | # 2021 33 | 34 | ## :surfing_woman: Second Half 2021 35 | 36 | | Team | Project | Link | Application Issue Link | 37 | | :--- | :------ | :--- | :--------: | 38 | | @Adithya-adi-Menon | Evido | [Github](https://github.com/Adithya-adi-Menon/ipfs-evido)| [#81](https://github.com/ipfs/devgrants/issues/81) | 39 | | @anudit | Convo | [Website](https://theconvo.space/)| [#82](https://github.com/ipfs/devgrants/issues/82) | 40 | | @ysongh | Codework NFT | [Github](https://github.com/ysongh/Codework-NFT)| [#83](https://github.com/ipfs/devgrants/issues/83) | 41 | | @optimus789 | Decentralized Broadcast & Stream for Audius | [Github](https://github.com/Rishikeshk9/DBS-Decentralized-Broadcaster-Streamer)| [#84](https://github.com/ipfs/devgrants/issues/84) | 42 | | @felixniemeyer | a-jam: collaborative multitrack recorder for musicians | [Github](https://github.com/felixniemeyer/a-jam)| [#85](https://github.com/ipfs/devgrants/issues/85) | 43 | | @feliciss | InterPlanetary File System for Business (IPFSfB) | [Github](https://github.com/feliciss/IPFSfB)| [#86](https://github.com/ipfs/devgrants/issues/86) | 44 | | @hackyguru et al | PassVault | [Github](https://github.com/hackyguru/PassVault) | [#87](https://github.com/ipfs/devgrants/issues/87) | 45 | | @cryptobuffer| 4EVERLAND | [Github](https://github.com/4everland) | [#89](https://github.com/ipfs/devgrants/issues/89) | 46 | | @eyalron33 | Esteroids | [Github](https://github.com/ipfs/community/blob/master/projects/Esteroids.md) | [#92](https://github.com/ipfs/devgrants/issues/92) | 47 | | @junoware | CryptoSouls | [Github](https://github.com/junoware/cryptosouls) | [#94](https://github.com/ipfs/devgrants/issues/94) | 48 | | @bkyogesh28 | HubShare | [Github](https://github.com/bkyogesh28/HubShare) | [#95](https://github.com/ipfs/devgrants/issues/95) | 49 | | @andskur | Juni::Db | [Github](https://github.com/uddugteam/juniDB) | [#96](https://github.com/ipfs/devgrants/issues/96) | 50 | | @keyvan-m-sadeghi | File Protocol implementation for box server | [Github](https://github.com/functionland/box) | [#97](https://github.com/ipfs/devgrants/issues/97) | 51 | | @threalharpaljadeja | NiftySubs | [Github](https://github.com/NiftySubs/niftysubs) | [#98](https://github.com/ipfs/devgrants/issues/) | 52 | | @i-m-aditya | Deagle | [Github](https://github.com/i-m-aditya/Deagle) | [#103](https://github.com/ipfs/devgrants/issues/103) | 53 | | @jordaniza | Rhada | [Github](https://github.com/RhadaPay) | [#106](https://github.com/ipfs/devgrants/issues/106) | 54 | | @tjayrush | TrueBlocks | [Github](https://github.com/TrueBlocks/trueblocks-core) | [#109](https://github.com/ipfs/devgrants/issues/109) | 55 | | @iamsdas | Dodging Turtis | [Github](https://github.com/Hardikag17/Dodging-Turtis) | [#113](https://github.com/ipfs/devgrants/issues/113) | 56 | | @jacekv | Git3 | [Github](https://github.com/Paper-House/PaperHouse) | [#114](https://github.com/ipfs/devgrants/issues/114) | 57 | | @poojitha611 | Socio Dapp | [Github](https://github.com/MohinishTeja/celo_project) | [#115](https://github.com/ipfs/devgrants/issues/115) | 58 | | @msanket9 | PaperHouse | [Github](https://github.com/varkiwi/git3-frontend) | [#117](https://github.com/ipfs/devgrants/issues/117) | 59 | | @electrone901 | Community Garden | [Github](https://github.com/electrone901/plant-doctor) | [#118](https://github.com/ipfs/devgrants/issues/118) | 60 | | @hackyguru | Flutter IPFS Plugin | [Github](https://github.com/hackyguru/IPFS-Flutter) | [#121](https://github.com/ipfs/devgrants/issues/121) | 61 | | @Mr-Cryptocoder | Covision| [Github](https://github.com/Mr-Cryptocoder) | [#119](https://github.com/ipfs/devgrants/issues/119) | 62 | | @hackyguru | Flutter IPFS Plugin| [Github](https://github.com/hackyguru/IPFS-Flutter) | [#121](https://github.com/ipfs/devgrants/issues/121) | 63 | | @SomajitDey | IPNS-Link | [Github](https://github.com/ipns-link) | [#122](https://github.com/ipfs/devgrants/issues/122) | 64 | | @mrodriguez3313 | IPNSGoServer | [Github](https://github.com/mrodriguez3313/IPNSGoServer) | [#123](https://github.com/ipfs/devgrants/issues/123) | 65 | 66 | # 2022 67 | 68 | ## :surfing_woman: First Half 2022 69 | | Team | Project | Link | Application Issue Link | 70 | | :--- | :------ | :--- | :--------: | 71 | | @shivani7q | ETH My Song | [Github](https://github.com/shivani7q/ETH_my_Song) | [#126](https://github.com/ipfs/devgrants/issues/126) | 72 | | @eerkaijun | Blockchain Ticketing | [Github](https://github.com/eerkaijun/tixlab) | [#127](https://github.com/ipfs/devgrants/issues/127) | 73 | | @robin-thomas | Phi | [Github](https://github.com/robin-thomas/phi) | [#128](https://github.com/ipfs/devgrants/issues/128) | 74 | | @melwong | Lifefram | [Github](https://github.com/lifefram/lf/) | [#133](https://github.com/ipfs/devgrants/issues/133) | 75 | | @CreativerseMC | Creativerse - Minecraft on Ethereum | [Github](https://github.com/CreativerseMC/CreativerseMC-Plugin) | [#134](https://github.com/ipfs/devgrants/issues/134) | 76 | | @MOUNIKASIMHADRI17 | Slick | [Github](https://github.com/MohinishTeja/Slick) | [#135](https://github.com/ipfs/devgrants/issues/135) | 77 | | @Josiassejod1 | realityDapp | [Github](https://github.com/Josiassejod1/realityDapp) | [#136](https://github.com/ipfs/devgrants/issues/136) | 78 | | @Shachindra | NetSepio | [Github](https://github.com/NetSepio/ChromiumExtension) | [#137](https://github.com/ipfs/devgrants/issues/137) | 79 | | @RichuAK | Prānah | [Github](https://github.com/pranah/DBM-client) | [#141](https://github.com/ipfs/devgrants/issues/141) | 80 | | @estebanabaroa | plebbit | [Github](https://github.com/plebbit/plebbit-js#schema) | [#143](https://github.com/ipfs/devgrants/issues/143) | 81 | | @lmedury | Auction House | [Github](https://github.com/lmedury/auctionhouse) | [#145](https://github.com/ipfs/devgrants/issues/145) | 82 | | @noryev | Statistical Data Viewer on IPFS | [Github](https://github.com/galaxyxone/glsx_live2.2) | [#146](https://github.com/ipfs/devgrants/issues/146) | 83 | | @badkk | IPFS Scan | [Github](https://github.com/crustio/ipfsscan) | [#147](https://github.com/ipfs/devgrants/issues/147) | 84 | | @poolsar42 | Sytime | [Github](https://github.com/ThirdRockEngineering/Sytime) | [#148](https://github.com/ipfs/devgrants/issues/148) | 85 | | @codeyager | DExplorer | [Github](https://github.com/codeyager/Dexplorer) | [#151](https://github.com/ipfs/devgrants/issues/151) | 86 | | @Barabazs | py-is_ipfs| [Github](https://github.com/Barabazs/py-is_ipfs) | [#152](https://github.com/ipfs/devgrants/issues/152) | 87 | | @b-rad-c | dBranch News| [Github](https://github.com/b-rad-c/dbranch-desktop) | [#155](https://github.com/ipfs/devgrants/issues/155) | 88 | | @slonigiraf | SLON| [Github](https://github.com/slonigiraf/slon-ui) | [#156](https://github.com/ipfs/devgrants/issues/156) | 89 | | @yehia67 | NFT-House for NFTs renting| [Github](https://github.com/yehia67/nft-house) | [#158](https://github.com/ipfs/devgrants/issues/158) | 90 | | @Brilliant497705 | Sympodium| [Github](https://github.com/mendsalbert/sympodiumCoin) | [#161](https://github.com/ipfs/devgrants/issues/161) | 91 | | @TheWeb3DAO | TheWeb3Portal from Web3DAO| [Github](https://github.com/ipfs/devgrants/issues/163) | [#163](https://github.com/Web3-Portal/TheWeb3Portal) | 92 | | @Sergei-Udris | Cara-Dune| [Github](https://github.com/Sergei-Udris/Karga) | [#164](https://github.com/ipfs/devgrants/issues/164)| 93 | | @jgarciajovel | Vortex| [Github](https://github.com/jgarciajovel/vortex) | [#165](https://github.com/ipfs/devgrants/issues/165) | 94 | | @TheGodOfAwesome | Caste| [Github](https://github.com/TheGodOfAwesome/Caste) | [#166](https://github.com/ipfs/devgrants/issues/166) | 95 | | @rhdeck | Time Limited Tokens Specification and Web3BnB Reference Implementation | [Github](https://github.com/rhdeck/time-limited-tokens) | [#167](https://github.com/ipfs/devgrants/issues/167) | 96 | | @vasanthsteve23 | IPFS-DROP | [Github](https://github.com/vasanthsteve23/IPFS_DROP) | [#171](https://github.com/ipfs/devgrants/issues/171) | 97 | | @Zhixuan0318 | PFS Documentation for the Chinese Community| [Github]( https://github.com/Zhixuan0318/ipfs-docs-zh-CN) | [#172](https://github.com/ipfs/devgrants/issues/172) | 98 | -------------------------------------------------------------------------------- /open-grants/README.md: -------------------------------------------------------------------------------- 1 | # Open Grants 2 | 3 | ## About 4 | Open grants are for novel ideas that advance the IPFS ecosystem, bring significant new usage, or directly [advance the IPFS mission statemnent](https://github.com/ipfs/roadmap#ipfs-mission-statement). 5 | 6 | If your project is smaller in scope and less well-defined, you may want to consider [the microgrant program](../MICROGRANTS.md) instead. 7 | 8 | ## 📋 How to apply 9 | 10 | To submit an Open Grant proposal, [create a new issue](https://github.com/ipfs/devgrants/issues/new?assignees=realChainLife&labels=Open+Grant&template=open-grant.md&title=) using the Open Grants Proposal template. Please cover the project being proposed (including value to the IPFS ecosystem, deliverables, development, roadmap, and budget), and the team making the proposal (including your expertise and past work). 11 | 12 | Draft submissions are welcome and encouraged to gauge community interest and begin discussion, even if you are uncertain of the suitability of your proposal. 13 | 14 | Open Grant proposals are reviewed monthly. 15 | 16 | ## ⌛ After you apply 17 | 18 | After you submit your proposal, you can expect the following to occur: 19 | 20 | - We will review your application. During review, we will add comments, questions, change requests, et cetera on your team's submission. 21 | - After a few round trips of discussion, our team will make a decision on which proposals to fund and which not to. 22 | - During the discussion and review phase, we will contact your team for financial and legal follow-ups, such as to confirm milestones and funding, your team's legal structure, etc. 23 | - If your team is accepted, we will ask you to sign our Open Source Software Grant Agreement, which will include a copy of the work plan and funding milestones. 24 | - We aim to complete all review within a few weeks after the wave deadline, so please stay vigilant on GitHub. 25 | 26 | Please reach out #grants-questions on Filecoin Slack ([invite](http://filecoin.io/slack)) or email grants@filecoin.org with any questions. 27 | 28 | ## ℹ️ Help 29 | 30 | If you have any questions, please ask them! 31 | - File an issue in this repo 32 | - Join our [community chat](https://github.com/filecoin-project/community#chat) 33 | 34 | ## Note 35 | Open grants are just one aspect of the IPFS project's overall grant program. Check out the top level of the [IPFS Grant Platform repo](https://github.com/ipfs/devgrants) to see the big picture. 36 | -------------------------------------------------------------------------------- /open-grants/archived/crystalizer.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `Crystalizer` 2 | 3 | **Name of Project:** Crystalizer 4 | 5 | **Proposer:** `hhff` 6 | 7 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** 8 | 9 | Yes, although we'd like to offer a paid plan to help us support infrastructure costs and provide ongoing maintenance, ie - something like how Sentry works. Given this is a CI style tool, we'd likely offer "parallelization" as a payment option (ie, paying for a "dedicated build queue" rather than waiting for the public queue). 10 | 11 | # Project Description 12 | 13 | #### Problem: 14 | Deploying and hosting static files with IPFS is not "beginner friendly" (in our humble opinion!). Developers need to understand a bunch of terminology (like "pinning", etc), and why they (probably) need pay for a pinning service, or spin up their own IPFS node. In addition, managing IPNS or DNSLink along with a DNS provider is confusing for folks who are new to regular DNS in the first place. 15 | 16 | #### Solution: 17 | A CI style Github integrated pipeline that automates this complexity for the developer. This service would: 18 | - Allow the developer to connect their Github account/org(s), and select project(s) for auto-deploys to IPFS 19 | - Allow the developer to elect one or more git branches in a project as "pinned" (ie, integration, production, dev) 20 | - Whenever a "pinned" git branch is updated, static assets would be built from the codebase, deployed, and pinned to an IPFS hash 21 | - Allow the developer to debug build logs by surfacing them in a UI 22 | - List all known "IPFS hashes" mapped to previous deploys in the UI 23 | - Automatically manage IPNS/DNSLink on behalf of those pinned branches 24 | - Allow for immediate "rollback" to a previous IPFS hash via IPNS/DNSLink via the UI 25 | - Send a webhooks to another service on successful deploy 26 | 27 | ## Prior Art 28 | 29 | We originally built [https://www.crystalizer.io](https://www.crystalizer.io/) as a way to preview PRs before they are merged, but we were beaten to market by [https://featurepeek.com](https://featurepeek.com/), which is ultimately a better product. As such, we already have in place: 30 | - [ ] A fully integrated CI pipeline working against Github oAuth, written in Ruby on Rails 31 | - [ ] A buildstep & background job queue for building and deploying static assets against multiple frontend frameworks on the fly (in docker containers via Kubernetes) 32 | - [ ] A brand guideline, UI styles, and implemented component library for neat UI (screenshots below) 33 | 34 | Changes we'd need to make to repurpose as a zero config IPFS deploy tool: 35 | - [ ] Update all Design, Marketing & Documentation for IPFS concepts 36 | - [ ] Redesign & reimplement build and deployment against IPFS 37 | - [ ] Add IPNS/DNSLink management layer (for automatic + manual rollbacks) 38 | - [ ] Under-the-hood move to using `Now.sh`'s open source builders ([Apache 2.0](https://github.com/zeit/now/blob/master/LICENSE)) to support [all of the frameworks listed here](https://github.com/zeit/now/blob/master/packages/frameworks/frameworks.json) with zero config (currently we use our own logic here) 39 | 40 | ## Value 41 | 42 | In recent years, the JAM (Javascript, APIs, Markup) Stack has become a really popular way of thinking about web apps and deployments. Services like Netlify & Now.sh have popularized these methodologies by adding a bunch of utility around this style of building and hosting. The JAM Stack is taught readily at developer bootcamps, and as such, is something new developers usually lean in to. 43 | 44 | In addition, we've already written the core of the user facing app in Ruby on Rails, lowering the bar to external contributors to participate in improving the product. 45 | 46 | ### What are the benefits to getting this right? 47 | We lower the bar (friction, person time, etc) to using IPFS as a viable deploy target for a really big and diverse group of developers (juniors, and everyone) - thereby increasing IPFS adoption! In addition, we'd simplify the concept of "rollback" deploys to these same developers, as permanent, immutable IPFS deployments are ideal for such a concept. 48 | 49 | ### What are the risks if you don't get it right? 50 | The main risk is that Netlify & Now.sh add IPFS as a hosting target in response to seeing how we do that (given our code would be open source). This doesn't strike me as likely, but who knows...! 51 | 52 | However, in a lot of ways that would mean Crystalizer fulfills it's primary goal: increasing adoption of IPFS. 53 | 54 | ### What are the risks that will make executing on this project difficult? 55 | The main risk here is that when I last used IPNS, it was quite slow to resolve (upwards of 30 seconds). I understand that DNSLink is a faster way to achieve a similar thing. 56 | 57 | In a worst case scenario, we could run an nginx proxy or Cloudfront Lambda function to improve usability by handling DNS routing to specific IPFS hashes on the fly. 58 | 59 | A secondary risk is user acquisition - we are not experts in product promotion. The success of this software is dependent on people actually using it! More volume means more paying customers, and more paying customers means we can afford to dedicate time to maintenance. 60 | 61 | ## Deliverables / Milestones 62 | 63 | #### Redesign & Implement Marketing Page 64 | - 3pts Rewrite content narrative 65 | - 3pts Repurpose existing graphics 66 | - 3pts Design new graphics and animations 67 | 68 | ~ 1 week of 1 designer's time 69 | 70 | Deliverable: New designs for the Marketing homepage 71 | 72 | #### Redesign & Implement UI for IPFS (& IPNS/DNSLink) concepts 73 | - 5pts Redesign UI for for IPFS concepts 74 | - 3pts Update ORM Schema to support IPFS hashes and such 75 | - 5pts Update Projects#Index with IPFS details 76 | - 5pts Update Projects#Build with IPFS details 77 | 78 | ~ 2 days of 1 designer's time 79 | ~ 1.5 weeks of a frontend developers time 80 | 81 | Deliverable: New designs & a working UI repurposed to work with IPFS hosting concepts 82 | 83 | #### Implement Integration Hooks 84 | - 3pts Implement Slack Integration 85 | - 5pts Implement Sending External Webhook on Deploy Completion 86 | 87 | ~ 1 week of a backend developer's time 88 | 89 | Deliverable: The ability to connect a Slack channel to notify users of new deployments, and the ability to post webhooks on this same event, for the sake of breaking caches and triggering other such services. 90 | 91 | #### Move to Now.sh Build Step, IPFS Deployment & DNS Management 92 | - 13pts Update Tooling & Build step to use Now.sh CLI 93 | - 13pts Update Tooling & Deploy step to push to IPFS 94 | - 8pts Handle Rollbacks and DNS Management (IPNS/DNSLink) 95 | 96 | ~ 3 weeks of a backend developer's time 97 | 98 | Deliverable: The core technology. A zero-config, framework agnostic buildstep that deploys static assets to a unique IPFS hash, and optionally manages DNS routing, etc. 99 | 100 | #### Test, QA and Launch 101 | - 30% of total points 102 | 103 | ~ team effort, hopefully including the grant committee! 104 | 105 | Deliverable: A ready-to-launch web application for users to connect their Github account, and start shipping static assets to IPFS! 106 | 107 | ## Total Budget Requested 108 | 109 | If you'd like to read more about how we quote technology, we've detailed it [here](https://medium.com/sanctuary-computer-inc/how-we-quote-technology-2b0f8e9b627f). 110 | 111 | **Please Note:** The numbers here are indicative of "cost" to employ developers here in NYC (with health insurance, payroll taxes, etc). These numbers do not have a profit margin built in: we are fans of the IPFS ecosystem, and would love to be able to afford the time to build something great on top of it! 112 | 113 | #### Estimated Cost 114 | 69 points * 1.3 (QA & Testing) / 13.5 (our burndown) = 6.6 person weeks 115 | 116 | 6.6 person weeks * $2800 (average cost to employ a person in NYC per week) 117 | = `$18,480` 118 | 119 | #### Estimated Timeline 120 | I plan to work on this (personally) roughly 2.5 days per week. Given the major timeline here is development (design timeline is short and can happen parallel). 121 | 122 | As such, we'd expect a launchable application to be ready roughly 12 weeks from grant approval. 123 | 124 | ## Maintenance and Upgrade Plans 125 | 126 | We'll be using it internally (instant rollbacks and cheap hosting is huge) so we'll ensure it's always in working order as a necessity. 127 | 128 | However, we would like to grow this product into a profitable offering for hosting static assets. We'd love to eventually offer some additional services like free SSL via LetsEncrypt, on the fly serverside rendering, and perhaps some CDN integrations. In order to be able to do this work, we'd first need a profit generating product so that we can afford to commit development time to it. 129 | 130 | # Team 131 | 132 | ## Team Members 133 | 134 | #### Developers: 135 | - [Hugh Francis](https://github.com/hhff) 136 | - [Joshie Fishbein](https://github.com/joshiefishbein) 137 | - [Christine Kim](https://github.com/chrismekim) 138 | - [Alicia Willett](https://github.com/aliciakw) 139 | - [Harrison Wideman](https://github.com/hwideman) 140 | - [Sebastian Odell](https://github.com/sepowitz) 141 | - [Ellis Marte](https://github.com/ellismarte) 142 | - [Sohee Lim](https://github.com/limsohee1002) 143 | - [Kay Mok](https://github.com/mokaymokay) 144 | - [Conor Davidson](https://github.com/conordavidson) 145 | 146 | #### Designers: 147 | - [Brendon Avalos](https://www.brendonavalos.com/) 148 | - [Devin Halladay](https://devinhalladay.com/) 149 | - [Darin Buzon](https://www.darinbuzon.info/) 150 | 151 | #### Strategy & Operations: 152 | - [Isabel Munter](https://www.linkedin.com/in/isabelmunter/) 153 | - [Tim Casasola](http://www.timcasasola.com/) 154 | 155 | ## Team Website 156 | 157 | [https://www.sanctuary.computer](https://www.sanctuary.computer) 158 | 159 | ## Relevant Experience 160 | 161 | Our team works with the JAM Stack quite often, for client projects! We're very familiar with CI tools (we use CircleCI a lot, and I've used Travis in my open source work). We currently use CircleCI w/ Docker to build and push to S3, so we're familiar with the quirks of getting single page apps up and serving traffic. 162 | 163 | In addition, we're experts in Rails, Docker, Kubernetes, and the like. The software stack we're working with here is a known quantity, through and through. 164 | 165 | ## Team code repositories 166 | 167 | We're a product studio, so most of our client work is private, however we do open source a lot of things [here](https://github.com/sanctuarycomputer/studio), including non-code stuff like financials. 168 | 169 | # Additional Information 170 | 171 | #### Screenshots of [Existing Product](https://www.crystalizer.io) 172 | 173 | ![image](https://user-images.githubusercontent.com/2865404/72011616-3eafa300-3228-11ea-8be0-619a277783c0.png) 174 | ![image](https://user-images.githubusercontent.com/2865404/72011650-4d965580-3228-11ea-9794-7c1475fd1bee.png) 175 | ![image](https://user-images.githubusercontent.com/2865404/72011713-6acb2400-3228-11ea-8e58-0c69c00d7bc4.png) 176 | ![image](https://user-images.githubusercontent.com/2865404/72011745-7ae30380-3228-11ea-881d-8cb363a499ab.png) 177 | ![image](https://user-images.githubusercontent.com/2865404/72011782-8c2c1000-3228-11ea-96cf-ccdaf6f3fff1.png) 178 | -------------------------------------------------------------------------------- /open-grants/completed/ENS.md: -------------------------------------------------------------------------------- 1 | ## ENS EthDNS 2 | 3 | https://eth.link 4 | 5 | etc 6 | -------------------------------------------------------------------------------- /open-grants/ipfs-rust/phase-1/media/fig1-ipfs-rust-risk-assessment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ipfs/devgrants/9b3724f286ef93be22c5cbf26b76e8b11e966c1e/open-grants/ipfs-rust/phase-1/media/fig1-ipfs-rust-risk-assessment.png -------------------------------------------------------------------------------- /open-grants/ipfs-rust/phase-1/media/fig2-ipfs-rust-implementation-schedule.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ipfs/devgrants/9b3724f286ef93be22c5cbf26b76e8b11e966c1e/open-grants/ipfs-rust/phase-1/media/fig2-ipfs-rust-implementation-schedule.png -------------------------------------------------------------------------------- /open-grants/ipfs-rust/phase-1/media/phase-1-0-gantt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ipfs/devgrants/9b3724f286ef93be22c5cbf26b76e8b11e966c1e/open-grants/ipfs-rust/phase-1/media/phase-1-0-gantt.png -------------------------------------------------------------------------------- /open-grants/ipfs-rust/phase-1/media/phase-1-1-gantt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ipfs/devgrants/9b3724f286ef93be22c5cbf26b76e8b11e966c1e/open-grants/ipfs-rust/phase-1/media/phase-1-1-gantt.png -------------------------------------------------------------------------------- /open-grants/ipfs-rust/phase-1/media/phase-1-2-gantt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ipfs/devgrants/9b3724f286ef93be22c5cbf26b76e8b11e966c1e/open-grants/ipfs-rust/phase-1/media/phase-1-2-gantt.png -------------------------------------------------------------------------------- /open-grants/ipfs-rust/phase-1/reports/phase-1.0.md: -------------------------------------------------------------------------------- 1 |

2 |
3 | Rust IPFS: Phase 1.0 Milestone Report 4 |

5 | 6 | The IPFS Rust grant team completed Phase 1.0 on schedule. The following activities were initially scoped and planned: 7 | 8 | - [Project Setup](#project-setup) incl. Git repositories, code organization, and continuous integration 9 | - [HTTP Scaffolding](#http-scaffolding) with `501 NOT IMPLEMENTED` boilerplate 10 | - [Conformance Testing](#conformance-testing) 11 | 12 | In addition to completing the above, we also completed a number of community related efforts. Protocol Labs created a logo (above), Equilibrium created a mascot (below), and we, together, set up bridged chat between [Matrix](https://riot.im/app/#/room/#rust-ipfs:matrix.org) and [Discord](https://discord.gg/9E5SFvW). 13 | 14 | ![Rust IPFS "mascot"](https://user-images.githubusercontent.com/106148/75078320-50e15a00-54d3-11ea-9df4-43d6d04466cf.png) 15 | 16 | We also added trademark and Creative Commons notices to all relevant repositories. 17 | 18 | # Activity Details 19 | 20 | Each heading below represents a specific item promised in the initial grant proposal and relevant notes. 21 | 22 | ## Project Setup 23 | 24 | Goal: Quality of repository administration (as opposed to code quality) 25 | 26 | ### Git Repositories 27 | 28 | We chose the Standard Readme spec. For example, see the [ipfs-rust](ttps://github.com/ipfs-rust/rust-ipfs/pull/72 29 | ) and [ipfs-rust-conformance](https://github.com/ipfs-rust/ipfs-rust-conformance/issues/11) READMEs. We also wrote a [Contributors guide](https://github.com/ipfs-rust/rust-ipfs/issues/61) and added it to the repo, along with [issue and pull request templates](https://github.com/ipfs-rust/rust-ipfs/pull/74). According to GitHub's "Community profile", we have achieved a "green" status. 30 | 31 | Finally, we also applied the [IPFS Community code of conduct](https://github.com/ipfs-rust/rust-ipfs/pull/68) following permission from Protocol Labs. 32 | 33 | ### Code Organization 34 | 35 | We organized the repositories according to the following list. Indentation implies creating crates within subfolders, and importing them via the [Rust module system](https://doc.rust-lang.org/book/second-edition/ch07-00-modules.html). 36 | 37 | - rust-ipfs 38 | - http 39 | - bitswap 40 | - rust-ipld 41 | 42 | ### Continuous Integration (CI) 43 | 44 | We automate away much of the "[definition of done](https://github.com/ipfs/devgrants/tree/master/open-grants/ipfs-rust#definition-of-done)" in this step. 45 | 46 | We set up [automated CI](https://github.com/ipfs-rust/rust-ipfs/pull/69), running on pushes to pull requested branches and master, on `rust-ipfs` and `rust-ipld`. The tests assert a [number of properties](https://github.com/ipfs-rust/rust-ipfs/issues/62), including unit tests, functional tests, code linting and formatting and language idiom checks via the "clippy" tool. The rests even try and execute the examples in the README files via a tool called [skeptic](https://github.com/ipfs-rust/rust-ipfs/issues/41). 47 | 48 | Note that in one instance Rust's `stable` release channel updated from 1.41 to 1.42, eschewing 32 bit iOS / OSX builds, and we were able to catch that and [fix it](https://github.com/ipfs-rust/rust-ipfs/pull/100) that day. 49 | 50 | ## HTTP Scaffolding 51 | 52 | The grant team used the [warp](https://github.com/seanmonstar/warp) Rust framework to scaffold [HTTP endpoints](https://github.com/ipfs-rust/rust-ipfs/issues/60) for conformance testing. This involved creating a long-standing process, and then responding to HTTP calls among specific paths to return the `501 NOT IMPLEMENTED` error code, as opposed to `404 NOT FOUND`. 53 | 54 | The grant team ensured that [all HTTP endpoints](https://github.com/ipfs-rust/rust-ipfs/blob/master/http/src/v0.rs#L30) covered by the `interface-js-ipfs-core` tests were appropriately scaffolded. 55 | 56 | ## Conformance Testing 57 | 58 | The grant team's goal was simply to be able to _run_ the tests against our executable. This involved both adding functionality to `rust-ipfs` as well as extending Protocol Labs' testing framework to accommodate Rust IPFS. 59 | 60 | We created [`npm-rust-ipfs-dep`](https://github.com/ipfs-rust/npm-rust-ipfs-dep/issues/1) which mirrors `npm-go-ipfs-dep`, allowing for the Rust IPFS executable to be installed as an npm dependency. From there we made [small edits](https://github.com/ipfs/js-ipfsd-ctl/pull/473) to `js-ipfsd-ctl`, and then wrote a [custom script](https://github.com/ipfs-rust/ipfs-rust-conformance) to run the interface tests. 61 | 62 | We also edited the `interop` tests in a [similar fashion](https://github.com/ipfs-rust/interop/pull/2). 63 | 64 | Currently all conformance testing, interface and interop, fails. This is intentional as grant progress can now be measured in the ratio of passing/failing tests moving forward. 65 | 66 | # What's Next? 67 | 68 | Phase 1.1 plans to introduce new HTTP endpoints, /pubsub, /swarm, /version, and /id, all of which will pass conformance testing standards. Additionally, we plan to expand our chat bridges to Telegram and Gitter. 69 | -------------------------------------------------------------------------------- /open-grants/ipfs-rust/phase-1/reports/phase-1.1.md: -------------------------------------------------------------------------------- 1 |

2 |
3 | Rust IPFS: Phase 1.1 Milestone Report 4 |

5 | 6 | The IPFS Rust team completed Phase 1.1 one day behind schedule, despite adverse internal and external conditions that threatened to push the project back over one week. The following activities were completed: 7 | 8 | - [HTTP endpoints](#http-endpoints). 9 | - [`/version`](#version) 10 | - [`/id`](#id) 11 | - [`/swarm/*`](#swarm) 12 | - [`/pubsub/*`](#pubsub) 13 | - [Blockstore](#blockstore) research was conducted and deferred until whenever, wherever 14 | - [Miscellaneous](#miscellaneous) Updates and Bug Fixes 15 | - [Conformance testing](#conformance-testing) 16 | - Various [community activities](#community-activities) outside of the grant scope 17 | 18 | ## HTTP Endpoints 19 | 20 | ### /version 21 | 22 | The grant team completed functionality for the [`/version` endpoint](https://github.com/ipfs-rust/rust-ipfs/issues/78), both the plaintext `/version` and the `/api/v0/version` that accepts arguments. See the [pull request](https://github.com/ipfs-rust/rust-ipfs/pull/85) here. 23 | 24 | ### /id 25 | 26 | The grant team completed functionality for the [`/id` endpoint](https://github.com/ipfs-rust/rust-ipfs/issues/79), which returns identifying information about the user's peer. Note that identifying another peer required additional work that was unforseen by the grant team at planning time, and was [pushed to Phase 1.2](https://github.com/ipfs-rust/rust-ipfs/issues/121). 27 | 28 | ### /swarm 29 | 30 | The grant team completed functionality for the [`/swarm` endpoints](https://github.com/ipfs-rust/rust-ipfs/issues/77), We discovered cases involving [multiaddrs with peer ids](https://github.com/ipfs-rust/rust-ipfs/issues/105), which we will address in Phase 1.2. 31 | 32 | ### /pubsub 33 | 34 | The grant team completed the work on the [pubsub functionality](https://github.com/ipfs-rust/rust-ipfs/pull/118) and [HTTP bindings](https://github.com/ipfs-rust/rust-ipfs/pull/118) .Please note the [discrepancy](https://github.com/ipfs-rust/rust-ipfs/issues/76#issuecomment-604053881) between how the `go-ipfs` client and `js-ipfs` client send pubsub messages. 35 | 36 | ## Blockstore 37 | 38 | Rust IPFS currently has three features that lend itself to expanding into a fully-fledged, highly performant blockstore: 39 | 40 | 1. The [`BlockStore`](https://github.com/eqlabs/rust-ipfs/blob/cb664e11f8ec2f4700e860bee2da95de36df6662/src/repo/mod.rs#L51) trait 41 | 2. An in-memory store 42 | 3. A rudimentary filestore. 43 | 44 | The grant team had originally planned to follow latest developments within `go-ipfs` and `js-ipfs` and innovate, as [requested by @stebalien](https://github.com/ipfs-rust/rust-ipfs/issues/84). However, we quickly learned certain architectural decisions are [pending within `ipfs/specs`](https://github.com/ipfs/specs/issues/242), so we postponed any work on the `BlockStore` until those decisions were made. 45 | 46 | This was fortunate, because it allowed us to focus solely on the libp2p integration during this phase, which was certainly a lift in terms of development effort. 47 | 48 | ## Miscellaneous 49 | 50 | - [In memory config](https://github.com/ipfs-rust/rust-ipfs/pull/113) for easier testing: 51 | - Fixing [crate names](https://github.com/ipfs-rust/rust-ipfs/pull/106) 52 | 53 | ## Conformance Testing 54 | 55 | ### Interface 56 | 57 | The grant team is happy to report that [31 interface tests now pass](https://github.com/ipfs-rust/ipfs-rust-conformance/actions/runs/63502176) on the latest build of Rust IPFS. 58 | 59 | The roster of supported endpoints now includes: 60 | 61 | * `/pubsub/{ publish, subscribe, unsubscribe, peers, ls }` 62 | * `/swarm/{connect, peers, addrs, localAddrs, disconnect }` 63 | * `/id` 64 | * `/version` 65 | * `/stop` 66 | 67 | ### Interop 68 | 69 | The grant team discovered that a number of the interop tests, as well as the conformance tests for Phase 1.2, use endpoints that are out of grant scope, primarily `ipfs.add`. PL helped us make the decisions to refactor the tests to use a more limiited set of APIs, which will make conformance easier in the long run. This will take place in Phase 1.2 70 | 71 | ## Community Activities 72 | 73 | Matrix now bridges to a Telegram group called rust-ipfs. 74 | 75 | The grant team submitted two [blog posts](https://github.com/ipfs-rust/rust-ipfs/issues/67) which seemed to be well received by the community. 76 | - https://blog.ipfs.io/2020-03-18-announcing-rust-ipfs/ 77 | - https://medium.com/equilibriumco/announcing-rust-ipfs-af8358f90beb 78 | 79 | The repository has [359 stars](https://github.com/ipfs-rust/rust-ipfs/stargazers) at the time of this writing. 80 | 81 | Mark (@aphelionz) from the Rust IPFS team has attended two IPFS Core Implementation calls. 82 | -------------------------------------------------------------------------------- /open-grants/ipfs-rust/phase-1/reports/phase-1.2.md: -------------------------------------------------------------------------------- 1 |

2 |
3 | Rust IPFS: Phase 1.2 Milestone Report 4 |

5 | 6 | The IPFS Rust team completed Phase 1.2 roughly one week after the estimated time, due both in part to residual governance issues as well as some unforseen complications. In spite of the delay, everything proposed in original grant is now delivered. 7 | 8 | The following activities were completed: 9 | 10 | - [HTTP endpoints](#http-endpoints). 11 | - [`/block`](#block) 12 | - [`/dag`](#dag) 13 | - [`/refs/*`](#refs) 14 | - [`/bitswap/*`](#bitswap) 15 | - [Miscellaneous](#miscellaneous) bug fixes and small refactors 16 | - [Interface Test Refactoring](#interface-test-refactoring), which was required for certain tests 17 | - [Conformance testing](#conformance-testing) 18 | - [Governance](#governance) discussions took place, and some decisions were made 19 | 20 | ## HTTP Endpoints 21 | 22 | ### /block 23 | 24 | The grant team successfully implemented the [`/block`](https://github.com/ipfs-rust/rust-ipfs/issues/90) endpoint suite. 25 | 26 | For now we treat all CIDs as V1 internally, [upgrading them on the way in](https://github.com/ipfs-rust/rust-ipfs/blob/master/src/repo/mod.rs#L119) and only performing the conversion back to V0 if requested or in special cases, e.g. [`refs/local`](https://github.com/ipfs-rust/rust-ipfs/pull/160). 27 | 28 | Relevant pull requests: 29 | - [Foundational work](https://github.com/ipfs-rust/rust-ipfs/pull/137) 30 | - [Implements V0 <--> V1 Conversion](https://github.com/ipfs-rust/rust-ipfs/pull/158) 31 | - [`/block/rm`](https://github.com/ipfs-rust/rust-ipfs/pull/153) 32 | 33 | ### /dag 34 | 35 | The grant team successfully implemented the [`/dag`](https://github.com/ipfs-rust/rust-ipfs/issues/91) endpoint suite. 36 | 37 | A large amount of knowlege has been gained specifically in the area of Ipld path walking, with a by-product of varying approaches in the codebase, each with different properties, features, and use cases. We'd like to narrow those down and would seek Protocol Lab's guidance in coming together with a cohesive approach. 38 | 39 | Relevant pull requests: 40 | - [`/dag/put`](https://github.com/ipfs-rust/rust-ipfs/pull/137) and [fix](https://github.com/ipfs-rust/rust-ipfs/pull/157) 41 | - [`dag/resolve`](https://github.com/ipfs-rust/rust-ipfs/pull/158) 42 | 43 | ### /refs 44 | 45 | The grant team successfully implemented the [`/refs`](https://github.com/ipfs-rust/rust-ipfs/issues/92) endpoint suite. 46 | 47 | Please note the _necessary_ usage of [`unsafe`](https://github.com/ipfs-rust/rust-ipfs/blob/master/http/src/v0/support/unshared.rs#L36) here is due to a compiler bug. This well documented in the code with links to the [hyper](https://github.com/hyperium/hyper/issues/2159), [Rust internals](https://internals.rust-lang.org/t/what-shall-sync-mean-across-an-await/12020), and [async-trait](https://github.com/dtolnay/async-trait/issues/77) issues. Once the compiler bug is fixed, this issue should go away. The warp framework does not share mutable state in its responses. so a "real" problem arising here is very, very unlikely. 48 | 49 | Relevant pull requests: 50 | - [`/refs`](https://github.com/ipfs-rust/rust-ipfs/pull/147) 51 | - [`/refs/local`](https://github.com/ipfs-rust/rust-ipfs/pull/150) 52 | 53 | ### /bitswap 54 | 55 | The grant team successfully implemented the [`/bitswap`](https://github.com/ipfs-rust/rust-ipfs/issues/93) endpoint suite. Overall this was straightforward. Also note that the bitswap crate is currently a refactoring candidate, with a [number of discussion issues](https://github.com/ipfs-rust/rust-ipfs/issues?q=is%3Aopen+is%3Aissue+label%3Abitswap+label%3Arefactoring) arising as to its purpose and approach. PL's guidance would be helpful here as well. 56 | 57 | Relevant pull requests: 58 | - [`/bitswap`](https://github.com/ipfs-rust/rust-ipfs/pull/131) 59 | 60 | ## Miscellaneous 61 | 62 | Relevant pull requests: 63 | - [Subscription deadlocks](https://github.com/ipfs-rust/rust-ipfs/pull/130) were discovered and fixed 64 | - [Flaky tests](https://github.com/ipfs-rust/rust-ipfs/pull/133) were fixed 65 | - The [domain](https://github.com/ipfs-rust/rust-ipfs/pull/151) crate is slightly outdated, so it was pinned to a specific commit 66 | - Small refactor to [remove some `&mut`s](https://github.com/ipfs-rust/rust-ipfs/pull/155) from the codebase 67 | - [`clippy --workspace --tests --examples`](https://github.com/ipfs-rust/rust-ipfs/pull/156) was added to CI, and the resultant [clippy warnings](https://github.com/ipfs-rust/rust-ipfs/pull/159) were dealt with 68 | 69 | ## Interface Test Refactoring 70 | 71 | It was discovered during this effort that many of the interface and interop tests use a diversity of APIs, not just the ones being tested, i.e. `ipfs.add` is used in the `refs.local` tests. With the philosophy that the tests should utilize "lower-level" APIs such as `ipfs.block.put`. 72 | 73 | As part of this work, a number of PRs were made to js-ipfs, two of which have already been merged: 74 | - [ipfs/js-ipfs#2980](https://github.com/ipfs/js-ipfs/pull/2980) 75 | - [ipfs/js-ipfs#2983](https://github.com/ipfs/js-ipfs/pull/2983) 76 | - [ipfs/js-ipfs#2972](https://github.com/ipfs/js-ipfs/pull/2972) 77 | - [ipfs/js-ipfs#2982](https://github.com/ipfs/js-ipfs/pull/2982) 78 | 79 | ## Conformance Testing 80 | 81 | ### Interface 82 | 83 | The grant team is happy to report that **102 interface tests now pass** on the latest build of Rust IPFS. 84 | 85 | The roster of supported endpoints now includes: 86 | 87 | * `/pubsub/{ publish, subscribe, unsubscribe, peers, ls }` 88 | * `/swarm/{connect, peers, addrs, localAddrs, disconnect }` 89 | * `/id` 90 | * `/version` 91 | * `/stop` 92 | * `/block{ get, add, rm, stat }` 93 | * `/dag{ get, put, resolve }` 94 | * `/refs` and `/refs/local` 95 | * `/bitswap/{ stat, wantlist }` 96 | 97 | ### Interop 98 | 99 | Interop tests also use APIs unsupported by Rust IPFS such as `ipfs.add`. However, now, given the progress made on the interface test refactoring, it seems possible to refactor interop in the same way and gain that much more coverage and compatibility between the different language implementations. 100 | 101 | ## Governance 102 | 103 | Governance was challenging during the grant cycle, perhaps due to the project being somewhat in its infancy. Things have stabilized but there is still a risk of it threatening future productivity if [more interpersonal issues](https://github.com/ipfs-rust/rust-ipfs/issues/129) arise. 104 | 105 | Despite this, some breakthroughs and decisions were made, primary in the form of productive discussions in the following issues: 106 | - [Repo abstraction redesign](https://github.com/ipfs-rust/rust-ipfs/issues/142) 107 | - [Error handling alternatives](https://github.com/ipfs-rust/rust-ipfs/issues/144) 108 | - [Overall architecture discussion](https://github.com/ipfs-rust/rust-ipfs/issues/136) 109 | 110 | The repository has [424 stars](https://github.com/ipfs-rust/rust-ipfs/stargazers) at the time of this writing. 111 | 112 | Mark (@aphelionz) from the Rust IPFS team has attended four IPFS Core Implementation calls. 113 | -------------------------------------------------------------------------------- /open-grants/ipfs-rust/phase-2/reports/phase-2.md: -------------------------------------------------------------------------------- 1 |

2 |
3 | Rust IPFS: Phase 2 Milestone Report 4 |

5 | 6 | The IPFS Rust team completed Phase 2 roughly one week after the estimated time, simply due to inherent complexities in the large 7 | feature set created. In spite of the delay, everything proposed in original grant is now delivered. 8 | 9 | The following activities were completed: 10 | 11 | - [ipfs_unixfs](#ipfs_unixfs-crate) crate 12 | - [HTTP Endpoints](#http-endpoints). 13 | - [`/cat`](#get) 14 | - [`/get`](#cat) 15 | - [Miscellaneous](#miscellaneous) bug fixes and upgrades 16 | - [Interface Test Refactoring](#interface-test-refactoring), which was required for certain tests 17 | - [Conformance Testing](#conformance-testing) 18 | - [Test Coverage](#test-coverage) 19 | 20 | ## ipfs_unixfs crate 21 | 22 | Following previous discussions on the repository issues, the grant team 23 | started a new crate in the main repository called `ipfs_unixfs`, which was 24 | designed so that it can be reused not only in `rust-ipfs` but in other 25 | implementations as well. At the moment the implementation supports only the 26 | work implemented in Phase 2 but we hope to grow its feature set in the coming months 27 | to support `/add`, and more. 28 | 29 | ## HTTP Endpoints 30 | 31 | ### /cat 32 | 33 | The grant team completed the functionality for the `/cat` endpoint. Work started 34 | by first implementing initial support for walking file trees in order for the 35 | content in ipfs-unixfs PR [#176] followed by the endpoint implementation in PR 36 | [#184]. 37 | 38 | [#176]: https://github.com/rs-ipfs/rust-ipfs/pull/176 39 | [#184]: https://github.com/rs-ipfs/rust-ipfs/pull/184 40 | 41 | ### /get 42 | 43 | The grant team completed the functionality for the `/get` endpoint in PR [#189]. 44 | The pull request ended up large as a way to split the work between the 45 | iterations could not be found. The pull request ended up addressing a number of 46 | issues: 47 | 48 | * cleanup of overall `ipfs-unixfs` structure 49 | * traversing over UnixFs directories (plain and HAMT Sharded), symlinks and 50 | files (`/cat` feature) 51 | * serving UnixFs content as `tar` at `/get` endpoint 52 | 53 | [#189]: https://github.com/rs-ipfs/rust-ipfs/pull/189 54 | 55 | # Miscellaneous 56 | 57 | Relevant pull requests: 58 | 59 | * [Upgrade to rust-libp2p 0.19] 60 | * [Cache dependencies on Windows builds] 61 | * [Removal of `unsafe` code through dependency upgrade] 62 | 63 | [Upgrade to rust-libp2p 0.19]: https://github.com/rs-ipfs/rust-ipfs/pull/169 64 | [Cache dependencies on Windows builds]: https://github.com/rs-ipfs/rust-ipfs/pull/180 65 | [Removal of `unsafe` code through dependency upgrade]: https://github.com/rs-ipfs/rust-ipfs/pull/191 66 | 67 | # Interface Test Refactoring 68 | 69 | Continuing the work started in previous phases, the `ipfs.add` API use was replaced 70 | in the tests for `/cat` and `/get`. This resulted in two PRs, one of which has 71 | already been merged: 72 | 73 | * https://github.com/ipfs/js-ipfs/pull/3078 74 | * https://github.com/ipfs/js-ipfs/pull/3093 75 | 76 | # Conformance Testing 77 | 78 | ## Interface 79 | 80 | The grant team is happy to report that *121 interface tests now pass* on the 81 | latest build of Rust IPFS. 82 | 83 | The supported endpoints now includes: 84 | 85 | * `/pubsub/{publish,subscribe,peers,ls}` 86 | * `/swarm/{connect,peers,addrs,addrs/local,disconnect}` 87 | * `/id` 88 | * `/version` 89 | * `/stop` 90 | * `/block/{get,add,rm,stat}` 91 | * `/dag/{get,put,resolve}` 92 | * `/refs` and `/refs/local` 93 | * `/bitswap/{stat,wantlist}` 94 | * `/cat` 95 | * `/get` 96 | 97 | ## Automation 98 | 99 | The grant team has been running conformance tests on CI since PR [#98] was merged 100 | at near the beginning of Phase 2. Following testing PR [#24] we are now able to 101 | maintain a patched version of the `interface-ipfs-core` package with our patches 102 | to version we are currently basing the work on. 103 | 104 | [#98]: https://github.com/rs-ipfs/rust-ipfs/pull/98 105 | [#24]: https://github.com/rs-ipfs/ipfs-rust-conformance/pull/24 106 | 107 | # Test Coverage 108 | 109 | Before Phase 2 the line coverage as reported by 110 | `cargo-tarpaulin` (latest version, latest rust toolchain) was 54%, 111 | 1926/3542 lines covered. After Phase 2 the coverage report stands at 57% 112 | coverage, 3232/5653 lines covered. Calculating from the coverage report, over 113 | 2000 lines were added but still the overall coverage was **increased.** 114 | 115 | The new crate, `ipfs-unixfs`, is compiled with different lint settings than 116 | existing code, namely warnings on missing public element documentation has been 117 | enabled. This has lead to the crate having at least minimal documentation and is 118 | supported by two examples: `get` and `cat`, which demonstrate the crates use. 119 | -------------------------------------------------------------------------------- /open-grants/open-proposal-4EVERLAND.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `4EVERLAND` 2 | 3 | **Name of Project:** 4EVERLAND 4 | 5 | **Proposer:** Clarence - [cryptobuffer](https://github.com/cryptobuffer) Core Team of 4EVERLAND. 6 | 7 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** 8 | 9 | Yes. 10 | 11 | 4EVERLAND is licensed with MIT license for code or CC-BY-SA 3.0 license for content. 12 | 13 | # Project Description 14 | 15 | 4EVERLAND is a Web 3.0 cloud computing platform that integrates storage, computing, and network core capabilities. 16 | It aims to help the user make a smooth leap from Web 2.0 to Web 3.0 and become the infrastructure for millions of Web 3.0 developers and applications. 17 | 18 | 4EVERLAND has now launched Gateway Service, Hosting Service, Bucket Service, Gateway service to provide decentralized storage capacity and global acceleration gateway for developers and projects. 19 | 20 | ## Value 21 | 22 | **- 4EVERLAND IPFS Gateway Service& Gateway Explorer**  23 | 4EVERLAND Gateway is dedicated to making various Web3 protocols and blockchain networks compatible with Web2, as well as delivering high-performance and high-availability network service capabilities. 24 | 25 | **- Hosting Service: Hosting Webs or Dapps on IPFS** 26 | Users can quickly deploy websites to IPFS through a Github authorization or a Cli local build via 4EVERLAND Hosting service. 27 | 28 | **- Bucket Service: Store file on IPFS** 29 | Bucket is an AWS S3 compatible storage platform for decentralized storage. 30 | 31 | **- A truly decentralized IPFS storage layer** 32 | 4EVERLAND has established IPFS swarm nodes based on the PoSC consensus mechanism.  33 | The master node will be responsible for backing up all the data stored in IPFS via 4EVERLAND, while the light node will partially back up the data and collaborate with 4EVERLAND's gateway nodes to enhance the availability of the network. 34 | All nodes will be verified and disciplined in a TEE environment.  35 | 36 | **- A Web3 User System** 37 | 4EVERLAND supports wallet login. 38 | This will allow us to integrate more easily with Web3 applications and create more usage and operation ways based on Web3 user identity. 39 | 40 | ## Deliverables 41 | 42 | - Support multi-chain login and payment: users can login to Bucket using various public chain wallets such as ETH, Polygon and Solana, purchase and use IPFS storage space with any assets. 43 | - Interactive user experience: provide users with a smooth experience of pinning data in IPFS, offering a variety of interaction methods including CLI, GUI, SDK, etc. 44 | - Complete the construction of distributed IPFS nodes: complete the construction of IPFS storage nodes based on PoSC consensus, provide stable and highly available data storage services, and implement work including sentinel procedures, reward and punishment mechanisms, and campaign mechanisms. 45 | 46 | ## Development Roadmap 47 | 48 | 49 | | Milestone | People | Funding | Period | 50 | | :------: | :------: | :------: | :------: | 51 | | Deliverables#1 | 4 | $15000 | 10.05.2022 - 18.07.2022 | 52 | | Deliverables#2 | 4 | $5000 | 19.07.2022 - 18.09.2022 | 53 | | Deliverables#3 | 6 | $30000 | 19.09.2022 - 31.12.2022 | 54 | 55 | 56 | ## Total Budget Requested 57 | 58 | $50000 59 | 60 | ## Maintenance and Upgrade Plans 61 | 62 | We've already laid out our plan for next 2 quarters but it doesn't end there. 63 | Please see our V2 roadmap for more details: [V2 Announcements](https://medium.com/4everland/4everland-announcement-4everland-roadmap-v2-f7d6ed3619b3). 64 | 65 | # Team 66 | 67 | ## Team Members 68 | 69 | - Clarence 70 | 71 | Role: Core Team Developer|Full Stack Engineer 72 | 73 | Email: qwertyhqwerty475@gmail.com 74 | 75 | Github: @cryptobuffer 76 | 77 | - Thloyi 78 | 79 | Role: Core Team Developer|4EVER-Hosting Architect 80 | 81 | Email: tfspq@protonmail.com 82 | 83 | Github: @thloyi 84 | 85 | - Saullary 86 | 87 | Role: Core Team Developer|Front End Developer 88 | 89 | Email: saullarytzc94@gmail.com 90 | 91 | Github: @saullary 92 | 93 | ## Team Website 94 | 95 | http://4everland.org/ 96 | 97 | ## Team code repositories 98 | 99 | 4EVERLAND Github - https://github.com/4everland 100 | -------------------------------------------------------------------------------- /open-grants/open-proposal-decompose-ml-tasks.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `Decomposing the Capabilities Learned by Machine Learning Models` 2 | 3 | **Name of Project:** Decomposing Models 4 | 5 | **Proposer:** `craffel` 6 | 7 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** Yes 8 | 9 | # Project Description 10 | 11 | The paradigm of *transfer learning* has increasingly become a standard way of attacking machine learning problems. In transfer learning, a pre-trained model is used as a starting point for additional training on a "downstream" task of input. The use of a pre-trained model can result in faster convergence to a better solution with less labeled data. 12 | 13 | These benefits have spurred the widespread use and development of pre-trained models. Systems like IPFS have the potential to further the proliferation of pre-trained models, thanks to the fact that it will become significantly simpler to share and host these valuable (and typically large) artifacts. 14 | 15 | However, despite transfer learning's successes, it only provides a crude means of transferring capabilities across models. Thinking more broadly, we might hope to decompose pre-trained models into submodels that each represent different capabilities and then recompose submodels to create new models that have the desired set of capabilities. 16 | 17 | For example, to answer the question "how long would it take for a tennis ball to hit the ground after it was dropped from the Burj Khalifa?", the model must understand gravity, be able to perform arithmetic, and know the weight of a tennis ball and the height of the Burj Khalifa. If we have different pre-trained models that can each perform a subset of these capabilities, it would be useful to be able to extract the relevant capabilities and combine them into a new model that has the desired functionality. 18 | 19 | We have already explored this solution space, showing that the gradient of a model's output with respect to its parameters tends to lie in a low-dimensional subspace and can be decomposed using classical methods like principal and independent component analysis. These components tend to correspond to different capabilities of the model, for example distinguishing between different subclasses of the input. We will combine this approach with our past work on [merging models](https://arxiv.org/abs/2111.09832) in order to recombine components and create new models. 20 | 21 | A major advantage of this approach is that it does not require training any new models, which will make it dramatically cheaper than traditional gradient-based training. To perform evaluation, we will make use of the thousands of pre-trained models on the [Hugging Face model hub](https://huggingface.co/models) and show that decomposing and recombining existing models can produce new models that attain strong performance on existing NLP benchmarks. 22 | 23 | While sharing pre-trained models is currently possible, it is typically only done for a very small subset of all of the models that could be shared. A major reason for this is the storage and transmision cost of sharing a given model Ultimately, IPFS will make it possible to store and access much larger amounts of data. This will make it significantly easier to share pre-trained models. The research in this proposal will enable a transformative way of making use of these resources that takes advantage of future possiblities enabled by IPFS. 24 | 25 | ## Value 26 | 27 | *What are the benefits to getting this right?* 28 | 29 | The successful culmination of this proposal will be a new paradigm for leveraging pre-trained models. 30 | The ability to decompose models into task-specific submodels and recombine them has various advantages over traditional sequential transfer learning: 31 | - It will likely be more computationally efficient since it will not involve gradient-based training, 32 | - It will provide a means of interpreting the capabilities of a given pre-trained model, 33 | - It may provide a path towards creating smaller and more resource-efficient models by enabling creating models that contain the minimal set of capabilities to perform a given task. 34 | - It will provide a new way of leveraging pre-trained checkpoints as IPFS enables them to become more widely shared. 35 | 36 | *What are the risks if you don't get it right?* 37 | 38 | Since this is a research-based proposal, it is possible that some of our proposed approaches will not succeed as we intend them to. For example, the performance of a given model on some task may degrade when it is decomposed and recombined with submodels from a different model. However, our preliminary work provides some indication that our proposed approach will be successful, and using our existing work to develop an interpretability method provides a reasonable fall-back plan. 39 | 40 | *What are the risks that will make executing on this project difficult?* 41 | 42 | Like all open-ended research projects, it is open-ended and its success is not guaranteed. However, we have significant background in the area as well as a great deal of experience undertaking open-ended research projects. The main failure mode that we might anticipate is that it is not possible to recombine subcomponents of a given model without sacrificing signficant performance. However, our past work on [merging pre-trained models](https://arxiv.org/abs/2111.09832) provides some preliminary evidence that this will be possible. 43 | 44 | ## Deliverables 45 | 46 | We will produce the following deliverables: 47 | - A codebase implementing our proposed procedure that will be readily applicable to standard pre-trained models. 48 | - A website describing, in terms understandable to the typical machine learning software engineer, how to use our code and procedure for decomposing and recombining pre-trained models. 49 | - A publication submitted to a top-tier machine learning venue describing our approach and results. 50 | 51 | ## Development Roadmap 52 | 53 | Since this is an open-ended research project, the exact plan and roadmap may change as we evaluate different approaches and determine what works best. Regardless of the specific approach developed, we will ultimately focus on the same final goal of enabling pre-trained models to be decomposed and recombined. The entirety of the project will be undertaken by me and one graduate research assistant. 54 | 55 | I will serve as an advisor, helping set the direction of the project and stepping in to perform experiments, write code, and write a paper as appropriate. My graduate research assistant will perform the bulk of the work on the project. 56 | 57 | Specifically, we will focus on the following milestones: 58 | 1. Validating our existing approach for decomposing the underlying capabilities of a pre-trained model (2 months). 59 | 60 | * This will include applying our technique to existing pre-trained models and analyzing the results. 61 | * Most of this analysis will be qualitative. We have preliminary code implementing this functionality, but we will also work to mature the codebase to make it easier to develop more advanced methods. 62 | 63 | 1. Developing methods for recombining decomposed submodels (2 months). 64 | * This will primarily require mapping back from the decomposition of parameter gradients to parameter values. We will make use of our past work on [merging models](https://arxiv.org/abs/2111.09832). 65 | 1. Evaluate our proposed approach on standard NLP benchmarks (2 months). 66 | * We will make use of pre-trained models from the [Hugging Face model hub](https://huggingface.co/models) and evaluate on standard NLP datasets from the [datasets library](https://github.com/huggingface/datasets). 67 | * Our codebase will aim to be a lightweight layer on top of these existing tools so that it can be easily integrated into other codebases that make use of them. 68 | 1. Write paper and prepare code for release (2 months). 69 | * We will submit our work to a top-tier machine learning venue. 70 | * We will also release our codebase with clear documentation to make it easily applicable for practitioners. 71 | 72 | ## Total Budget Requested 73 | 74 | We request a budget of $50,000. The entirety of this budget will go towards [support](https://cs.unc.edu/research/research-support/proposal-prep/student-compensation/) of a single graduate research assistant for one year. 75 | 76 | ## Maintenance and Upgrade Plans 77 | 78 | Our primary goal with the code produced by this project will be to serve as a demonstration of the proposed functionality. 79 | 80 | We will base it on the popular [Hugging Face Transformers](https://huggingface.co/docs/transformers/index) library, ensuring that it will be easily adoptable. 81 | 82 | Further, by basing our code on an established and widely-used library, we will ensure that it will be useable in the long term. 83 | 84 | We also will publish our results in an archival venue, so that the high-level description of our algorithms is permanently available. 85 | 86 | # Team 87 | 88 | ## Team Members and website 89 | 90 | My lab members are listed on my website: https://colinraffel.com/ 91 | 92 | ## Relevant Experience 93 | 94 | * I have a long history of developing important pre-trained models. 95 | * I was the lead developer of the T5 model, which remains the largest publicly-available pre-trained neural network over two years since its release. 96 | * I led the organization of the recent ICLR 2021 Workshop on Enormous Language Models. 97 | * I have given invited talks on the topic at workshops at NeurIPS, CVPR, ISMIR, AKBC, and many other venues. 98 | * Recently, I have been developing a [research agenda](https://colinraffel.com/blog/a-call-to-build-models-like-we-build-open-source-software.html) focused on making it possible to develop machine learning models in a collaborative and continual manner (much in the way that open-source software is developed). 99 | * Preliminary work in this direction includes methods for [merging models](https://arxiv.org/abs/2111.09832) and [communication-efficient training](https://arxiv.org/abs/2111.09839). 100 | 101 | ## Team code repositories 102 | 103 | Code for related research projects done by me and my students include: 104 | - https://github.com/google-research/text-to-text-transfer-transformer/ 105 | - https://github.com/mmatena/model_merging 106 | - https://github.com/varunnair18/FISH/ 107 | -------------------------------------------------------------------------------- /open-grants/open-proposal-defi-for-sustainable-supply-chains-2.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `DeFi for Sustainable Supply Chains 2` 2 | 3 | **Proposer:** [Evan Powlowsky](https://github.com/AdaptiveResources) 4 | 5 | **Table of Contents** 6 | 7 | - [Description](#project-description) 8 | - [Value](#value) 9 | - [Deliverables](#deliverables) 10 | - [Milestones and Funding](#milestones-and-funding) 11 | - [Total Budget Requested](#total-budget-requested) 12 | - [Maintenance and Future Plans](#maintenance-and-future-plans) 13 | - [Operations](#operations) 14 | - [Big Picture](#big-picture) 15 | - [Team](#team) 16 | - [Team Members](#team-members) 17 | - [Adaptive Website](#team-website) 18 | - [Relevant Experience](#relevant-experience) 19 | - [Code Repositories](#team-code-repositories) 20 | - [Support and Funding](#support-and-funding) 21 | 22 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** YES 23 | 24 | # Project Description 25 | 26 | The global innovation economy depends on components made with critical minerals and metals such as tantalum, cobalt, and gold. Demand for these minerals is expected to rise rapidly over the coming years with expanded battery storage and renewable energy utilization. At the same time, it is common for the individuals who extract these resources, essential to humanity's clean energy future, to face poverty, poor labor conditions, and health and safety risks. The complexity of multi-tiered supply chains also makes it difficult for downstream brands (technology companies, battery manufacturers, jewelers etc.) to contribute to solutions in a meaningful manner. 27 | 28 | Adaptive seeks to make supply chains more transparent and fair for the upstream producers. The Adaptive protocol is a framework of blockchain smart contracts that generate non-fungible ‘claim tokens’ representing an underlying physical asset. Tokens will be purchased and traded by downstream supply chain actors. Claim creators in this protocol must meet specific responsible sourcing guidelines for onboarding. Claim creators using the Adaptive protocol will be rewarded for meeting these standards, creating claim tokens, and using the application. 29 | 30 | As a claim token is sold and transferred downstream through the supply chain, the producers of the claim and associated civil society actors - known as “Beneficiaries” - will be compensated for participation in the Claim Application. This can be used to finance mine site improvements, increase worker pay, and drive the adoption of “due diligence” practices that make improvements across the value chain. The beneficiaries along with the physical properties of the asset are recorded in the claim token and stored immutably on the blockchain. 31 | 32 | When a claim is purchased on the Adaptive Marketplace, the beneficiaries recorded in the claim token itself are credited with a percentage of the sale proceeds. Upon completion of a claim token sale, the seller of a claim receives a percentage of the claim token’s value. The remaining profit will be divided between Beneficiaries recorded in the claim. Beneficiary accounts tied to a claim token’s ‘metadata’ can withdraw their individual proceeds at any time. 33 | 34 | 35 | ## Value 36 | 37 | Adaptive has created an approach to store Claim information in a decentralized and transparent manner. This allows supply chain data to be shared and transferred from one tier of the supply chain to the next. Adaptive’s first Filecoin foundation grant allowed us to build tooling for auditing Adaptive claim tokens through an external package. Additionally, we created multiple dashboards for tracking the claim token lifecycles and various parameters related to beneficiary pay-outs. These were major steps in moving our platform through the alpha development phase into the beta stage. Our next set of work focuses on necessary UI/UX improvements and usability testing, to ensure the product is ready for pilot testing. A major UX improvement includes developing a crypto to fiat off-ramp for our users. In addition, we will automate our Know Your Customer (KYC) process to onboard potential users into the application, as unique user types. Our process will follow United States and international requirements around know your customer, vendor, and counterparty regulations. 38 | 39 | Further updates anticipated during this grant include the development of a “corrective action plan” as part of our risk management tools. The corrective action plan component will be connected to risk reporting tools, so that claim token buyers are provided the status updates around the risk treatment areas detailed in claim tokens. The data generated using corrective action plans are crucial in measuring the success of the risk treatment interventions and measuring the protocol's impact on the users of the application. We will also expand our interactive map component, which has been placed on the landing page of the application. The risk map shows different production locations supported and risks identified in those locations. The map will provide users with additional insights into areas where claim token revenue can be mostly valuably directed. 40 | 41 | 42 | ## Deliverables 43 | 44 | 1). Adaptive Risk Map: A web app feature built using MapBox components will be expanded. The map will overlay production areas with risk data from 3rd party providers and Adaptive risk assessment data. Risk data will be used to further refine focus areas for Adaptive Claims. 45 | 46 | 2). User Types and KYC Onboarding for New Users: Establish official know your customer (KYC) procedure and standards for onboarding users to the Adaptive platform along all tiers of the supply chain. This includes the development of an automated form to collect required KYC information from users store non-sensitive information in a cloud database. We will ensure the architechure is aligned with payment processing standards requiremented by banking and financial services partners. We will explore the benefits and need of partnering with a Compliance as a Service (CaaS) provider. 47 | 48 | 3). Corrective Action Plan for Risk Management: As part of the Adaptive platform, we will develop a “Corrective Action Plan” feature that is integrated with our Beneficiary Risk Reporting features. As beneficiaries report on their progress the information will automatically flow into the corrective action plan, providing claim token buyers with up to date status of risks for specific claim tokens they have purchased. 49 | 50 | 4). Traceability Tool and Data Carrier Development: The Adaptive Trace tool will be developed in a manner that allows users to maintain an “identity preserved” chain of custody from mining location to point of export. This includes the development of a mobile scanning tool and a secure/sealable shipping package with Adaptive QR Code. Exporters using Adaptive will be asked to scan QR stickers, using the Adaptive application, during the Claim Creation process. 51 | 52 | 53 | ## Milestones and Funding 54 | 55 | Work for milestones will begin on July 1st, 2022 56 | 57 | | Milestone | Description | Hrs | Cost | 58 | | --------- | --------------------------------------------------------------------------------------- | --- | ---- | 59 | | 1 | “Adaptive Risk Map” expansion showing various risk indicators in a primary set of mining locations. Includes cost of 3rd party data sets. | 30 | 3000 | 60 | | 2 | User Types and the Design and build a KYC onboarding process for new users of the application. | 90 | 9000 | 61 | | 3 | Corrective Action Plan | 45 | 4500 | 62 | | 4 | Traceability Tool Integration with Data Carrier | 60 | 6000 | 63 | 64 | ### Total Budget Requested 65 | 66 | - **Total Funding Amount:** $22,500 67 | 68 | ## Maintenance and Future Plans 69 | 70 | ### Operations 71 | 72 | The smart contracts are currently deployed and upgradable. There should be little maintenance on the contracts themselves. Adaptive will be focused on preparing for pilot implementation, user onboarding, and completing our milestones. 73 | 74 | ### Big Picture 75 | 76 | Adaptive seeks to develop partnerships with private sector companies, industry associations, certification programs, and auditing bodies that will benefit from the Adaptive Claim system. As stakeholders in the region and internationally learn about the positive impact, we hope to rapidly grow the claims system network. Additionally, we will seek additional grant funding and support from development agencies and foundations who seek to drive due diligence and responsible sourcing through supply chains. 77 | 78 | ## Team 79 | 80 | ### Team Members 81 | 82 | - Software Development - [Evan Powlowsky](https://github.com/PowVT) 83 | - Advisors - Jonathan Ellermann, Dave Snow 84 | 85 | ## Team Website 86 | 87 | Website: [Adaptive Resources](https://adaptiveresources.io) 88 | 89 | ## Relevant Experience 90 | 91 | Evan, the lead engineer, has been working on this project since April 2021, developing the smart contract architecture and front end for the project. 92 | 93 | The team has extensive experience in responsible minerals and renewable energy. The team has been involved in supporting ASM sourcing guidance for the gold and 3T industry, including managing teams in Uganda and Rwanda in the responsible sourcing field. 94 | 95 | ## Team Code Repositories 96 | 97 | -[Smart Contracts](https://github.com/PowVT/adaptive-smart-contracts) (solidity files) 98 | -[ipfs-claims](https://github.com/AdaptiveResources/ipfs-claims) (npm package) 99 | 100 | ## Support and Funding 101 | 102 | Previously supported by funding [grant](https://github.com/ipfs/devgrants/pull/120) accepted by Filecoin. 103 | -------------------------------------------------------------------------------- /open-grants/open-proposal-defi-for-sustainable-supply-chains.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `DeFi for Sustainable Supply Chains` 2 | 3 | **Proposer:** [Evan Powlowsky](https://github.com/PowVT) 4 | 5 | **Table of Contents** 6 | 7 | - [Description](#project-description) 8 | - [Value](#value) 9 | - [Deliverables](#deliverables) 10 | - [Milestones and Funding](#milestones-and-funding) 11 | - [Total Budget Requested](#total-budget-requested) 12 | - [Maintenance and Future Plans](#maintenance-and-future-plans) 13 | - [Operations](#operations) 14 | - [Big Picture](#big-picture) 15 | - [Team](#team) 16 | - [Team Members](#team-members) 17 | - [Adaptive Website](#team-website) 18 | - [Relevant Experience](#relevant-experience) 19 | - [Code Repositories](#team-code-repositories) 20 | - [Support and Funding](#support-and-funding) 21 | 22 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** YES 23 | 24 | # Project Description 25 | 26 | The global innovation economy depends on components made with critical minerals and metals such as tantalum, cobalt, and gold. Demand for these minerals is expected to rise rapidly over the coming years with expanded battery storage and renewable energy utilization. At the same time, it is common for the individuals who extract these resources, essential to humanity's clean energy future, to face poverty, poor labor conditions, and health and safety risks. The complexity of multi-tiered supply chains also makes it difficult for downstream brands (technology companies, battery manufacturers, jewelers etc.) to contribute to solutions in a meaningful manner. 27 | 28 | Adaptive seeks to make supply chains more transparent and fair for producers. The Adaptive protocol is a framework of blockchain smart contracts that generate non-fungible ‘claim tokens’ representing an underlying physical asset. Tokens will be purchased and traded by downstream supply chain actors. Claim creators in this protocol must meet specific responsible sourcing guidelines for onboarding. Claim creators will be rewarded for meeting these standards, creating claim tokens, and using the application. 29 | 30 | As a claim token is sold and transferred downstream through the supply chain, the producers of the claim and associated civil society actors - known as “Beneficiaries” - will be compensated for participation in the Claim Application. This can be used to finance mine site improvements, increase worker pay, and drive the adoption of “due diligence” practices that make improvements across the value chain. The beneficiaries along with the physical properties of the asset are recorded in the claim token and stored immutably on the blockchain. 31 | 32 | When a claim is purchased on the Adaptive Marketplace, the beneficiaries recorded in the claim token itself are credited with a percentage of the sale proceeds. Upon completion of a claim token sale, the seller of a claim receives a percentage of the claim token’s value. The remaining profit will be divided between Beneficiaries recorded in the claim. The beneficiaries can withdraw their individual proceeds from downstream token sales at any time. 33 | 34 | ## Value 35 | 36 | Currently, the target users of the application largely rely on paper based certificate systems that do not store data in a decentralized and transparent manner. We hope to pioneer the usage of IPFS for supply chain traceability and provide a secure way to store all claim data. Adaptive seeks to expose responsible sourcing stakeholders to the distributed web through IPFS. 37 | 38 | We plan to develop tooling around IPFS which makes it easier for auditors on our platform to view important claim information and validate claims. This will take form as a javascript implementation and finalize in a npm package called ‘ipfs-claims’. 39 | 40 | Additionally, Adaptive relies on IPFS to pin and retrieve claim documents to/from the network. Adaptive wants to increase its IPFS node swarm with grant funding to decrease reliance on central providers like Pinata and Infura. Further strengthening the IPFS Filecoin ecosystem. 41 | 42 | Due to the unique nature of this claim system it is important we have measures in place to train users on setting up their digital wallets and interacting with the application. The more beneficiaries attracted to the platform, the larger the claims ecosystem will become. 43 | 44 | ## Deliverables 45 | 46 | 1). ipfs-claims: A npm package of components that we will use to parse IPFS claims data. These tools will help standardize claim forms and help our partners audit the claims. 47 | 48 | 2). Claims-dashboard: In addition to our current app a set of react components will be built for the tracking of claims after creation. The dashboard will include features like the number of token transfers, IPFS data, the claim creator, auditing history and more. For efficiency, Adaptive will run and maintain multiple IPFS daemons pinning the data created in the app. 49 | 50 | 3). Beneficiary-dashboard: A set of react components for tracking beneficiary payouts. Similar to the claims dashboard but focusing on the claims payouts, number of payouts, total payout, and all IPFS data for the beneficiary. For both dashboards IPFS data will be fetched through the ipfs-js library. 51 | 52 | 4). Pilot Test Report: A scientific report detailing the outcome of the pilot implementation. Specifically, how the claims tooling and overall app performed when being used in production. IPFS claims will be generated by the users during the pilot and a report will detail their experience. The report will help Adaptive Resources market IPFS claims and shine a light on using IPFS in this manner. 53 | 54 | ## Milestones and Funding 55 | 56 | Work for milestones will begin on December 1st, 2021 57 | 58 | The Adaptive team seeks to pilot the application at selected mine site (gold) and associated supply chain as soon as feasible. During this pilot period development of the application will be ongoing concurrently. 59 | 60 | | Milestone | Description | Hrs | Cost | 61 | | --------- | --------------------------------------------------------------------------------------- | --- | ---- | 62 | | 1 | npm package for verifying claims data on IPFS | 60 | 4500 | 63 | | 2 | CLI tools for testing npm package and auditing claims | 15 | 1125 | 64 | | 3 | Front end claims dashboard to improve user experience | 30 | 2250 | 65 | | 4 | Beneficiaries dashboard for UX and marketing | 30 | 2250 | 66 | | 5 | Automated testing scripts for dashboards using hardhat.js + IPFS local test environment | 30 | 2250 | 67 | | 6 | Scientific report on IPFS implementation, claims creation, and auditing | 15 | 1125 | 68 | 69 | ### Total Budget Requested 70 | 71 | - **Total Funding Amount:** $13,500 72 | 73 | ## Maintenance and Future Plans 74 | 75 | ### Operations 76 | 77 | The smart contracts are currently deployed and upgradable. There should be little maintenance on the contracts themselves for they have been under development for close to 8 months. Adaptive will be focused on a successful pilot implementation and completing our milestones. 78 | 79 | ### Big Picture 80 | 81 | Adaptive seeks to develop partnerships with private sector companies, industry associations, certification programs, and auditing bodies that will benefit from the Adaptive Claim system. As stakeholders in the region and internationally learn about the positive impact, we hope to rapidly grow the claims system network. Additionally, we will seek additional grant funding and support from development agencies and foundations who seek to drive due diligence and responsible sourcing through supply chains. 82 | 83 | ## Team 84 | 85 | ### Team Members 86 | 87 | - Software Development - [Evan Powlowsky](https://github.com/PowVT) 88 | - Advisors - Jonathan Ellermann, Dave Snow 89 | 90 | ## Team Website 91 | 92 | Website: [Adaptive Resources](https://adaptiveresources.io) 93 | 94 | ## Relevant Experience 95 | 96 | Evan, the lead engineer, has been working on this project since April 2021, developing the smart contract architecture and front end for the project. 97 | 98 | The team has extensive experience in responsible minerals and renewable energy. The team has been involved in supporting ASM sourcing guidance for the gold and 3T industry, including managing teams in Uganda and Rwanda in the responsible sourcing field. 99 | 100 | ## Team Code Repositories 101 | 102 | [Smart Contracts](https://github.com/PowVT/adaptive-smart-contracts) 103 | 104 | ## Support and Funding 105 | 106 | This grant is privately funded. 107 | -------------------------------------------------------------------------------- /open-grants/open-proposal-defluencer.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `Defluencer` 2 | 3 | **Name of Project:** Defluencer 4 | 5 | **Proposer:** Simon-Pierre Vivier ([@SionoiS](https://github.com/SionoiS)) 6 | 7 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** Yes 8 | 9 | # Project Description 10 | 11 | Social medias apps are centralized data silos right now. I will build social.defluencer.eth, a web3 social media website. It will help me improve my decentralized social media protocol and give a taste of what web3 can do. 12 | 13 | I've been working on this project since HackFS 2020. Here's what is fonctional as of now. 14 | - First we have, adaptative bit-rate live streaming using PubSub, IPLD & IPFS. 15 | - Second, non-live streaming with adaptative bit-rate is done in a similar way. 16 | - Third, live chat using PubSub and Metamask (for signatures). 17 | - Forth, the social web is built with IPNS addresses (ION or ENS could also be used) pointing to a user content and friend list wrapped in an object giving us a CID for every users. (ENS domain names can resolve to this CID) 18 | - Fifth, IPLD schemas for common social media content. 19 | 20 | defluencer.eth the project website W.I.P. -> https://bafybeifuu2njrul54bimwmxhvp6ozz3rwviubwpjutpyixu62allne3nwm.ipfs.dweb.link 21 | 22 | I plan to make some part of the protocol more modular. For example, I might use DIDs and different kind of indexing methods. I also want to clarify ownership of content when sharing. 23 | 24 | ## Value 25 | 26 | Crypto/web3 communities could decentralize all their means of communication. IPFS usage would increase as would Filecoin. It would be fertile ground for new businesses; archiving, serving content, transcoding video, AI moderation & filtering, content indexing, etc... 27 | 28 | This project is highly dependant on browser integration for; IPFS, IPLD & PubSub. 29 | The current environement is unsuitable for mass adoption as it require too much configuration. 30 | Waiting for fully fonctional IPFS APIs in browser is unproductive as both can be work on in parallel. 31 | 32 | ## Deliverables 33 | 34 | - A decentralized social media website where users can; 35 | - Create identities with avatar and name. 36 | - Follow each others to get content updates. 37 | - Scroll a feed of all the content/comments they and the people they follow created. 38 | - Watch live streams and chat with the audience. 39 | - Post videos, micro-blog, photos, articles and comments. 40 | - A report on the scalability of live streaming with IPFS. 41 | - Updates to rust-web3 or an Ethereum Name Service library for Rust. 42 | - Updates to reqwest. 43 | - Updates to rust-ipfs-api. 44 | 45 | ## Development Roadmap 46 | 47 | Start date would be around new year. 48 | 49 | ### Milestone 1: Libs 50 | 51 | Needed crates (rust libs) for the project. 52 | Would allow the crate in the next milestone to be compiled to any rust supported targets including WASM and 90% of the code would be shared between the CLI & website. If the maintainers do not want the changes I propose, I will create forks or new crates with the features I need. 53 | 54 | - Pull request to [rust-web3](https://github.com/tomusdrw/rust-web3) with most ENS fonctionalities. 55 | - Code. (mostly done already) 56 | - Tests. 57 | - Documentation. 58 | - Pull request to [reqwest](https://github.com/seanmonstar/reqwest) crate for; 59 | - WASM support for byte streams 60 | - WASM support for multipart/form 61 | - Pull request to [rust-ipfs-api](https://github.com/ferristseng/rust-ipfs-api) crate for; 62 | - WASM support 63 | - Async IPFS add. 64 | 65 | Test the scalability of the live-streaming with [Testground](https://github.com/testground/testground). 66 | 67 | Due date 1 April 2022. (3 Months) 68 | 69 | ### Milestone 2: Fonctionalities 70 | 71 | Create and publish a crate (lib) with theses features. 72 | 73 | - User Management. 74 | - Create a new user. 75 | - Optional linking to ENS domain name. 76 | - Manage multiple users. 77 | - Export/Import users crypto keys. 78 | - Content Management. 79 | - Create new content. 80 | - Videos. 81 | - Micro-blog post. 82 | - Photos. 83 | - Articles. 84 | - Comments. 85 | - Update content. 86 | - Delete content. 87 | - Content Ownership. 88 | - Optional Blockchain timestamping. (Bring Your Own Blockchain kinda feature) 89 | - Optional Cryptographic signatures. (DAG-JOSE) 90 | - Social Web Crawling Tools. 91 | - Content Agregation Tools. 92 | 93 | Build a CLI with it. 94 | 95 | Due date 1 September 2022. (5 months) 96 | 97 | ### Milestone 3: UI 98 | 99 | Create social.defluencer.eth a decentralized social media website. 100 | 101 | Due date 1 January 2023. (4 months) 102 | 103 | ## Total Budget Requested 104 | 105 | | Milestone | Total | 106 | |-|-| 107 | | Milestone 1 | 5,000 USD | 108 | | Milestone 2 | 8,333 USD | 109 | | Milestone 3 | 6,666 USD | 110 | | **Total** | **20,000 USD** | 111 | 112 | ## Maintenance and Upgrade Plans 113 | 114 | The website would receive bug fixes but no new features. Building new websites and apps on the same protocol would be preferable. 115 | 116 | The rust ENS crate would require mininal maintenance as the smart-contracts don't change much or be maintained by the rust-web3 community if merged. 117 | 118 | The main crate (lib) would hopefully attract contributors, lessening the load on myself as it would be used by multiple apps and websites. 119 | 120 | # Team 121 | 122 | ## Team Members 123 | 124 | - Simon-Pierre Vivier ([@SionoiS](https://github.com/SionoiS)) 125 | 126 | ## Relevant Experience 127 | 128 | I've been working on the protocol, in my spare time, since HackFS 2020, a lot has been done already but as they say 90% done 90% to go. 129 | 130 | ## Team code repositories 131 | 132 | [Defluencer](https://github.com/Defluencer) 133 | 134 | -------------------------------------------------------------------------------- /open-grants/open-proposal-distributed-pinning-protocol.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `Distributed Pinning Protocol` 2 | 3 | **Name of Project:** Photon 4 | 5 | **Proposer:** `@zuriel-photon` 6 | 7 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** Yes 8 | 9 | # Project Description 10 | 11 | IPFS is a perfect architecture for the distributed file system, where community members contribute disk capacities. The Web2 companies are beginning to move to Web3, and we can foresee that the demand for distributed data storage will grow to Web2 levels. It will be a significant challenge for IPFS to meet the demand by relying on voluntary contributions. We propose a protocol design to incentivise individuals/groups to run IPFS nodes by providing monetary rewards for their direct contributions. 12 | 13 | Our project, Photon, creates a distributed storage marketplace by introducing an incentive layer for IPFS nodes. Storage providers are rewarded for executing data pinning tasks. The rewards are dynamically adjusted based on demands and contributions. As the storage demand grows over time, the network will scale accordingly. 14 | 15 | Technically, Photon is a blockchain with dedicated smart contracts to ensure IPFS nodes pinning data is within the contracted period. This proposal only provides a typical workflow within the protocol. More technical detail can be found in our white paper to be published shortly. 16 | 17 | Data Owner: 18 | 1. Upload the data content to the IPFS network and obtain the CID. 19 | 2. Create a signed smart contract including CID, storage period, fee, and upload to the IPFS. 20 | 3. Pending contract gets countersigned and committed to the Photon chain by Pinning Node. 21 | 4. If data cannot be retrieved on the IPFS, initiate a dispute in the Photon chain. 22 | 23 | Pinning Node: 24 | 1. Regularly scan the IPFS network and obtain storage contracts of interest. 25 | 2. For each contract, download the content by CID and start pinning the contracted data. 26 | 3. Countersign the contract, and submit it to the Photon chain. 27 | 4. If the data owner initiates a dispute, submit the proof of retrievability to the Photon chain. 28 | 5. If a contract is being executed faithfully, reward accumulates accordingly. 29 | 30 | ## Value 31 | 32 | ### What are the benefits of getting this right? 33 | 1. Create a distributed pinning service, helping IPFS aggregate network capacity. 34 | 2. Encourage enterprise/individuals to run stable IPFS nodes 24/7. 35 | 3. Avoid centralised pinning service provider’s control of the entry point of IPFS. 36 | 37 | ### What are the risks if you dont get it right? 38 | The protocol is built above the IPFS, so it will not affect the IPFS network even if the project fails. The only risk it might have is if the protocol becomes successful. Unpinned data can get flushed out quickly from IPFS because all the nodes prefer to pin data with incentives. 39 | 40 | ### What are the risks that will make executing this project difficult? 41 | We have finished the feasibility verification and have an internal prototype running. The chain can suffer performance degradation if the stored data size grows to zettabyte-level. At that point, scaling solutions such as sharding or zero-knowledge proof can be considered and implemented accordingly. 42 | 43 | ## Deliverables 44 | 45 | The project will be delivered in two phases. 46 | 1. Stable Photon protocol with integrated IPFS nodes allows users to use the command-line tool to exercise workflow of the process, including post pinning contact, countersign contract, initiate a dispute, and proofs retrievability. 47 | 2. Interactive UX: provide users with a smooth experience pinning data in IPFS. An easy setup bot allows any IPFS node to join the distribution pinning protocol and enjoy pinning to earn. 48 | 49 | ## Development Roadmap 50 | 51 | 52 | | Milestone | People | Funding | Period | 53 | | :------: | :------: | :------: | :------: | 54 | | Deliverables#1 | 5 | $15000 | 10.02.2022 - 18.09.2022 | 55 | | Deliverables#2 | 5 | $15000 | 20.09.2022 - 23.11.2022 | 56 | 57 | 58 | ## Total Budget Requested 59 | 60 | We requested $30,000 to accomplish the two milestones. All the budget will be exchanged to the FIL, and use these FILs to stimulate the IPFS community to test the product and assist us with testing and reach the final stable version. 61 | 62 | ## Maintenance and Upgrade Plans 63 | 64 | 1. Use sharding or zk-proof to solve the performance issue. 65 | 2. Create a cross-chain bridge that supports FIL, ETH, and BTC. Allow using different assets to pay the pinning service fee. 66 | 3. Add bandwidth incentive for IPFS nodes to cache the hot data. 67 | 68 | # Team 69 | 70 | ## Team Members 71 | 72 | The project is open source, but the team wishes to keep some level of anonymity. 73 | 74 | - @zuriel-photon 75 | - Joined the Bitcoin community in 2012. 76 | - Served as a CTO for a blockchain company for four years. 77 | 78 | - @maxkaneco 79 | - PhD in CS, ex-Facebook core engineer. 80 | - Built a mining pool service that can dynamically allocate computation between mining and AI training. 81 | 82 | ## Team Website 83 | - http://photon.storage/ 84 | 85 | ## Relevant Experience 86 | Except for two co-founders, we have three blockchain engineers with 3+ years of experience. The team has deep expertise in the blockchain, wallet, explorer, mining pool, and Defi. We began researching the Web3 storage field in May 2021 and started coding Photon in Feb 2022 87 | 88 | ## Team code repositories 89 | - The code is still in active development since Feb 2022. We will be [open source](https://github.com/photon-storage) in September. 90 | 91 | ## Additional Information 92 | 1. For the proof of retrievability, implement the famous paper in Golang: H. Shacham and B. Waters. Compact proofs of retrievability. 93 | 2. For the consensus layer, we forked Prysm’s Ethereum beacon chain and refactored nearly 50% of the codebase to fit Photon’s need. An internal running version is established. -------------------------------------------------------------------------------- /open-grants/open-proposal-embedded-ipfs.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `Simplified Lightweight IPFS for embedded systems` 2 | 3 | 4 | 5 | **Name of Project**: _Embedded IPFS_ 6 | 7 | 8 | 9 | **Proposer**: `GeorgeTsagk` - Libre Space Foundation 10 | 11 | 12 | 13 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** 14 | 15 | "Yes" 16 | 17 | # Introduction 18 | 19 | 20 | ### About _Libre Space Foundation_: 21 | Libre Space Foundation is a non-profit organization creating open source space technologies. LSF is active on several free software, open hardware and open data projects directly related to space applications and technologies while producing open-data and know how for all. 22 | 23 | One of the most active Libre Space projects is SatNOGS, the open global satellite ground-station network. It is designed as an open source participatory project based on the users operating a ground station that is accessed via a web page for all of the network users. 24 | 25 | Libre Space together with the University of Patras are also the makers of UPSat, the 1st free software, open-hardware cubesat. 26 | 27 | Libre Space Foundation is also implementing the European Space Agency activity SDR Maker Space working on several open-source Software Defined Radio sub-activities, to facilitate satellite communications. 28 | 29 | 30 | ### Project Goal: 31 | The goal of this project is to provide a simplified, yet fully functional, IPFS implementation suitable for embedded systems, 32 | allowing embedded system networks to interoperate with the existing IPFS networks. 33 | 34 | 35 | # Project Description 36 | 37 | Applying the IPFS concept on embedded systems and success in exchanging information between them will show the wide field of applications that IPFS can cover and extend it even more by bootstrapping new opportunities. 38 | 39 | At greater scales, the content-addressed concept between systems exchanging data can prove very suitable in terms of code complexity for the end user, as well as data consistency in cases of sub-system failure, without over-stressing the hardware. Such examples could be multiple-subsystem satellites or any generic network of connected devices (e.g. IoT). 40 | 41 | The IPFS concept best serves flexible and modular decentralized networks, which is the new trend in embedded systems. 42 | 43 | This project aims to: 44 | * investigate the optimal way of applying an IPFS PoC on embedded systems 45 | * provide the design and an implementation of a simple and lightweight solution 46 | * demonstrate embedded-to-embedded utilization 47 | * explore ways of establishing full interoperation with existing IPFS implementations 48 | 49 | 50 | # Value 51 | 52 | If the application of this concept proves functional, then not only is the IPFS application width extended, but it opens a lot of opportunities in integrating with existing networks. 53 | 54 | An integrating example could be the propagation of information by using an embedded system as a node able to dynamically join / seperate from IPFS networks. 55 | 56 | For example a literate inter-planetary exchange of information that treats the system as the moving node which serves as the information carriage (e.g. a futuristic concept where a device being a node on Earth travels and becomes a node on Mars). In such a case, the device could also internally utilize a simplified IPFS implementation for inter-system communications. 57 | 58 | Apart from the last example, a functional implementation of such a concept in embedded systems could be expanded in order to be used by device networks sharing data while serving many different roles (e.g. IoT). 59 | 60 | An unsuccessful execution of this project will give useful feedback on the simplified protocol's design. 61 | 62 | While conducting this program of work, main challenges would include issues regarding the respect on the lightweight approach of this implementation, as well as maintaining independence by any OS. 63 | 64 | 65 | # Deliverables 66 | 67 | The deliverables would include (sorted by ascending order of delivery date): 68 | 69 | * Documentation about the specifications of a PoC version of IPFS on embedded systems 70 | * Documentation and examples of various use cases 71 | * Implementation of the simplified IPFS (in the form of a C++ library) 72 | * Research results of effect on embedded system's resources 73 | * Minimalistic example of the library's usage by 2 or more systems 74 | * List of new features and optimizations to consider for a future version 75 | * Interoperability & integration with existing IPFS research results 76 | 77 | 78 | # Development Roadmap 79 | 80 | 81 | 82 | The following table describes the main checkpoints of this R&D procedure. 83 | 84 | | Milestone | Details | Hours | Assignees | Funding | 85 | | :----------------------------------------------------------: | :----------------------------------------------------------: | :---: | :------------------------: | :-----: | 86 | | Complete investigation of solution's approach | Full details on what the solution serves to the embedded systems. | 40 | `GeorgeTsagk` & `surligas` | 1400€ | 87 | | Complete research around application's feature set | Documentation regarding the features that the library in its final form can support. | 40 | `GeorgeTsagk` | 1400€ | 88 | | Complete Library Architecture | Layout of the library and its components, including documentation about its lifecycle. | 40 | `GeorgeTsagk` & `surligas` | 1400€ | 89 | | Complete Software Design | Definition of the library's components & functions. Definition of the end user interface. | 40 | `GeorgeTsagk` | 1400€ | 90 | | Implementation of PoC | Basic functional implementation of the library with a sub-set of features present. | 240 | `GeorgeTsagk` | 8400€ | 91 | | Functional example on systems | Utilize the library by a network of systems, applying the IPFS over a common channel| 120 | `GeorgeTsagk` | 4200€ | 92 | | Investigation about level of interoperation with existing IPFS | Report of compatibility with IPFS & interoperability with existing implementations | 60 | `GeorgeTsagk` & `surligas` | 2100€ | 93 | 94 | 95 | 96 | #### Total Budget Requested: 97 | 98 | The full completion of the upper roadmap would sum up a budget of _**24,000.00 USD**_ 99 | 100 | Expenses would include: 101 | 102 | - Engineers salary 103 | - Administrative overhead 104 | - Equipment procurement 105 | - Lab expenses 106 | 107 | 108 | # Team 109 | 110 | 111 | 112 | * **George Tsagkarelis** - Embedded Engineer - Libre Space Foundation (GitHub: [`GeorgeTsagk`](https://github.com/GeorgeTsagk) , GitLab: [`georgetsag`](https://gitlab.com/georgetsag)) 113 | * **Manolis Surligas** - Systems Architect - Libre Space Foundation (GitLab: [`surligas`](https://gitlab.com/surligas)) 114 | 115 | 116 | # Relevant Experience 117 | 118 | The group of LSF holds a significant amount of experience on embedded systems, showcased by a variety of previous projects. 119 | 120 | [AX5043 Transceiver Driver](https://gitlab.com/librespacefoundation/ax5043-driver) 121 | 122 | [HAB System](https://gitlab.com/librespacefoundation/hab) 123 | 124 | [Qubik](https://gitlab.com/librespacefoundation/qubik) 125 | 126 | [Rocketry Avionics](https://gitlab.com/librespacefoundation/rocketry) 127 | 128 | [UPSat](https://gitlab.com/librespacefoundation/upsat) 129 | 130 | [SatNOGS Rotator Firmware](https://gitlab.com/librespacefoundation/satnogs/satnogs-rotator-firmware) 131 | -------------------------------------------------------------------------------- /open-grants/open-proposal-emergent-reputation.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `Emergent Reputation` 2 | 3 | **Name of Project:** Emergent Reputation 4 | 5 | **Proposer:** `@ckartik` 6 | 7 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** Yes 8 | 9 | # Project Description 10 | 11 | ## Problem Statement 12 | **Cyberspace** can abstractly be seen as a means of information distribution. In a general sense, most applications can be broken down into two key objects: 13 | **Users & Content**. The focus of the current network infrastructure (layers below Application on OSI the Model) 14 | has been **content**, ensuring the content is _Authenticated (Certificates) and holds Integrity (Hashes)_. However, it failed to provide any similar cryptographic provisions for the **Users** creating & consuming this content leading internet engineers to overload this into the Application Layer. 15 | The provisions relevant to Users are _Reputation & Trust_. Because of these being held at the application layer, 16 | monopolistic organizations _(Twitter, Meta)_ have gained **institutionalized control** over these attributes without governance. 17 | 18 | The **monopolistic** nature of these organizations has led them to create suboptimal solutions to _Reputation & Trust_ of users and, they lack any incentive to improve the state of Trust. I purpose that the instability this creates, leaves significant slack left for leveraging the Internet as a large-scale social coordination system. This RFC presents a solution to this problem through the development of a **distributed graph data structure** that mimics single-degree trust relationships held in the physical world for each user. This would help emerge a larger web-of-trust that is highly composable at the application layer of traditional applications. Through the development of IPLD as a basis for distributing a decentralized data structure such as the social graph and the proliferation of wallets & blockchains as a mechanism for providing signing capabilities to browsers, this is the first time that a viable solution could be adopted with low friction has ever been possible. 19 | 20 | There are three key components to the implementation of the solution, for which a working [POC (here)](https://github.com/ckartik/Emergent-Reputation) has been enabled on testnet. 21 | 1. The **edges** of the graph will be stored on IPLD, we will call these attestations. 22 | 2. The **nodes** will be a key to a map stored on a Smart Contract, and will be driven from the wallet account number. 23 | 3. An **engine** will be provided in the library to provide the following functionality: 24 | - Addition of nodes & attestations 25 | - Revocation of attestations 26 | - Graph algorithms for driving proxy determinations of trust (Shortest Path, K-connectedness, etc) 27 | - If possible, we would also like to conduct research into mechanisms for zero-knowledge transfer of trust information. 28 | - Particularly research conducted to judge the usefulness of hyperedges as a method for providing privacy 29 | 30 | 31 | ### What are the benefits of getting this right? 32 | With the right execution, this technology could remove the propensity of Sybil attacks currently seen on Social Media platforms. 33 | It would also lead to community-driven censorship, rather than centralized control of censorship that can be abused. 34 | The technology is inherently composable with other platforms that can build on top of it. 35 | ### What are the risks if you don't get it right? 36 | A failed execution could lead to a fragmented development of trust on Web 3.0. Ensuring the architecture can be built with foresight 37 | in mind is also important. 38 | ### What are the risks that will make executing this project difficult? 39 | Difficult to get inflection point adoption to get value out of network effects 40 | 41 | ## Deliverables 42 | 43 | Please describe in detail what your final deliverable for this project will be. Include a specification of the project and what functionality the software will deliver when it is finished. 44 | 45 | ## Development Roadmap 46 | 47 | 48 | | Milestone | Details | Hours & Expected Completion | Assignees | Funding | 49 | | :----------------------------------------------------------: | :----------------------------------------------------------: | :---: | :------------------------: | :-----: | 50 | | Library Architecture | Look into high-level architecture for the final library. This stage will help in determining access patterns for the core social graph. It will entail usability research. | 80 hours - May 25, 2022 | `ckartik` & `jialin98` | $4000 | 51 | | Composable Library V0 | Convert POC into easily useable npm module architecture. | 40 hours - June 20, 2022 | `ckartik` | $2000 | 52 | | Composable Library V0.1 | Add several graph algorithms for proxy determinations of reputation. | 50 hours - June 28, 2022 | `ckartik` | $2000 | 53 | | Composable Library V1.1 | Deploy contract to Testnet & Provide mechanisms to easily connect.| 40 hours - July 28, 2022 | `ckartik` | $2000 | 54 | | Composable Library V1.2 | Deploy the contract to mainnet, and allow the library to connect to both Testnet & Mainnet. | 50 hours - August 28, 2022 | `ckartik` | $2000 | 55 | | Cryptonomics Research | Complete research around the cryptonomics that would drive meaningful attestations and mechanisms for incentivizing businesses to compensate the graph for usability. Publish this research into the public domain. This has been started and the first prototype is [here](https://github.com/ckartik/reputation-betting) | 150 hours - June 28, 2022 | `ckartik` | $4000 | 56 | | Hypergraph Research for ZK | Hypergraphs are a generalization of a graph where the edges can be of arbitrary cardinality. An edge in a typical graph is restricted to be a subset of two objects from the vertex set. There is intuitively a credible mechanism for providing levels of privacy by turning highly connected regions of this social graph automatically into hyperedges. | 180 hours - July 15, 2022 | `ckartik` & `jialin98`| $8000 | 57 | | Privacy with NimaProtocol - exploration & research | Privacy is crucial to this project to avoid it becoming a social credit system. In effort to do this, we can leverage the nimaprotocol chain. This is a chain that leverages exclusively zk proofs of exeution and correctlness of state transitions. This will help us ensure we can provide some level of validity to signatures without explicitly | 40 hours August 30, 2022 | `ckartik` & `jialin98` | $4000 | 58 | 59 | Total Funding Request: USDC 28,000 60 | # Team 61 | 62 | ## Team Members 63 | 64 | - Kartik Chopra [Linkedin Profile](https://www.linkedin.com/in/mathbiz/) | [Github Profile](https://github.com/ckartik) 65 | - Jialin Li [Github Profile](https://github.com/jialinli98) 66 | ## Team Website 67 | - [Link](https://showcase.ethglobal.com/buildquest/tki-trust-key-infrastructure-er66f) to ETHGlobal showcase. 68 | 69 | ## Relevant Experience 70 | - Kartik has a junior background in Applied Cryptography & Network engineering, Kartik currently works at FinTech as a backend engineer, researching cryptocurrencies & the De-fi space. Kartik previously worked: 71 | - As a Programmer for the Canadian Military 72 | - A Network Security Developer at [ISARA Corporation](https://www.isara.com/) with a focus on Network Cryptography & authentication systems like PKI. 73 | - Has an academic background in Computer Science from the University of Waterloo with a focus on Network Security & Cryptography 74 | 75 | - Jialin has a Master of Computer Science with a focus on Zero-Knowledge and Cryptography from the University of California, Berkeley 76 | 77 | ## Team code repositories 78 | - Here are some of Kartik's Repositories: 79 | - [Emergent Reputation POC](https://github.com/ckartik/Emergent-Reputation) built with @jialinli98 80 | - [A system for tracking CIDs to implement versioning on IPFS](https://github.com/DougAnderson444/HydroFile) 81 | - [Enterprise NFT platform](https://showcase.ethglobal.com/roadtoweb3/nft-bridge) 82 | - [Emergent Reputation POC 2.0](https://github.com/ckartik/reputation-betting) with added crypto-economic incentives and games 83 | 84 | Thank you to @TheDiscordian for assistance & guidance. -------------------------------------------------------------------------------- /open-grants/open-proposal-memex+ipfs+filecoin+textile.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `Memex + IPFS/Filecoin + Textile` 2 | 3 | **Name of Project: `Memex + IPFS/Filecoin + Textile`** 4 | 5 | **Proposer:** @blackforestboi @shishkabab @andrewxhill 6 | 7 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** 8 | Yes 9 | 10 | **Potentially interesting for** 11 | - Protocol Labs 12 | - IPFS 13 | - Filecoin 14 | 15 | # Project Description 16 | 17 | ### Problems: 18 | 19 | 1. WorldBrain's [Memex](https://getmemex.com) is a browser extension for full-text history search, annotations and web archiving. This data is valuable to store on IPFS or Filecoin, but an integration is missing. What can be shared: 20 | - Collections (Curations of websites, annotations and (soon) web archives) 21 | - Annotations 22 | - Tagged pages 23 | - Bookmarks 24 | 25 | 2. For app developers there are frictions in experimenting with IPFS because the entire architecture needs to be built on top of it, or suitable abstraction layers need to be considered from the start. 26 | 27 | ### Solutions 28 | 29 | 1. At WorldBrain we developed StorexHub, [an offline-first Zapier](https://medium.com/@WorldBrain/storexhub-an-offline-first-open-source-zapier-f8841810fd9c). It's original purpose is to enable developers/users to integrate Memex with any app or technology flexibly. However it also allows to connect any app with each other and has a database abstraction layer allowing for flexible usage of database technologies and transport protocols like IPFS. 30 | Adding a IPFS/Filecoin plugin gives users the ability to selectively store their data on IPFS/Filecoin 31 | 32 | Example use case: 33 | A user curates a list of articles, annotations and web archives with the most useful articles about the COVID crisis. They set up the IPFS integration to automatically sync this collection, and also everything that is tagged with "IPFS". 34 | 35 | Developers can also experiment more flexibly with IPFS since they can start with more traditional databases and then gradually migrate to IPFS without rewriting their application logic or just use IPFS for some of their functionality. A gradual decentralisation- and infrastructure migration process becomes possible. 36 | As an example: Memex's (or other apps) sharing functionality can be done with IPFS/Filecoin, while the rest of the system uses the browser internal database. 37 | Migrating Memex entire application logic from IndexedDB (browser extension) to TypeORM (mobile) took 1 day. 38 | 39 | 40 | ## Value 41 | - What are the benefits to getting this right? 42 | Having an IPFS/Filecoin integration would lead to **increased adoption among developers** and **knowledge professionals**. Both are critical audiences to further IPFS's mission statement to *preserve and grow humanity’s knowledge* Memex can provide that because its main users are developers, (investigative) journalists, 2nd Brainers and overall knowledge workers. 43 | It would also make important bits of knowledge available on the network, like (parts) of browsing histories, bookmarks, annotations, curated lists, tagged content & (soon) web archives. 44 | Through StorexHub, a more risk free experimentation with IPFS/Filecoin may lead to higher adoption down the line. 45 | 46 | 47 | - What are the risks if you don't get it right? 48 | - Important knowledge will have one way less for being distributed 49 | - IPFS/Filecoin will not be able to tap into the community of a mainstream user product 50 | - Less adoption potential for IPFS/Filecoin 51 | 52 | - What are the risks that will make executing on this project difficult? 53 | 54 | Nothing major we can think of. The only thing is that we are working with Textile.io's stack for the first time. 55 | With Andrew we have the right advisors on board to make the integration smooth. 56 | 57 | 58 | ## Deliverables 59 | ### Definition of done 60 | - There is a StorexHub Plugin for IPFS/Filecoin powered by Textile's Threads that enables developers and users to store Memex data on IPFS. 61 | - There is a database operations abstraction layer that allows any app to use Textile/IPFS/Filecoin APIs to store data 62 | - There is a Developer & User focused documentation on how to setup the IPFS/Filecoin integration. 63 | 64 | ## Development Roadmap 65 | 66 | **Milestone 1:** 67 | Implemented IPFS/Filecoin plugin for StorexHub with Textile's Threads 68 | 69 | Lead: Vincent den Boer 70 | Advisor: Andrew Hill 71 | Time: 2 days á 600€/day = 1200€ 72 | 73 | **Milestone 2:** 74 | Added database abstraction to enable any app connected to StorexHub to use the IPFS integration. 75 | 76 | Lead: Vincent den Boer 77 | Time: 2 days á 600€/day = 1200 78 | 79 | **Milestone 3:** 80 | Written documentation for developers and users on how to use IPFS integration 81 | 82 | Lead: Oliver Sauter 83 | Advisor: Vincent den Boer 84 | Time: 1 day á 600€/day = 600 85 | 86 | 87 | ## Total Budget Requested 88 | 89 | 3000€ 90 | 91 | 92 | ## Maintenance and Upgrade Plans 93 | 94 | This integration will be kept up-to-date with Textile's Threads latest versions. 95 | The work provides a forkable reference implementation that can be maintained by the community. 96 | 97 | The next step after this proposal is to add an end-user-friendly, Wordpress-like interface to setup, configure and maintain this plugin. This is potentially part of another proposal though. 98 | See for more: https://www.notion.so/worldbrain/StorexHub-Interface-3a6024e9538e404ab4df41771302de3f 99 | 100 | # Team 101 | 102 | ## Team Members 103 | 104 | - Oliver Sauter @blackforestboi 105 | - Vincent den Boer @shishkabab 106 | - Andrew Hill @andrewxhill 107 | 108 | 109 | ## Team Website 110 | 111 | https://getmemex.com 112 | https://textile.io 113 | 114 | ## Relevant Experience 115 | 116 | We're the developers of Memex, StorexHub and Textile and offer all relevant product and technical experience to finish this project in a timely manner. 117 | 118 | 119 | ## Team code repositories 120 | 121 | https://github.com/WorldBrain 122 | https://github.com/textileio 123 | 124 | 125 | -------------------------------------------------------------------------------- /open-grants/open-proposal-nft-game-machine.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `NFT Game Machine` 2 | 3 | **Name of Project:** NFT Game Machine 4 | 5 | **Proposal Category:** `devtools-libraries`, `app-dev` 6 | 7 | **Proposer:** `@kedarkshatriya` 8 | 9 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** Yes (MIT License) 10 | 11 | # Project Description 12 | 13 | ## Problem Statement 14 | Currently, if you see the web2 gaming space, we can see two types of development approaches, 15 | * First is from the indie developers like Wukong Game devs, etc. 16 | * Second is from the big companies with huge budgets like EA, Crafton, Xbox studios, etc. 17 | 18 | We see few problems here, 19 | 1. The first problem is not all indie developers have web3 knowledge or cannot hire web3 developers to build web3 related features in their games (because of the high cost of development) 20 | 2. These big companies put a heavy amount of time and funding to build the NFT logic which essentially is redundant considering the vast numbers of games that we see being built using NFT Logic. 21 | 22 | Using our idea, we plan to build two different things - one is **a generalized API service**, which can handle all sorts of things like NFT Minting, Transfers, Burning, Storing metadata and assets on IPFS storage solutions, and storing scores related to statistical data, etc. 23 | 24 | The second is **a platform** that would give a gateway to different types of indie games just like a play store or an app store. There would be a common player leaderboard system that is tracked across the blockchain. We plan to create a platform for the indie developers who can host their games on it and players could be onboarded on the platform and play these games, bet on multiplayer lobbies which would feature a metaverse like an interactive streaming map or game where they can watch streams and bet on the games while watching. 25 | 26 | The most huge gaming markets in the world are PC, Console, and Mobile gaming. All these developers are creating games on centralized servers. They store data like scores, ranking, maps, etc on their own private servers. As these scores are open to all, these data values could be stored on IPFS to be accessed by everyone all over the world. For Example, data like screenshots of the game you are currently playing, if the user wants to share the screenshot with someone it should be accessible to everyone rather than downloading it they can easily just share the IPFS link of the screenshot to their friends. 27 | 28 | **We want to revolutionize the gaming industry** and provide them with **a one-stop solution** for all the different problems which occur when we convert a **web2 game to web3**. Things like adding NFTs to game assets, storing assets on the IPFS storage, showing scores and other information over the decentralized platform, etc. 29 | 30 | As we have created a prototype - [NFT Game Machine](https://showcase.ethglobal.com/lfgrow/nft-game-machine-qfu59 "NFT Game Machine") in EthGlobal Hackathon demonstrating a future use of our tool. There are many things in web2 based games where IPFS can be of great use, these types of games have their own statistics stored in the centralized server, statistics as the number of players alive, the survival time of each player, winning player, top 3 players leaderboard, etc, and that too for multiple games/matches. This data doesn't need to be kept private. Whatever gamers need nowadays is to have a transparent system of different things like scores, levels, their unique assets. 31 | 32 | In the prototype we have introduced 2 games and converted them to use web3 technology, we have used Tableland to store all the data like scores and levels into the IPFS and used nft.storage and NFTPort storage solutions to store the data like NFT Metadata.json file and image file on the IPFS decentralized storage. We are willing to expand and scale this project in many ways. Recently we have built two separate prototypes with different genres of games, one being a jumper style 3d game ([Crypto Chicken Run](https://devfolio.co/projects/crypto-chicken-run-c1cd "Crypto Chicken Run")) and the other one is a touch based 2d arcade game ([Symbals](https://showcase.ethglobal.com/buildquest/symbals-ewfav "Symbals")). 33 | 34 | Our NFT solution would help Game developers to freely mint NFTs of in-game assets like player characters, skins assets and weapon skins, which would help bring utility in any web2 game for example considering our above jumper style game we added utility to add perks and powers to the characters. Now consider games like FIFA, WWE, Mario, Racing Games, we can add NFT utility for them. 35 | 36 | ## Value 37 | 38 | ### What are the benefits of getting this right? 39 | The major benefit is that we would have a standard API system or a platform which can transition any web2 based game to a web3 based game. This statement in itself is very powerful because currently there are around a million games in web2 space with an active user base of around a billion players worldwide. Think if these people can enter the blockchain space essentially through different games. This brings mass adoption in the blockchain and in itself to IPFS and Filecoin. 40 | 41 | 42 | ### What are the risks if you dont get it right? 43 | If we dont get adequate funding or grants then it might be difficult to build such a huge robust API service and a potential platform. 44 | 45 | ## Deliverables 46 | 47 | Right now the prototypes we have created are in simple vanilla JS and Dynamic HTML (EJS) as frontend with Express Js as backend. We are planning to develop the frontend with ReactJS from Scratch which is the reason for Hiring Fullstack dev and a react frontend junior developer. 48 | 49 | We are planning to build an API service that would provide gasless NFT magic in any web2 game on Polygon Network. All public data will be stored on IPFS. Web2 developers would need to use our APIs in their game engine to mint through our NFT smart contracts. Players could buy and sell NFTs on our marketplace where each games NFT collection would be different just like the Steam marketplace. API would handle services like: 50 | 51 | 1. Storing metadata 52 | 2. Storing images 53 | 3. In-game Assets 54 | 4. Minting NFTs (ERC721, ERC 1155 - according to the assets used in the game) 55 | 5. Buying, selling, and transfer of NFTs in the marketplace. 56 | 6. Burning of these NFTs to earn perks 57 | 7. API service will provide routes for minting NFTs, transferring NFTs, and enabling a bidding and auction system for a particular NFT. This API will help any game dev creator to fetch and retrieve data regarding the NFTs and load them into the game. 58 | 59 | ## Development Roadmap 60 | 61 | 62 | | Milestone | Details | Duration | Funding | 63 | | :----------------------------------------------------------: | :----------------------------------------------------------: | :---: | :-----: | 64 | | Planning Phase | Planning on building a custom Smart Contract - (Remove NFTPort) which will include 3 smart contracts, one would be a NFT marketplace contract and another two would be ERC721 and ERC1155 smart contracts to handle the NFTs. First Milestone would cover specs docs to be built it would require us around 3 weeks of time. | 3 weeks | $8000 | 65 | | Smart Contract Development V1.0 | Working on the smart contract building ERC721 smart contract and ERC1155 smart contract and deploying on the Polygon Testnet. Plan to start development of Frontend Marketplace. | 3 weeks | $8000 | 66 | | Start Frontend Development | Start on the development of the ReactJS frontend marketplace, Select designs for the marketplace (1 week), Development of the marketplace page. Continue development of the smart contracts. | 3 weeks | $8000 | 67 | | Backend API Development | Start development on backend API Repo, creating routes for different services like minting, transferring, burning the NFTs with Authentication token from the collection’s owner, etc. Backend will be developed on the new and improved NestJs framework in Nodejs. | 3 weeks | $8000 | 68 | | Smart Contract Development V1.1 | Development of backend API services, enabling auction and bidding features, and development of the marketplace smart contract. We will focus on the integration for the next milestone. | 3 weeks | $8000 | 69 | | Beta Integration of Services | Integration of the backend API services with the marketplace frontend. Start deployment of the working build on Testnet and temporary CI/CD pipeline to start QA check for the same. Meanwhile, we would also start the outreach and marketing to different developers/companies who are working on various games and give them beta access. | 3 weeks | $8000 | 70 | | Final Integration and Production Deployment | Last 2 weeks of the development, production beta deployment for QA purpose, deploying the smart contracts on Polygon Mainnet. Run all the QA tests for load and other checks before release on production. | 2 weeks | $4500 | 71 | 72 | 73 | ## Funds Distribution 74 | 75 | Below is the list of people who would be working on the project for the next 5 - 6 months: 76 | 77 | Senior Full Stack developer working full time - $ 4,000 * 5 months = $20,000 78 | 79 | Solidity Developer working part time - $2,000 * 5 months = $10,000 80 | 81 | Fullstack Developer working part time - $2,000 * 5 months = $10,000 82 | 83 | Junior React Frontend developer full time - $1,000 * 5 months = $5,000 84 | 85 | QA full time - $1,000 * 5 months = $5,000 86 | 87 | Marketing/Outreach Manager Part time - $500 * 5 months = $2,500 88 | 89 | ### Total Budget Requested 90 | 91 | The Total Budget Requested is **$52,500** 92 | 93 | # Team 94 | 95 | ## Team Members 96 | 97 | - Kedar Kshatriya [Linkedin Profile](https://www.linkedin.com/in/kedar-kshatriya/) | [Github Profile](https://github.com/kedarkshatriya) 98 | 99 | - Vinay Sudrik [Linkedin Profile](https://www.linkedin.com/in/vinaysudrik/) | [Github Profile](https://github.com/optimus789) 100 | 101 | ## Team Website 102 | - [Link to Live Proof of Concept.](https://nft-game-machine.herokuapp.com/) 103 | 104 | ## Relevant Experience 105 | - Kedar has Smart contract and Dapp Development experience from the last 2 years. 106 | 107 | - Vinay is a Full Stack Developer with 2 years of experience. We are going to further hire people for Front-end development. 108 | 109 | ## Team code repositories 110 | - [Our current codebase.](https://github.com/optimus789/nft-game-machine) -------------------------------------------------------------------------------- /open-grants/open-proposal-open-registry.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `OpenRegistry x IPFS` 2 | 3 | **Name of Project:** OpenRegistry 4 | 5 | **Proposer:** Jasdeep Singh - [Github - jay-dee7](https://github.com/jay-dee7) on behalf of OpenRegistry 6 | 7 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** Yes 8 | We are already building under Apache2.0 License 9 | 10 | # Project Description 11 | 12 | OpenRegistry is a decentralised container registry fully compliant with OCI Distribution Specification. The specification provides similar capabilities as that of the Docker Registry HTTP API V2 protocol and more. 13 | 14 | For the longest time Docker has run DockerHub (their hosted container registry) and it’s been the most popular platform by far. Majority of the people rely on Docker’s Container Registry, even in the Web3 world where every component must be decentralised and the need for centralised platform should be as little as possible. 15 | Here are a few reasons why **THIS** project comes to life: 16 | - Docker Hub is run by a corporate, who’s biggest (but not only) goal is to make profit. 17 | - When DockerHub goes down, it causes a lot of service degradation for it’s peers, we can show the tech industry how resilient and robust OpenRegistry can be, with the support of decentralised and Web3 native protocols like IPFS. 18 | - `DockerHub’s new Rate Limiting` makes if even harder to use DockerHub. (We’ve worked with Fortune500 Clients in the past and we were literally forced to use AWS’ Container Registry). When you're building continuously and your deployment process is frequent, the rate limiting can really be a pain in the neck. 19 | - With OpenRegistry, we want to establish a trust factor among tech communities that it doesn't have to be centralised to build a powerful product like DockerHub. 20 | - Run by the Open Cloud, powered by Open Technologies. We’re planning to add IPFS support soon after the initial launch. 21 | 22 | Currently, OpenRegistry is being built on top of Skynet for the storage backend but the OCI Distribution Spec defines the backend to be pluggable simply by satisfying the `storage.StorageDriver` interface. Now that our MVP is ready, we'd like to add IPFS storage backend to make OpenRegistry more flexible to the demanding world of technologies. 23 | 24 | ### Usage 25 | 26 | **Q.** How difficult it would be to use OpenRegistry as Container Registry of our choice? 27 | **Answer:** OpenRegistry is fully compliant with The OCI Distribution Spec, and we've received the Certification from the Open Containers Initiative Organization as well, check it out on the [Official OCI Conformance Website](https://conformance.opencontainers.org/). This means that your existing workflow would remain exactly how it is. 28 | 29 | ## Value 30 | 31 | Containers are the building blocks of modern infrastructure and distributing them efficiently is a critical part of deploying applications (even more so, at scale). 32 | 33 | We believe that a Container Registry is one of the best use cases for a decentralised storage system like IPFS. OpenRegistry with IPFS has potential to be used by millions of developers everyday, which would roughly translate to Terrabytes of data being transferred daily. This makes it a perfect collaboration/opportunity to highlight the scalability and resiliency of the IPFS Network. 34 | 35 | Developers can use OpenRegistry to share their private code-bases, secrets, and other sensitive information while still being in full control of all the data they share. Knowing it all is protected, and being distributed reliably with a transparent system of decentralised storage, all without the involvement of any centralised entity. 36 | 37 | **- What are the benefits to getting this right?** 38 | If OpenRegistry is a success (which we're gonna make sure it is), Web3 will have it's own Container Registry, fully compliant with OCI Distribution Conformance Spec, which literally means you can do anything that you would do on DockerHub, GHCR, etc. Owned and operated completely by the Open Source Web3 Communities. 39 | 40 | **- What are the risks if you don't get it right?** 41 | We hope we never come to this but however if in some alternate reality this does happen, we'll always be listening to our users and the communities we participate in and try to rectify any issues or obstacles that might be in the way OpenRegistry vision. 42 | 43 | **- What are the risks that will make executing on this project difficult?** 44 | The biggest risk so far is that we do not have enough funds to run and manage OpenRegistry. Along with that, we also want to hire another engineer to work with us. We want to start incentivising developers that build OpenRegistry so that they don't have to think about full-time job or contracting somewhere to make ends meet. 45 | We want to pursue this dream aggressively 46 | 47 | ## Deliverables 48 | 49 | 1. OCI Distribution Specification compliant backend and get the certification from them. 50 | 2. Web interface with search auto-completion, GitHub OAuth2.0 support, and 3 blogs. 51 | 3. Collaboration with IPFS and Filebase. WebAuthN, Vulnerability scanning for container images, PASETO and SPIFEE based access management. 52 | 53 | ## Development Roadmap 54 | 55 | ### Milestone 1 - Q4 2021 56 | 57 | > After successful completion of this **Milestone**, a user should be able to: Push, Pull, Search and Manage their container images on OpenRegistry. Any container engines (like nerdctl or docker cli) should also be able to use HTTP Basic and JWT Authentication. A basic form of Web Interface will also be ready to use. In addition to this, We should have received Certification from Open Containers Initiative Organization for implementing Distribution Spec. 58 | 59 | |OCI Distribution Spec Implementation|AuthN & AuthZ|APIs, Web Interface, & Integration| 60 | |----|----|---| 61 | |✅ Push Container Images|✅ Implement Registry Spec Compliant Authentication Protocol|✅ Catalog API for Listing Container Images| 62 | |✅ Push Container Manifests|✅ Server Side Network and bandwidth Optimization|✅ System Wide Logging| 63 | |✅ Pull Container Images |✅ Migrate KV Store to PostgreSQL|✅ List Tags API| 64 | |✅ Pull Container Image Manifests|✅ JWT Support|✅ Basic Web Interface| 65 | |✅ Content Discovery & Management|✅ HTTPS - Basic Authentication|✅ Release Closed Beta Program| 66 | |✅ OCI Conformance Certification||| 67 | 68 | **Engineers Working on this:** Gunjan Valecha & Jasdeep Singh
69 | **Funding Requested: $30k USD** 70 | 71 | ### Milestone 2 - Q1 2022 72 | 73 | > After successful completion of this **Milestone**, we'll have a brand new designs implemented. A state-of-the-art Web Interface will be released along with personalised blog posts, Login With Github, Autocompletion for searching container images and an Up-time status page to monitor OpenRegistry's up-time. 74 | 75 | |Web App Development|Workflows & Developer Experience|New Release and the way forward| 76 | |----------|--------|----------| 77 | |✅ Design Logo & Web Interface |✅ Logs & Metrics collection \w FluentBit and Grafana|◻︎ Cut a new release| 78 | |✅ New Home Page for OpenRegistry|✅ Uptime Status Page|✅ Integrate Email Service with OpenRegistry| 79 | |✅ OpenRegistry Dashboard View|✅ OAuth2.0 /w GitHub|✅ Enable Sign In & Sign up on Web Interface| 80 | |✅ Settings & Profile Page|✅ New Blogs about OpenRegistry & collaborations|◻︎ Load & Performance Testing| 81 | |✅ Search With Auto-complete|✅ Documentations|◻︎ Collect Feedback| 82 | 83 | **Engineers Working on this:** Gunjan Valecha & Jasdeep Singh
84 | **Funding Requested: $30k USD** 85 | 86 | ### Milestone 3 - Q2 2022 87 | 88 | > Upon successful completion of this **Milestone**, OpenRegistry will have multiple storage backends, thorough collaborations with IPFS and Filebase. These backends will be configurable by the end user. We'll also build an Open-Source TUS Protocol Client Library, which helps with uploading large files efficiently to servers that support TUS. We're looking forward to bring WebAuthN to OpenRegistry as it will eliminate any need to collect PII. Along with this, we're also expecting Vulnerability scanning, Bring your own encryption keys and more. 89 | 90 | |Web3 integrations|New Features & Enhancements|Ecosystem Building| 91 | |------|--------|-------| 92 | |◻︎ TUS Protocol Client Implementation|◻︎ Vulnerability Scanning for Container Images|◻︎ SPIFEE based resource access| 93 | |◻︎ Collaborate with IPFS|◻︎ WebAuthN - Passwordless Access|◻︎ Run Freemium for 2022| 94 | |◻︎ Collaboration With Filebase|◻︎ Bring your own Skynet Key (BYOSK)|◻︎ Contribute back to Skynet, IPFS, and Akash Network| 95 | 96 | **Engineers Working on this:** Gunjan Valecha & Jasdeep Singh
97 | **Funding Requested: $30k USD** 98 | 99 | ### Milestone 4 - Q3 2022 100 | 101 | |OpenRegistry Core|Enhancements|Web App| 102 | |------|------|---------| 103 | |◻︎ Organization Mode|◻︎ gRPC APIs for OCI Distribution Spec APIs|◻︎ Cut a new release| 104 | |◻︎ Container Image Analytics|◻︎ Platform Agnostic Security Tokens (PASETO)|◻︎ Design Origin Illustrations| 105 | |◻︎ Private & Encrypted Container Images|◻︎ OCI Distrbution Spec Extensions support|◻︎ Animations for Web App and Blob| 106 | |◻︎ P2P Container Image Distribution||| 107 | 108 | **Engineers Working on this:** Gunjan Valecha & Jasdeep Singh
109 | **Funding Requested: $30k USD** 110 | 111 | ## Total Budget Requested 112 | 113 | Sum up the total requested budget across all milestones, and include that figure here. Also, please include a budget breakdown to specify how you are planning to spend these funds. 114 | 115 | | Milestone | Developer Hours | Total | 116 | |-------------|-----------------|-------| 117 | | Milestone 1 | 420 | $30,000 USD | 118 | | Milestone 2 | 500 | $30,000 USD | 119 | | Milestone 3 | 500 | $30,000 USD | 120 | | Milestone 4 | 420 | $30,000 USD | 121 | | **Total** | **1840** |**$120,000 USD** | 122 | 123 | ## Maintenance and Upgrade Plans 124 | 125 | We've already laid out our plan for next 2 quarters but it doesn't end there. We want to build a complete ecosystem around OpenRegistry and add a bunch of complimentary features and products. We're currently running a Open Beta Program to join and check OpenRegistry out. 126 | 127 | We're soon to release OpenRegistry for Public use and once OpenRegistry is stable enough, We'd like to shift focus towards building a Desktop App along the lines of Docker Desktop and Rancher Desktop. With this product, we'll be able to make real use-case of P2P container image distribution, with fine grained ACLs. 128 | 129 | # Team 130 | 131 | ## Team Members 132 | 133 | - Jasdeep Singh - [Github](https://github.com/jay-dee7) - [Twitter](https://twitter.com/_jsdp) 134 | - Gunjan Valecha - [Github](https://github.com/guacamole) - [Twitter](https://twitter.com/guacaemole) 135 | 136 | ## Team Website 137 | 138 | https://app.openregistry.dev/about 139 | 140 | ## Relevant Experience 141 | 142 | Our team is small but versatile. We have combined experience in multiple technologies like Blockchain, Backends, UI/UX, DevOps and more. We're passionate about Web3 and want to make a dent in the large world of corporate data stealing. 143 | 144 | - I (Jasdeep) have over 5 years of experience in Go, SvelteKit, TailwindCSS, TypeSript, Blockchain, DevOps and Cloud Technologies. 145 | I've also done couple of bounties with Protocol Labs in the past, noticeably **CLI Tutor Mode** in the IPFS WebUI [Link](https://github.com/ipfs/ipfs-webui/pull/1572). Along with that, I've donated an OpenSource Library to ENSDomains, it's a lightweight JavaScript Lib, which is used for encoding/decoding different blockchain addresses (https://www.npmjs.com/package/crypto-addr-codec) 146 | 147 | - Gunjan Valecha (Guacamole) has more than 6 years of Enterprise Networking, UI/UX, SvelteKit, TailwindCSS, Backends with Go and PostgreSQL. Along with that, she has a natural talent for Designing beautiful Animations, Illustrations, and merchandise. 148 | She's has contributed to Hashicorpt Vault, been a member of Community Awards Board at Akash Network (which works towards funding projects that build on and help Akash Network grow) and is part of their Akash Insiders Program. She's quit her job to help build OpenRegistry full-time. 149 | 150 | ## Team code repositories 151 | 152 | - OpenRegistry - https://github.com/containerish/OpenRegistry.git 153 | - Parachute (current Web UI) - https://github.com/containerish/parachute-ui.git 154 | - OpenRegistry Web (New Web Interface) - https://github.com/containerish/openregistry-web.git 155 | 156 | # Additional Information 157 | 158 | We're part of Akash Community Awards Board (CAB). Following are the details of grant funds we have received so far: 159 | 160 | | Organization | Amount | Received | 161 | | ---- |-----------------------------------| -- | 162 | | Akash Network - Open Cloud Hackathon Winners | $10k USD in AKT | ✅ | 163 | | Akash Network - CAB Funding Round 1 | $1k USD in AKT | ✅ | 164 | | Akash Network - CAB Funding Round 2 | $10k USD in AKT | ✅ | 165 | | Akash Network - CAB Funding Round 3 | $35,000 USD (Received 72,454 AKT) | ✅ | 166 | 167 | -------------------------------------------------------------------------------- /open-grants/rn-remote-ipfs.md: -------------------------------------------------------------------------------- 1 | # React Native support for the js-ipfs-http-client 2 | 3 | **Proposer**: [schwartz10](https://github.com/schwartz10), [pcowgill](https://github.com/pcowgill/) 4 | 5 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** yes 6 | 7 | # Project Description 8 | 9 | The js-ipfs-http-client does not work out of the box in React Native. This is a problem because it’s difficult to create a native mobile application that interacts with a remote IPFS node. Running a remote node (instead of one in the phone) can be preferable if it consumes less data, battery, and memory, or is faster and more flexible to set up out-of-the-box. 10 | 11 | Phase 0 of this proposal is for up to 1.5 weeks of research to get more visibility around the technical challenges, blockers, and potential solutions for making the js-ipfs-http-client compatible with React Native. Then we’ll submit a spec that outlines our intended solution as a follow-on deliverable. 12 | 13 | # Value 14 | 15 | We gauged community interest in this initiative by filing a [Gitcoin Grant](https://gitcoin.co/grants/364/react-native-support-for-ipfs) and conducting developer interviews. In two weeks, our Gitcoin Grant received \$410 from 14 different contributors. We spoke to 5 teams developing mobile wallets in the Ethereum ecosystem - each would benefit from the js-ipfs-http-client working in React Native. In the 3Box ecosystem alone, 5 active projects requested this functionality in the past few weeks. 16 | 17 | Alternative starting points exist for running an IPFS node inside the phone. Textile worked on [grpc-ipfs-lite](https://github.com/textileio/grpc-ipfs-lite), which could be extended for use in React Native. There’s also [gomobile-ipfs](https://github.com/ipfs-shipyard/gomobile-ipfs), but it’s still experimental, and it’s unclear what its development and stability will be in the future. Involving other languages like Go, Swift, Kotlin, etc. adds complexity for a developer when initially configuring the project and when debugging, so it’s best to avoid unless absolutely necessary. 18 | 19 | Both these alternatives are still difficult to get working in React Native and would require the developer to [eject](https://docs.expo.io/versions/latest/expokit/eject/) from React Native Expo. This could make developing with IPFS less accessible to junior engineers interested in experimenting with IPFS in native mobile apps. These alternative approaches might also not be compatible with packages like 3Box or OrbitDB. 20 | 21 | ## Deliverables 22 | 23 | A spec that outlines the optimal solution(s) to the problem. We plan to use this spec to create follow-on deliverables for this Open Grant Proposal. 24 | 25 | ## Development Roadmap 26 | 27 | * Investigation of multipart/form-data issues that the js-ipfs-http-client lib throws errors when first configured in a React Native env. We need to figure out if this problem can/should be handled natively or in JavaScript. 28 | * Documenting proper babel config for async iterator support 29 | * Documenting work-arounds for fetch to support streams in React Native (Open PR against js-ipfs-http-client and `@stardazed/streams-polyfill`) 30 | * Investigation of viability of `rn-fetch-blob` as an alternative fetch implementation 31 | * Investigation of any other newer browser APIs used in js-ipfs-http-client that are not supported in React Native. 32 | * Documenting which of the outstanding issues can be mitigated when the IPFS core team moves away from their use of ky and ky-universal as their fetch abstraction 33 | * Investigation of any networking or libp2p issues, including pub-sub. 34 | 35 | ## Total Budget Requested 36 | 37 | Up to \$8,775 for 1.5 weeks of work, starting Wednesday February 5th to Friday February 14th, 2020. If the investigation is finished early, a prorated amount will be paid. 38 | 39 | ## Maintenance and Upgrade Plans 40 | 41 | Our plan is to PR the documentation/investigation outputs to an issue in ipfs/notes or ipfs/js-ipfs-http-client for others to learn from. 42 | 43 | ## Team Members 44 | 45 | Open Work Labs (Jonathan Schwartz)
46 | [Website](https://www.openworklabs.com/)
47 | [GitHub](https://github.com/openworklabs/) 48 | 49 | Paul Cowgill
50 | [Website](https://cowgill.io/)
51 | [GitHub](https://github.com/pcowgill/) 52 | 53 | ## Relevant experience 54 | 55 | We’ve been working on this exact problem with Hugo Dias from IPFS core for about 3 weeks already now. We have a very in-depth understanding of the challenges ahead. 56 | 57 | ## Team code repositories 58 | 59 | https://github.com/openworklabs/react-native-ipfs-http-client/ 60 | -------------------------------------------------------------------------------- /rfps/README.md: -------------------------------------------------------------------------------- 1 | # RFP 2 | 3 | ## About 4 | RFPs (Requests For Proposals) are detailed descriptions of a technical problem seeking proposed solutions, the best of which will be funded for execution. This could be a protocol level improvement, a novel algorithm, a developer- or user-facing tool, and so on. 5 | 6 | A successful RFP grant requires a detailed problem statement with well-defined acceptance criteria and budget, as well as a Proposal describing the implementation plan and clear deliverables. 7 | 8 | If you're interested in a smaller grant with simpler application and reporting requirements, take a look at the [microgrants](../MICROGRANTS.md). 9 | 10 | If you have a detailed proposal for a project that will broadly benefit the IPFS community that doesn't answer a particular RFP, you may want to try an [open grant proposal](../open-grants). 11 | 12 | ## How To Propose 13 | ### Intended Audience 14 | You're a developer or development team that can complete the work described in an RFP within the budget and up to spec. 15 | 16 | ### How To 17 | 1. Select an open RFP from [this list](.). 18 | 2. [Open an issue](https://github.com/protocol/ipfs-grants/issues/new?assignees=&labels=&template=rfp-proposal.md&title=RFP+Proposal%3A+%3CYour+Project+Title%3E) with your proposal, following the template. Be sure to tag the original poster of the RFP to let them know about your proposal. 19 | 20 | ## How To Create an RFP 21 | ### Intended Audience 22 | You're an organization looking to solicit technical contributions for a well-defined project. You have the necessary technical or product expertise to specify the work, evaluate proposals, and determine the correctness of the result. 23 | 24 | ### How to 25 | 1. Open a PR based on the [RFP template](rfp-template.md) (don't forget to change the file name). Tag your RFP appropriately to help applicants find projects that fit their skills and interests. 26 | 2. Watch for new issues referencing your RFP 27 | 3. Evaluate and select the proposal best suited to your requirements 28 | 4. Once you've affirmatively selected a proposal, we will close any other issues and mark your RFP as "In Progress" 29 | 30 | Remember: writing a high quality RFP is a lot of work. It's your responsibility to offer detailed instructions and acceptance criteria to the applicants, review proposals in a timely manner, and evaluate the finished work. RFPs that remain idle for 3 months will be archived. 31 | 32 | ## How To Help Fund an RFP 33 | ### Intended Audience 34 | You're interested in accelerating the development of a specific feature, or perhaps broadly supporting IPFS work as a foundation or private donor. 35 | 36 | ### How To 37 | Simply add your additional pledge to the document describing the RFP (under "Support and Funding"), or add it in comments of the PR if it is not yet merged. 38 | 39 | It may also be a good idea to add invoicing/payment information for your organization to [FUNDING](../FUNDING.md) to make the disbursement process easier. 40 | 41 | ## Note 42 | RFPs are just one aspect of the IPFS project's overall grant program. Check out the top level of the [IPFS Grant Platform repo](https://github.com/ipfs/devgrants) to see the big picture. 43 | -------------------------------------------------------------------------------- /rfps/handshake-fallback-resolver.md: -------------------------------------------------------------------------------- 1 | # RFP: `Implement Handshake "fallback" resolver` 2 | 3 | **Issuer:** `@johnnywu-namebase` 4 | 5 | ## Project Description 6 | 7 | The distributed web community is exploring ways to remove the complexity of addressing IPFS and other content-addressed protocols with distribtued name spaces like Handshake, and one way is by implementing a fallback resolver like the one proposed below for Handshake. 8 | 9 | For context, Handshake is a naming project focused on decentralizing the root zone (to decentralize control of domain names from ICANN) with the goal of replacing Certificate Authorities (to rehaul Internet security and privacy). 10 | 11 | Given the goals of: 12 | - IPFS doesn’t want to choose winners 13 | - IPFS wants to decouple from ICANN and support non-ICANN namespaces 14 | - IPFS wants to avoid introducing privacy and security risks in implicit defaults 15 | - IPFS wants the alternative namespaces to be DNS compatible. Preferably they can use DoH endpoints 16 | 17 | IPFS can accomplish these goals while supporting non-ICANN namespaces by adding a “fallback” resolver option to DNS.Resolvers that points to a list of DoH endpoints. (See `Detailed Requirements & Constraints` below for more info) 18 | 19 | ## Value 20 | 21 | By implementing a fallback resolver to distributed namespaces like Handshake, IPFS makes the decentralized web massively more accessible to anyone already using an IPFS-compatible application, which in turn accelerates the adoption of a fully distributed web. 22 | 23 | ## Deliverables 24 | 25 | A merged PR for implementing a fallback resolver that successfully resolves Handshake names like http://namebase/. 26 | 27 | ## Recommended Team 28 | 29 | Any developer comfortable with everything listed in the below `Resources` section. 30 | 31 | ## Detailed Requirements & Constraints 32 | 33 | Each DoH endpoint can point to a different decentralized naming system. When a query fails to resolve through the “.” resolver, query all of the “fallback” resolvers. If one of the resolvers has a match without conflict, then proceed with fetching the IPFS file. Otherwise if there’s a conflict, return an error code (ie HTTP 409 conflict). 34 | 35 | The “fallback” setting can be set by default to [“https://query.hdns.io/dns-query”] which is HDNS.io’s Handshake DoH resolver (note that HDNS.io doesn’t log or store IP addresses or any other personal information, as specified in the privacy policy linked on the website). Polkadomain.org, butterflyprotocol.io, and other decentralized naming systems which issue TLDs can be added as well when they create their own DoH resolvers and issue a PR. 36 | 37 | Before starting implementation, one should post the proposed design as an issue in this repository (how config would look like, what implicit default would be, and what needs to be changed to make that possible). Please ping @lidel and myself (@johnnywu-namebase) on the issue to ensure the proposed design is included during IPFS's weekly triage session. By getting confirmation on design and config bikeshed first, we avoid investing time into approach that can't be accepted into the main branch and have more confidence moving forward. 38 | 39 | ## Milestones & Funding 40 | 41 | **Total Funding Amount:** 20,000 HNS ($5,000+) 42 | 43 | **Milestones:** 44 | 45 | | # | Description | Amount | 46 | |---|---|---| 47 | | 1 | Propose the best design as specified in `Detailed Requirements & Constraints` | 2,000 HNS | 48 | | 2 | Completion of PR (is merged and live) | 18,000 HNS | 49 | 50 | ## Acceptance Criteria 51 | 52 | Handshake names like http://namebase/ should resolve in IPFS-compatible applications like the IPFS Companion extension, Brave browser, and Opera browser, etc. 53 | 54 | ## Resources 55 | 56 | - go-ipfs 0.9 was not released yet, but the code is in master branch and the docs for DNS config are at: https://github.com/ipfs/go-ipfs/blob/master/docs/config.md#dns 57 | - "Ongoing work" in https://github.com/ipfs/go-ipfs/issues/6532 is a good list of code paths that were touched while adding the DNS support, so reading linked PRs there should be enough to build mental model of how DNS in go-ipfs works now. 58 | - Additional tldr: config is in go-ipfs-config, generic DNS logic is in go-multiaddr-dns, and the defaults hardcoded in go-ipfs are in 59 | https://github.com/ipfs/go-ipfs/blob/3b254a631f57d6290ab8179c0cacd72f24ca7dea/core/node/dns.go#L14-L16 60 | - Namebase developer docs: https://docs.namebase.io/ 61 | - Handshake developer docs: https://hsd-dev.org/ 62 | 63 | ## Support and Funding 64 | 65 | Namebase.io is funding this project and our engineers are readily available for assistance with HDNS.io and Handshake resolvers as well. 66 | -------------------------------------------------------------------------------- /rfps/rfp-template.md: -------------------------------------------------------------------------------- 1 | To create an RFP, please open a PR based on this template against this repo. Title your file `rfp-title.md`, replacing `title` with the name of your project. 2 | 3 | # RFP: `Title` 4 | 5 | **Issuer:** `replace with your GitHub username` 6 | 7 | ## Project Description 8 | 9 | Please fill in details about what you're trying to build. What is the purpose/context? What are the high-level requirements? 10 | 11 | This section should be 2-3 paragraphs long. 12 | 13 | ## Value 14 | 15 | Please describe why the work that will come out of this RFP is valuable for the IPFS ecosystem. 16 | 17 | ## Deliverables 18 | 19 | What are you expecting the proposer to deliver at the completion of this project? 20 | 21 | ## Recommended Team 22 | 23 | List the skills and experience you are looking for. Teams with this background might be a better fit for this project. 24 | 25 | ## Detailed Requirements & Constraints 26 | 27 | You can use this section to detail requirements that the deliverables must include. 28 | 29 | Also include any relevant constraints that the implementer should be aware of before beginning this project. 30 | 31 | ## Milestones & Funding 32 | 33 | **Total Funding Amount:** List the total proposed funding amount (currently in USD, eventually can be a distribution between USD/FIL) 34 | 35 | **Milestones:** Make sure that the values in the Funding column add up to the Total Funding Amount listed above. 36 | 37 | | Milestone No. | Milestone Description | Funding | Estimated Timeframe | 38 | | --- | --- | --- | --- | 39 | | 1 | Example milestone | $X | Y weeks | 40 | | 2 | Example milestone | $X | Y weeks | 41 | | 3 | Example milestone | $X | Y weeks | 42 | 43 | ## Acceptance Criteria 44 | 45 | What are the acceptance criteria for each milestone and for the final deliverables? These should be as objective as possible. They will be used to determine whether or not a grantee will receive payment for work completed for a milestone. 46 | 47 | ## Resources 48 | 49 | Link any resources that might be helpful for an implementer who is working on this project. 50 | 51 | ## Support and Funding 52 | 53 | Who is backing this project? How will they pay the implementers? If you have not already added your information to [FUNDING](../FUNDING.md), you can do so now and link it here. Include a legal entity name if possible. 54 | 55 | Any other organizations that choose to add their support to this RFP will do so in this section. 56 | -------------------------------------------------------------------------------- /targeted-grants/IPFS-Browser-Protocol-Compliance-Suite.md: -------------------------------------------------------------------------------- 1 | # Targeted Grant: IPFS Browser Protocol Compliance Suite 2 | 3 | 4 | **Issuer:** @lidel 5 | **Recipient:** @RangerMauve 6 | 7 | ## Project Description 8 | 9 | 12 | 13 | **This project’s goal is to figure out what browser features require IPFS addressing support and to create a comprehensible test page that browser vendors can verify support through.** 14 | 15 | IPFS Companion browser extension has been making progress on getting IPFS support into web browsers. 16 | 17 | However, the definition of "support" is still ambiguous and it would be good to give browser vendors a definitive test suite to ensure they have compatibility with each other. 18 | 19 | There already exist [some tests for IPFS protocol handler](https://ipfs.github.io/in-web-browsers/ipfs-protocol-handler-support-tests.html), but they are not extensive and have gaps such as iframes, different types of XHR requests, and JS modules. Part of this work will be to find the gaps and update the tests to cover everything that's needed for modern web development. 20 | 21 | ## Value 22 | 23 | 24 | 25 | There are some features of the protocol that we would like browsers to support which cannot currently be supported using the `registerProtocolHandler` API on the web or via IPFS Companion. 26 | 27 | Defining the needed functionality and expected behaviors will help browser vendors to standardize and implement the needed APIs, and reduce the friction between `https://` and `ipfs://` `ipns://` websites and dapps. A comprehensible test suite will make it easier for browser vendor engineers to guarantee that they are implementing protocol support accurately and that we have compatibility between different browsers. 28 | 29 | IPFS team will use the same test suite to prototype new behaviors internally, namely we want to use it for exploring the concept of Writable Gateways being mapped to URI schemes. 30 | 31 | ## Deliverables 32 | 33 | 34 | 35 | - Description of protocol handler functions needed from browser vendors (iframe, script tag, image, etc) (20 hours) 36 | - Extend [Protocol Handler Support Tests](https://ipfs.github.io/in-web-browsers/ipfs-protocol-handler-support-tests.html) to contain tests for all the needed features and make it easy to run them in a way that produces a shareable "compliance report" (40) 37 | - Create additional set of Protocol Handler Support Tests for handling POST/PUT/DELETE messages for `ipfs://` and `ipns://` (for internal use by IPFS team - could be a commented out section, or a separate instance) (20) 38 | - Show the tests as passing in an experimental dweb browser as a proof of concept that could be presented to browser vendors in addition to the dry spec and tests (20) 39 | 40 | ## Team 41 | 42 | 43 | 44 | - [@RangerMauve](https://github.com/RangerMauve) - (Grant recipient) Active member of the dweb community. 45 | Done a grant with Protocol Labs before. 46 | Done multiple grants with DAT and are key member in team that set up the DAT Foundation. 47 | 48 | - @lidel - (Protocol Labs) Technical advisor 49 | 50 | ## Detailed Requirements & Constraints 51 | 54 | 55 | Description: This description should ennumerate all the ways that a browser might load data from IPFS in a markdown document. As well, there will be research done to see how other browser compliance tests are presented so that it can inform the test design. This document will be used to make the test 56 | 57 | Tests: This will be an HTML document which will contain individual "tests" which will either pass or fail. The tests will be checking the browser's ability to interact with `ipfs://` URLs according to the spec in Milestone 1. Once the tests have run, there will be a summary of the browser's compliance. These tests will be uploaded to IPFS and pinned on a pinning service in addition to being abailable in a GitHub repository. 58 | 59 | POST/PUT: This will be a second HTML document which will use the same format for tests and complaince as in Milestone 2, but it will focus on the ability to use `POST`/`PUT`/`DELETE` methods which are currently not strongly defined. This will also be uploaded to a GitHub repository and pinned on IPFS. 60 | 61 | Passing in Experimental Browser: This will consist on patches to the Agregore browser which has support for `IPFS` via Electron's protocol handler API. The patches will bring Agregore to the point of complying with the test scenarios so that other browser vendors can see an example of passing compliance. 62 | 63 | ## Milestones & Funding 64 | 65 | **Total Funding Amount:** $6500 66 | 67 | **Milestones:** (working 10-20 hours a week) 68 | 69 | | Milestone No. | Milestone Description | Funding | Estimated Timeframe | 70 | | --- | --- | --- | --- | 71 | | 1 | Research/Description | $1300 | ~20h | 72 | | 2 | Test Page with Compliance Report | $2600 | ~40h | 73 | | 3 | Second page with POST/PUT | $1300 | ~20h | 74 | | 4 | Passing compliance in experimental browser | $1300 | ~20h | 75 | 76 | ## Acceptance Criteria 77 | 78 | 79 | 80 | 1. Description of URI behavior in HTML documents includes a, img, audio, video, link, script and iframe tags; XHR/fetch requests made from JS running on a `ipfs://` page. 81 | 2. Test page for behaviors listed in (2) is a static HTML+JS that can be loaded in regular browser (Firefox, Chrome) that has `ipfs://` registered via `registerProtocolHandler`, and in Brave / Opera (which have built-in support). 82 | 3. Ibid. 83 | 4. An experimental browser is capable of passing all tests from (2). 84 | 85 | ## Resources 86 | 87 | 88 | 89 | - https://ipfs.github.io/in-web-browsers/ipfs-protocol-handler-support-tests.html 90 | - https://github.com/olizilla/dweb.link/issues/7 91 | - https://github.com/ipfs/in-web-browsers/issues/165 92 | - https://github.com/ipfs/in-web-browsers/issues/168 93 | 94 | ## Support and Funding 95 | 96 | 100 | 101 | This grant is funded by Protocol Labs. 102 | Technical guidance will be provided by @lidel. 103 | -------------------------------------------------------------------------------- /targeted-grants/IPFS-mobile-design-guidelines.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `IPFS mobile design guidelines` 2 | 3 | **Name of Project:** 4 | 5 | **Proposer:** `jkosem` 6 | 7 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** "Yes" 8 | 9 | # Project Description 10 | 11 | Following on the far-reaching initial efforts to bring about mass adoption of IPFS by creating browser design guidelines to be brought to standards bodies and browser vendors, it is clear the guidelines work needs to be expanded to where it could achieve adoption quickest, on mobile. Smartphone use has eclipsed desktop, especially in emerging markets, where IPFS stands to better address use cases, patterns and concerns around data sovereignty, offline applications and security. 12 | 13 | This programme of work will include the design phase to follow on from the preceding research phase. It will include not just the design of use of mobile browser but wider mobile sharing and receiving workflows of iOS and Android mobile operating systems. This will provide a foundational effort towards IPFS on mobile platforms, informing both IPFS feature prioritisation and the ecosystem and community building on the protocol. 14 | 15 | ## Value 16 | 17 | If the mobile design guidelines are not available, we risk application builders reinventing this design wheel over and over again, or shipping poorly designed IPFS-based products that don't meet user needs. This ultimately means less and less people would use IPFS. 18 | 19 | The value of the IPFS Mobile Design Guidelines is taking the research and analysis, synthesising it and then providing actionable principles for the development and design communities to act on in bringing IPFS mobile experiences to the world in the most user-friendly way possible. 20 | 21 | The question of scope is constant in defining projects and areas of study. While the scope of this may initially be quite wide and shallow, this could be advantageous in setting up the groundwork for additional studies which would further refine thinking and recommendations as the field progresses. The value lies in making forays into the space, researching and designing that which has not been done to date, and creating a way to learn where to refine and redefine how IPFS is brought to more and more users. 22 | 23 | ## Deliverables 24 | 25 | The deliverable is a repository and report of use-cases, design guidelines and UX patterns. This design direction would then be explored through iconography, interface and interaction design as expressed through the design and production of graphic assets. These assets, in accessible graphical formats in a version tracked repository, will then help form the recommendations half of the public and open source report, showing and inspiring designers how to design for IPFS in a mobile world. 26 | 27 | ## Development Roadmap 28 | 29 | The following is the second of two phases of the rollout of the IPFS Mobile Design Guidelines. All of the research and design work is to be led or done by Jim Kosem with technical and project guidance and advice by Dietrich Ayala. 30 | 31 | 13 Apr 2020: Proposed date to start 32 | 33 | 22 May 2020: Estimated date to finish 34 | 35 | Milestone | Hours | Cost 36 | --- | --- | --- 37 | Design workshop to help translate research and direct design | 16 | €1,180.00 38 | User interface, component and elements design | 38 | €2,802.50 39 | Interaction design and production of user flows and use cases | 40 | €2,950.00 40 | Design guidelines creation and documentation | 20 | €1,475.00 41 | Documentation survey and collection of research and design materials | 18 | €1,327.50 42 | Guidelines analysis | 20 | €1,475.00 43 | Compilation of assets and writing of documentation with development recommendations | 24 | €1,770.00 44 | Writing and publication of blog post summarising the project design | 8 | €590.00 45 | Presentation of the project at IPFS Weekly | 8 | €590.00 46 | **Total** | | **€14,160.00** 47 | 48 | ## Total Budget Requested 49 | 50 | €14,160 EUR 51 | 52 | No VAT charged (Reverse charge – VAT is not settled under Article 44 of Directive 2006/112/EC) 53 | 54 | ## Maintenance and Upgrade Plans 55 | 56 | As the project is research and design based, there is no need for software maintenance. However, what will be produced and delivered are content and design repositories and documents which are to be open source, freely available to the public and to be maintained by Protocol Labs. 57 | 58 | # Team 59 | 60 | ## Team Members 61 | 62 | - Jim Kosem (Researcher and designer) - jimkosem.com 63 | - Dietrich Ayala (Protocol Labs advisor) - https://github.com/autonome 64 | 65 | ## Team Website 66 | 67 | `Github repository provided by Protocol Labs to follow` 68 | 69 | ## Relevant Experience 70 | 71 | Jim is a designer with 20 years of experience researching, designing and helping build digital products and services for everyone from Intel, Samsung to the British Government Digital Services. He's currently working in helping make decentralisation usable. As co-author of the Protocol Labs IPFS Browser Design Guidelines, along with background in the blockchain space and extensive innovation and product experience, Jim is uniquely suited to help further IPFS's efforts in mass adoption. 72 | 73 | ## Team code repositories 74 | 75 | [IPFS Browser Design Guidelines] 76 | 77 | # Additional Information 78 | 79 | Please include any additional information that you think would be useful in helping us to evaluate your proposal. 80 | -------------------------------------------------------------------------------- /targeted-grants/IPFS-mobile-design-research.md: -------------------------------------------------------------------------------- 1 | # Open Grant Proposal: `IPFS mobile design research` 2 | 3 | **Name of Project:** 4 | 5 | **Proposer:** `jkosem` 6 | 7 | **Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:** "Yes" 8 | 9 | # Project Description 10 | 11 | Following on the far-reaching initial efforts to bring about mass adoption of IPFS by creating browser design guidelines to be brought to standards bodies and browser vendors, it is clear the guidelines work needs to be expanded to where it could achieve adoption quickest, on mobile. Smartphone use has eclipsed desktop, especially in emerging markets, where IPFS stands to better address use cases, patterns and concerns around data sovereignty, offline applications and security. 12 | 13 | This programme of work will be the first of two, including research and design phases. Both will include not just use of mobile browser but wider mobile sharing and receiving workflows of iOS and Android mobile operating systems. This will provide a foundational effort towards IPFS on mobile platforms, informing both IPFS feature prioritization and the ecosystem and community building on the protocol. 14 | 15 | ## Value 16 | 17 | An evaluation of IPFS for mobile applications that is grounded in research and design will be the foundation for adoption at massive scale. By researching existing usage patterns and behaviors, we can identify where IPFS could have the most impact, accelerating and amplifying the efforts of application builders. 18 | 19 | Mobile is especially important to the wider distribution of IPFS and user base growth. IPFS could, with focused study on use cases and behaviours of mobile users for instance with sharing content and media, be an easier jump to using P2P in their daily lives. For instance, a solid and enjoyable IPFS mobile experience might allow perhaps skipping the desktop experience altogether for users coming to the platform. 20 | 21 | The question of scope is constant in defining projects and areas of study. While the scope of this may initially be quite wide and shallow, this could be advantageous in setting up the groundwork for additional studies which would further refine thinking and recommendations as the field progresses. The value lies in making forays into the space, researching and designing that which has not been done to date, and creating a way to learn where to refine and redefine how IPFS is brought to more and more users. 22 | 23 | ## Deliverables 24 | 25 | The deliverable is a repository and report of research and analysis to inform the IPFS Mobile Design Guidelines. The research contains a contextual examination of the technical, security and usability issues with IPFS use on mobile, an examination of the current mobile sharing and receiving features and patterns. After establishing the investigation space, there would follow the interviews and analysis to develop a design direction. This would include interviews with and examination of the work of firms already doing work in this space such as Berty Technologies and Textile. 26 | 27 | ## Development Roadmap 28 | 29 | The following is the first of two phases of the rollout of the IPFS Mobile Design Guidelines. All of the research and design work is to be led or done by Jim Kosem with technical and project guidance and advice by Dietrich Ayala. 30 | 31 | 04 Mar 2020: Proposed date to start 32 | 33 | 03 Apr 2020: Proposed date to finish 34 | 35 | Milestone | Hours | Cost 36 | --- | --- | --- 37 | Kick off workshop - design, planning, setup and execution of sync remote workshop for stakeholders in order to help frame the research and highlight where and what to focus on. | 16 | €1,180.00 38 | Research recruitment - sourcing, evaluating, contacting and scheduling for non-technical and technical interviewees. | 16 | €1,180.00 39 | Survey review of mobile p2p applications - Identify and review features, capabilities, use-cases and authors of existing mobile p2p applications | 16 | €1,180.00 40 | Writing and publication of blog post introducing the project research | 4 | €295.00 41 | Review of wider and additional contexts that affect mobile beyond the mobile browser, for example power, bandwidth and security | 16 | €1,180.00 42 | Perform interviews of experts and non-experts | 32 | €2,360.00 43 | Consolidating of research notes and learnings from interviews and into a readable resource to contribute to the final design recommendations in public Github repository | 16 | €1,180.00 44 | Analysis of research and surveys to identify key learnings to lead the creation of design strategy | 32 | €2,360.00 45 | Creation and compilation of design strategy with recommendations to provide direction to the following IPFS mobile design phase documented in repository | 8 | €590.00 46 | Writing and publication of blog post summarising the project research | 12 | €885.00 47 | Presentation of the project at IPFS Weekly - including the production of slide deck, review, and present | 8 | €590.00 48 | **Total** | | **€12,980.00** 49 | 50 | ## Total Budget Requested 51 | 52 | €12,980 EUR 53 | 54 | No VAT charged (Reverse charge – VAT is not settled under Article 44 of Directive 2006/112/EC) 55 | 56 | ## Maintenance and Upgrade Plans 57 | 58 | As the project is research and design based, there is no need for software maintenance. However, what will be produced and delivered are content and design repositories and documents which are to be open source, freely available to the public and to be maintained by Protocol Labs. 59 | 60 | # Team 61 | 62 | ## Team Members 63 | 64 | - Jim Kosem (Researcher and designer) - jimkosem.com 65 | - Dietrich Ayala (Protocol Labs advisor) - https://github.com/autonome 66 | 67 | ## Team Website 68 | 69 | `Github repository provided by Protocol Labs to follow` 70 | 71 | ## Relevant Experience 72 | 73 | Jim is a designer with 20 years of experience researching, designing and helping build digital products and services for everyone from Intel, Samsung to the British Government Digital Services. He's currently working in helping make decentralisation usable. As co-author of the Protocol Labs IPFS Browser Design Guidelines, along with background in the blockchain space and extensive innovation and product experience, Jim is uniquely suited to help further IPFS's efforts in mass adoption. 74 | 75 | ## Team code repositories 76 | 77 | [IPFS Browser Design Guidelines] 78 | 79 | # Additional Information 80 | 81 | Please include any additional information that you think would be useful in helping us to evaluate your proposal. 82 | -------------------------------------------------------------------------------- /targeted-grants/active-local-discovery-in-brave.md: -------------------------------------------------------------------------------- 1 | # Targeted Grant: Active local discovery in Brave 2 | 3 | **Issuer:** @lidel and @autonome 4 | **Recipient:** @RangerMauve 5 | 6 | ## Project Description 7 | 8 | 11 | 12 | **This project’s goal is to get active local peer discovery working in [IPFS-Companion](https://github.com/ipfs/ipfs-companion) on the [Brave](https://brave.com/) browser when embedded [JS-IPFS](https://github.com/ipfs/js-ipfs) node is used.** 13 | 14 | Part of this will be to find out what isn’t working in the current implementation and/or [mDNS spec](https://github.com/libp2p/specs/blob/master/discovery/mdns.md) and to fix it, or propose changes that will enable discovery to work in decentralized fashion. 15 | 16 | Secondary goal is to test and refine the Targeted Grant process. 17 | 18 | ## Value 19 | 20 | 21 | 22 | This work enables browser-to-browser IPFS connections in local networks, a powerful expression of offline and local collaboration use-cases of IPFS technology. 23 | 24 | It will lay the groundwork for interoperable local network discovery between browser and non-browser nodes and also providers a low-barrier way for people to experience the true power of IPFS without installing separate daemon software. 25 | 26 | It will also proof-check our existing specs related to mDNS local discovery, making it interoperable across varying runtime environments. 27 | 28 | ## Deliverables 29 | 30 | 31 | 32 | - Local discovery between two JS-IPFS nodes running in Brave is merged to ipfs-companion. 33 | - Upstream fixes to `js-libp2p-mdns`, `libp2p/specs` (if needed) 34 | 35 | ## Team 36 | 37 | 38 | 39 | - [@RangerMauve](https://github.com/RangerMauve) - (Grant recipient) Active member of the dweb community. 40 | Done multiple grants with DAT and are key member in team that set up the DAT Foundation. 41 | 42 | - @lidel - (Protocol Labs) Technical advisor 43 | 44 | - @autonome - (Protocol Labs) Grant advisor 45 | 46 | ## Detailed Requirements & Constraints 47 | 50 | 51 | Our browser extension is whitelisted in Brave to have access to TCP and UDP socket APIs at `chrome.sockets.*`. 52 | We take advantage of that when "Embedded with chrome.sockets" node type is selected in *Preferences*. 53 | 54 | Right now, only the passive discovery of go-ipfs works (via _compat_ submodule from [js-libp2p-mdns](https://github.com/libp2p/js-libp2p-mdns)): the IPFS node running in Brave is not announcing itself to other peers on the same local network, and a centralized signaling service at `ws-star.discovery.libp2p.io` needs to be used instead. 55 | 56 | 57 | It is unknown if existing mdns discovery spec can be used in environment with `chrome.sockets`, and depending on the research done as a part of this grant, different solutions can be delivered: 58 | 59 | - If `js-libp2p-mdns` can be fixed, but requires changes to [libp2p mDNS spec](https://github.com/libp2p/specs/blob/master/discovery/mdns.md), PRs making changes to the libp2p spec and relevant libraries and app repositories need to be approved and merged before proceeding further. 60 | - If `js-libp2p-mdns` could not be used or fixed, a separate discovery module dedicated for use in runtimes with `chrome.sockets` can be created. If so, it should be: 61 | - published on NPM 62 | - licensed under MIT+Apache 2.0 ([PL's permissive licensing stack](https://protocol.ai/blog/announcing-the-permissive-license-stack/)) 63 | - Whitelisting additional `chrome.*` APIs is on the table, but requires PoC validating the need. 64 | 65 | ## Milestones & Funding 66 | 67 | **Total Funding Amount:** $3600 68 | 69 | **Milestones:** (working 10 hours a week) 70 | 71 | | Milestone No. | Milestone Description | Funding | Estimated Timeframe | 72 | | --- | --- | --- | --- | 73 | | 1 | Research relevant libraries specs and available APIs and prepare a standalone PoC | $1200 | ~35h | 74 | | 2 | Submit PR changes to respective specs, libraries and projects | $1200 | ~20h | 75 | | 3 | Addressing reviews, all PRs are merged | $1200 | ~10h | 76 | 77 | 78 | 79 | ## Acceptance Criteria 80 | 81 | 82 | 83 | - Local discovery between two JS-IPFS nodes running in Brave works in a LAN without connection to the internet (no centralized signaling service). 84 | - `js-libp2p-mdns` is in sync with [the spec](https://github.com/libp2p/specs/blob/master/discovery/mdns.md). 85 | - PRs making changes to the libp2p spec and relevant libraries and app repositories are approved and merged. 86 | - JS-IPFS node running in Brave can announce itself to go-ipfs 0.4.23 using `mdns:compat` from `js-libp2p-mdns`, or it is documented why it is not possible to implement it on top of `chrome.sockets` for future work in this problem space. 87 | 88 | ## Resources 89 | 90 | 91 | 92 | 93 | - ipfs-companion issue: [Brave: LAN discovery & announcement](https://github.com/ipfs-shipyard/ipfs-companion/issues/758) 94 | - [node types in ipfs-companion v2.10.0](https://github.com/ipfs-shipyard/ipfs-companion/blob/v2.10.0/docs/node-types.md) 95 | - [ Embedded JS-IPFS in Brave](https://github.com/ipfs-shipyard/ipfs-companion/issues/716) 96 | - Local discovery library used by js-ipfs in ipfs-companion: [js-libp2p-mdns](https://github.com/libp2p/js-libp2p-mdns) 97 | - **Note:** it aims to support existing mDNS discovery service provided by every go-ipfs node (`mdns:compat`) and the new spec that is compliant with DNS Service Discovery (DNS-SD), as described in [libp2p/specs/discovery/mdns.md](https://github.com/libp2p/specs/blob/master/discovery/mdns.md). 98 | - js-ipfs supports both 99 | - go-ipfs supports only the legacy mdns method (`mdns:compat`) 100 | 101 | ## Support and Funding 102 | 103 | 107 | 108 | This grant is funded by Protocol Labs. 109 | Technical guidance will be provided by @lidel. 110 | -------------------------------------------------------------------------------- /targeted-grants/dnslink-multiplatform-update.md: -------------------------------------------------------------------------------- 1 | # Targeted Grant: DNSLink multiplatform and update 2 | 3 | **Issuer:** [@lidel][] 4 | **Recipient:** [@martinheidegger][] 5 | 6 | ## Project Description 7 | 8 | **Update DNSLink implementations and publication for consistency and interoperability.** 9 | 10 | The project consists of 4 parts in 5 milestones: 11 | 12 | 1. Create Test Suite for DNSLink implementations. 13 | 2. Fix essential issues with existing DNSLink implementations in IPFS. 14 | 3. Update DNSLink website & specifications to reflect the changes in the implementation and reference the test suite. 15 | 4. Create browser tool for DNSLink exploration. 16 | 17 | ## Value 18 | 19 | With the work done in this grant, DNSLink will support multi-protocol. Allowing users of DNSLink to choose both IPFS and another protocol instead of having to choose either as its the case right now. 20 | 21 | The documentation updates have the goal to explain DNSLink system better to end users, developers and implementers. 22 | 23 | The consistency of the implementations is to increase the confidence in DNSLink. 24 | 25 | ## Deliverables 26 | 27 | - Language and platform independent **test setup** for dnslink. 28 | - **Documentation** specifying redirects and consistent ordering. 29 | - Independent DNSLink **JavaScript implementation** that works in browsers and Node.js. 30 | - **Browser util** that visualizes the output of the DNSLink for a given domain name. 31 | - **Fixes for the existing implementations** of DNSLink used in IPFS (GO & javascript). 32 | 33 | ## Team 34 | 35 | - [@martinheidegger][] - (Grant recipient) Active member of the dweb community. 36 | New to the IPFS community; working on dns support for the `hyper://` community. Actively developing of `hyper-dns` for the hyper community. 37 | 38 | - [@lidel][] - (Protocol Labs) Technical advisor 39 | 40 | ## Detailed Requirements & Constraints 41 | 42 | **Test Setup:** A test setup needs to consist of DNS-settings on the domain that can be used to verify a working version of DNSLink. It needs to cover all edge cases, such as: existing/missing `_dnslink` subdomains, redirects, multiple dnstext entries for multiple protocols and error cases. 43 | 44 | **Documentation:** The documentation to be published on the dns page needs to cover the Test setup, and detail the new fixes of the implementation. 45 | 46 | **JavaScript Implementation:** The JavaScript implementation needs to provide TypeScript definitions, `tape` tests be published on NPM. In the CI setup it needs to work with `browser-run`. The implementation needs to also work with DoH, respecting the [wire format](https://developers.cloudflare.com/1.1.1.1/dns-over-https/wireformat). 47 | 48 | **Browser util:** The browser util at dnslink.io needs to work on modern browsers, excluding IE 11. Minimally it needs to provide the result of DNSLink lookup for a given domain: resolve DNS TXT lookup over DoH using the RFC-compliant wire-format. Needs option to specify DoH configuration. 49 | 50 | **Fixes for the existing implementations:** Provide Pull Requests an tests for the existing `js-ipfs` implementation, `go-dnslink` implementation and `go-namesys` implementation. 51 | 52 | ## Milestones & Funding 53 | 54 | **Total Funding Amount:** $9100 55 | 56 | **Milestones:** (working ~30 hours a week) 57 | 58 | | Milestone No. | Milestone Description | Funding | Estimated Timeframe | 59 | | --- | --- | --- | --- | 60 | | 1 | Test Setup | $1300 | ~20h | 61 | | 2 | Documentation | $1300 | ~20h | 62 | | 3 | JavaScript Implementation | $2600 | ~40h | 63 | | 4 | Browser util | $1300 | ~20h | 64 | | 5 | Fixes for the existing implementations | $2600 | ~40h | 65 | 66 | ## Acceptance Criteria 67 | 68 | 69 | 70 | 1. Published Test Setup and examplary use of it in one implementation. 71 | 2. Pull-Request on dnslink homepage containing all required changes to the spec. 72 | 3. JavaScript library with reference implementation of the DNSLink spec published on NPM. Programmatic interface for resolving DNSLink records works in Nodejs and Browser, and command line script can be used for quick lookup/validation when run via `npx`. 73 | 4. Browser Util, based on the NPM library, published on the dnslink.io website allowing to explore and test DNSLink records on a domain provided by the user. DoH endpoint used for DNS lookups can be customized via UI. 74 | 6. Accepted PR's to existing IPFS repositories. go-ipfs uses go-dnslink, and js-ipfs uses the new dnslink library from NPM. 75 | 7. New libraries will be released under [dual MIT/Apache-2 license](https://protocol.ai/blog/announcing-the-permissive-license-stack/) 76 | 77 | ## Resources 78 | 79 | 80 | 81 | - https://github.com/ipfs/js-ipfs/issues/3685 82 | - https://github.com/ipfs/go-dnslink/issues/14 83 | - https://github.com/JChanceHud/dnslink/issues/5 84 | - https://github.com/ipfs/js-ipfs/issues/3684 85 | - https://github.com/ipfs/dnslink.dev/issues/1 86 | - https://github.com/ipfs/js-ipfs/issues/2212 87 | 88 | ## Support and Funding 89 | 90 | 91 | This grant is funded by Protocol Labs. 92 | Technical guidance will be provided by [@lidel][]. 93 | 94 | [@lidel]: https://github.com/lidel 95 | [@martinheidegger]: https://github.com/martinheidegger 96 | -------------------------------------------------------------------------------- /targeted-grants/omnilingo-IPFS.md: -------------------------------------------------------------------------------- 1 | # Targeted Grant: Omnilingo hosted on IPFS 2 | 3 | * **Issuer:** @autonome 4 | * **Recipients:** @nlhowell @ftyers 5 | 6 | ## Project description 7 | 8 | We are building a language-learning app for language communities 9 | that are either unsupported by major platforms or do not wish 10 | to give up sovereignty over their languages. Centralised language-learning 11 | systems privately collect user data and audio samples, trapping communities 12 | into proprietary silos and walled gardens. With the popularisation of open 13 | content licences and the innovation of new accessible distributed storage 14 | systems, we can build language-learning for the decentralised web. 15 | 16 | Our design is decentralised from the beginning, with common resources 17 | accessible through a robust simple protocol amenable to offline, http-based, or 18 | peer-to-peer access; user settings stored in one or more persistent stores of 19 | the user's choice; and clients offering users maximum sovereignty over who has 20 | their data. 21 | 22 | This grant will allow us to implement an IPFS-based common resource storage 23 | design and plugins for client applications to access IPFS-based common 24 | resources. IPFS provides flexible storage and content distribution network 25 | capabilities without the dependency on and vulnerability to a centralised 26 | system. 27 | 28 | ## Target audience 29 | 30 | We have several target audiences for the software. 31 | 32 | Firstly language learners, the demo was built to scratch an itch. The second author 33 | was taking a language class and wanted a way to practise listening comprehension. There 34 | are no other free/open-source applications for this, and certainly no others that support 35 | a wide range of languages or allow languages to be easily added. In terms of the size of 36 | the potential learner userbase, it scales with the number of language communities we serve. 37 | 38 | Secondly developers of other language learning applications in the free/open-source world. 39 | There are a wide variety of applications that have a problem accessing open content in 40 | many languages and so cannot take advantage of the kind of scale available to enterprise 41 | players. 42 | 43 | Thirdly language teachers, we have been in contact with various people with an eye to 44 | working out how to fit language teachers into the project as a primary stakeholder and driver 45 | and not just as a passive user. This could for example allow them to design their own 46 | curricula using the data, without having to do the processing themselves. Think of it as 47 | "distributed audio-visual building blocks for language courses". 48 | 49 | Fourthly researchers. This would need to be worked out from a privacy perspective, but we 50 | would like to develop a system to allow users to locally store their behavioural/activity data and 51 | optionally and with full consent share it in an anonymised form with researchers in the fields 52 | of second-language acquisition/second-language studies/linguistics/computer-aided language learning 53 | etc. This could enable research into active learning and tailored-language learning (for example 54 | a curriculum of clips that maximises acquisition of particular phonemic contrasts). Although 55 | the data would be locally stored, the references/addresses of the relevant content would be 56 | global. 57 | 58 | ## Data characteristics 59 | 60 | * The principle data we are interested in with respect to language data are audio 61 | files and text files. These are split by language, a given language may have thousands 62 | of potential clips, and each one needs to be addressed and linked to metadata about 63 | the clip (e.g. difficulty rating, transcript, etc.) 64 | * To give an example, in our demo which supports 60 languages, each language has around 65 | 10,000 audio clips, with each language having in the region of 10M-100M of clips. We are only 66 | currently able to use a fraction of the available data, which is in the region of 250G 67 | of clips with a median per language of 400M. 68 | * The precise location of the clip does not matter, so long as it is addressable and linkable 69 | to the relevant metadata. 70 | 71 | ## Value 72 | 73 | Language learning resources is an embarrassingly distributable system, and is an 74 | opportunity to expose the large population of language learners to the 75 | distributed web. 76 | 77 | ## Future directions 78 | 79 | This seed grant is intended to fund proof-of-concept work on using IPFS for decentralised 80 | and content-addressed audio-visual content storage aimed at language learning. This is however 81 | only a start. 82 | 83 | ***From crowdsourcing to crowdstoring***: The popular methods of crowdsourcing language data 84 | currently work in a centralised way. There is storage in something like EC3, and contributors 85 | have to give up the rights over their data to participate. If there are many other options 86 | and people are participating for pure enjoyment this is not problematic, but if people are 87 | participating because they have no other option then it tends to extraction. This is particularly 88 | highlighted when indigenous or colonised communities are involved (e.g. [Māori are trying to save 89 | their language from Big Tech](https://www.wired.co.uk/article/maori-language-tech)). We envisage 90 | a more equitable approach that would allow individuals and language communities to license their data 91 | however they see fit, but take advantage of content addressing and distributed storage to lower 92 | the barrier to entry and to enable wide replication to avoid catastrophic data loss. 93 | 94 | 95 | 96 | ## Deliverables 97 | 98 | 1. IPFS support for Omnilingo client applications 99 | 1. IPFS support in the Omnilingo language data toolkit 100 | 1. Demo page working with several languages with available data 101 | 1. Post about the project for the IPFS blog 102 | 1. Design of distributed voice data contribution system using IPFS 103 | 1. Scientific article describing our success published in workshop proceedings and/or on arxiv. 104 | 105 | ## Team 106 | 107 | * @ftyers, @nlhowell - Grant recipients. Computational linguists with 108 | familiarity with multilingualism and experience in distributed computing and 109 | speech processing 110 | * Dietrich Ayala - PL Grant advisor 111 | 112 | ## Milestones & Funding 113 | 114 | **Total Funding Amount:** $10,000 115 | 116 | Week | Milestone | Cost 117 | ---- | --------- | ---- 118 | 1 | ipfs support in toolkit design | $1250 119 | 2 | ipfs support in toolkit implementation | $1250 120 | 3 | ipfs support in client design | $1250 121 | 4 | ipfs support in client implementation | $1250 122 | 5 | ipfs support in client integration | $1250 123 | 6 | demo of omnilingo on ipfs | $1250 124 | 7 | distributed voice contrib design | $1250 125 | 8 | paper and blog post | $1250 126 | 127 | ## Resources 128 | 129 | * Omnilingo: https://omnilingo.xyz 130 | * Open voice data: https://openslr.org 131 | * A centralised language learning system: https://duolingo.com 132 | * A centralised voice contribution system (for comparison): 133 | https://commonvoice.mozilla.org 134 | 135 | ## Support and Funding 136 | 137 | This grant is funded by Protocol Labs. 138 | -------------------------------------------------------------------------------- /targeted-grants/open-street-map-ipfs.md: -------------------------------------------------------------------------------- 1 | # Targeted Grant: Open Street Map hosted on IPFS + Filecoin 2 | 3 | **Issuer:** @autonome + @mishmosh 4 | **Recipient:** @okdistribute 5 | 6 | ## Project Description 7 | 8 | 11 | 12 | We are building Peermaps, a distributed, offline-friendly alternative to commercial map providers such as Google Maps. Instead of fetching data from a centralized tile service, your computer fetches map data from other peers across the network. With the powerful inverse scaling dynamics of peer-to-peer, we can run a mapping platform at a fixed, modest cost, no matter how popular it becomes. 13 | 14 | We've developed a new standard format for map data that is better for decentralized contexts. [This specification can be found here.](https://github.com/peermaps/docs/blob/master/bufferschema.md) The original OSM data format is XML and is not great for random access or space efficiency. But both of these features -- small footprint and efficient access -- will be critical for practical use on a distributed storage network. A typical size for data in XML format is at least 87GB, and the OSM pbf format reduces it to 50GB. The peermaps format should be much smaller and faster by using compact buffers, triangulation, and clever indexing developed in Rust. 15 | 16 | This grant will help us use IPFS as a "hot" peer-to-peer storage network for Peermaps data for near-real-time access. This will be a premiere application built on IPFS that will greatly improve digital mapping. There is between 3-4GB of XML updated per week on OpenStreetMap -- we (bits.coop peermaps team) will run a node will download, diffs, and pack those changes into the Peermaps format on a regular basis. 17 | 18 | This script will also put OpenStreetMap data in the original (.pbf) format on the IPFS and Filecoin networks for cold storage, improving the overall resiliency and download speeds for the data. We figured this will be nice to do at the same time, since the processing node will have to downloading these large OSM files anyway, it would make sense to also upload the original (pre-processed) versions to IPFS and Filecoin. 19 | 20 | 21 | ## Value 22 | 23 | 24 | 25 | 26 | We will be able to lower costs for developers who are currently using embedded Google Maps or Mapbox, which both cost money per impression after a certain limit. 27 | 28 | Currently a developer creating a website with a map will have to pay substantial money per impression. For example, 1 million impressions * $0.07 = $70,000. Although there are often volume discounts, this gives you an idea of how expensive this can be for the unfortunately popular individual developer or small startup. 29 | 30 | OpenStreetMap is an amazing example of public-interest technology and community-run critical digital infrastructure. They have managed to make a competitive product to Google maps, and they serve a substantial volume of requests. Decentralizing their storage -- both for hot and cold access -- could drastically lower costs for the community to maintain this public interest dataset. Peer to peer protocols like IPFS will be able to spread out the work of hosting very large files among all the participants in the network who are interested in a file. Centralized services can be overwhelmed if too many people want to download a file, but p2p services flip scaling on its head: the more people are downloading and sharing, the better the network works for everyone. 31 | 32 | ## Deliverables 33 | 34 | 35 | 36 | 37 | 1. `peermaps/ingest`: A library for injesting and diffing OpenStreetMap data, handling periodic changes. This tool will convert OpenStreetMap into the Peermaps format. This deliverable is co-funded by this devgrant and SamsungNEXT; 38 | 2. Commandline tool using `peermaps/ingest` to diff .pbf files, convert to the Peermaps format, and pin both data formats on IPFS; 39 | 3. Commandline tool using `peermaps/ingest` .pbf files, convert to the Peermaps format, and pin both data formats on Filecoin 40 | 4. Post about the project for the IPFS blog 41 | 5. Demo page with example code for map view in the browser using js-ipfs to fetch data. 42 | 6. Report on feasability, usability, experience building on Filecoin/IPFS apis. 43 | 44 | ## Team 45 | 46 | 47 | 48 | 49 | * @okdistribute- Grant recipient. 3rd member of dat in 2014, peer-to-peer software developer with experience in developing mission-critical production applications. 50 | * @substack, @mk30, @sedmonds, bits.coop - Technical advisors for peermaps 51 | * Dietrich Ayala, Michelle Lee - PL Grant advisors 52 | 53 | ## Milestones & Funding 54 | 55 | **Total Funding Amount:** $17,100 56 | 57 | Milestone | Hours | Cost 58 | --- | --- | --- 59 | Research and experimentation with Filecoin and IPFS APIs, compiling report about feasibility and usability when building on both. | 16 | $1,800.00 60 | New repository `peermaps/spec` that further formalizes the Peermaps specification depending on factors related to IPFS and Filecoin to improve performance and usability | 16 | $1,800.00 61 | v1 of the `peermaps/ingest` library in Rust | 64 | $7,200.00 62 | Documentation, automated testing suite, bug fixes, and performance enhancments as necessary for `peermaps/ingest` at v1.0.x | 32 | $3,600.00 63 | Commandline tool to diff .pbf files, convert to the Peermaps format, and pin both data formats on IPFS | 12 | $1,350.00 64 | Commandline tool to diff .pbf files, convert to the Peermaps format, and pin both data formats on Filecoin | 12 | $1,350.00 65 | **Total** | | **$17,100.00** 66 | 67 | ## Detailed Requirements & Constraints 68 | 71 | 72 | We plan to run a node to process, diff, and host the data in the short term. This will be run on a computer every week. We can publish this on a collaborative cluster to make it easy for other folks to also host the subsequent data. If at some point we decide to shut off our node that processes & diffs, we will let Protocol Labs know -- and of course all the necessary tools will be open source. 73 | 74 | A long-term goal of this project is to make this processing & indexing be 75 | done with distributed computation, rather than on a single machine. Ideally, 76 | other groups in maplandia would be interested in running the infra/CI and we 77 | could share the computation load. 78 | 79 | We'd also be happy to run the script on the IPFS collaborative cluster infra as 80 | well: https://blog.ipfs.io/2020-01-09-collaborative-clusters/. 81 | 82 | ## Resources 83 | 84 | 85 | 86 | * OpenStreetMap weekly data dump (planet.osm, 87GB): https://planet.openstreetmap.org/ 87 | * Peermaps website: peermaps.org 88 | * Google Maps Pricing: https://cloud.google.com/maps-platform/pricing/sheet/ 89 | * MapBox Pricing: https://www.mapbox.com/pricing/ 90 | * How to download OSM data: https://wiki.openstreetmap.org/wiki/Downloading_data 91 | * Statistics of daily users: https://www.openstreetmap.org/stats/data_stats.html 92 | * Diff size can range between 3-4GB of XML per week. 93 | 94 | ## Support and Funding 95 | 96 | 100 | 101 | This grant is funded by Protocol Labs. 102 | --------------------------------------------------------------------------------