profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/mishmosh/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

CodeForPhilly/chime 207

COVID-19 Hospital Impact Model for Epidemics

ipfs/devgrants 75

The IPFS Grant platform connects funding organizations with builders and researchers in the IPFS community.

filecoin-project/go-fil-markets 45

Shared Implementation of Storage and Retrieval Markets for Filecoin Node Implementations

filecoin-shipyard/js-filecoin-api-client 44

An API client for Filecoin

filecoin-project/venus-docs 39

Content for Venus tutorial

bensheldon/open311status 30

Open311 Status monitors and aggregates the status of dozens of Open311 API endpoints, providing benchmarks and comparative insights.

filecoin-project/go-data-transfer 22

Data Transfer Shared Component for go-filecoin & go-lotus

Digital-MOB-Filecoin/QABot 14

Quality Bot: Periodically makes storage and retrieval deals with each of the top 100 miners, tracking state & success/fail.

mishmosh/bootstrap 1

HTML, CSS, and JS toolkit from Twitter

push eventipfs/devgrants

Johnny Wu

commit sha be2b1b1fd035a772f30b2e02376bffdf8f5741f3

Add a couple resources

view details

Mosh

commit sha 2d3561229b426be305e20c4d2c80dbd33d3cbdfc

Merge pull request #107 from johnnywu-namebase/patch-2 Add a couple resources

view details

push time in 2 days

PR merged ipfs/devgrants

Add a couple resources
+3 -2

0 comment

1 changed file

johnnywu-namebase

pr closed time in 2 days

PullRequestReviewEvent

pull request commentipfs/devgrants

ipsg

Hello! Thank you for your proposal. Some initial comments:

  1. The IPFS ecosystem is quite broad, and we've seen a general pattern of users struggling to even name their problem, let alone search for or find the solution. It would be great to see an "Adoption and Outreach" phase 4 of this project even if it increases scope. This might include contributing a new page or writeup to https://docs.ipfs.io/how-to/ (eg "Organizing IPFS Content Within Your Application"), publishing a demo video workshop, and giving workshops and talks oriented to application builders either at IPFS-hosted or external events (PL team can help arrange & schedule).

  2. Nit: Could you add the name of your IPFS technical advisor (W.S. - don't know their github handle) somewhere in the markdown file? This will help us stay organized when it comes to milestone check-ins, etc.

maurerbot

comment created time in 3 days

PR opened jochasinga/flowwow

Edits to readme

Hi @jochasinga — some suggestions for you to consider to get this readme public-ready before next Monday's workshop.

  • Add intro section
  • Separate prerequisites from getting started
  • Add software license info
+6 -4

0 comment

1 changed file

pr created time in 3 days

create barnchmishmosh/flowwow

branch : readme-edits

created branch time in 3 days

fork mishmosh/flowwow

NFT petshop built on Flow blockchain and IPFS

fork in 3 days

MemberEvent

issue openedipfs-shipyard/nft.storage

More docs for using NFT.storage at scale

I am seeing an increasing interest in people using or evaluating NFT for production usage. They have questions that are not well-answered by the "getting started" material currently published.

Rather than answering 1 at a time, I think a broader "using NFT.storage at scale" piece would be very timely and useful.

Let's use this thread to track all the questions/considerations coming up in this area. Then maybe we can set up a chat with team and turn it into a written longform piece for docs and/or blog.

1. Minting & working with 100s of NFTs

  • I'm setting up a NFT Minter for the first time. I'm using the IPFS GUI. I need to pin 100 images and copy all CID hashes. Is there a way to easily Pin all to Pinata and export all CIDs? I'm currently doing each one by hand.

2. Uploading 10000 NFTs and their metadata

  • Is the data pinned forever?
  • What uptime guarantees are available?
  • How many copies and which nodes are used?

3. How permanent is my data?

4. Gateways and throughput

created time in 6 days

push eventfilecoin-project/devgrants

Mosh

commit sha c0b677b3488cbe10f68e1ef4c4cbf3b2961b14e0

Delete rfp-storage-helper-libraries.md The introduction of tools like Estuary and NFT/Web3.storage has filled these needs, no longer urgent RFP.

view details

push time in 6 days

push eventfilecoin-project/devgrants

Mosh

commit sha 90bf49c935a0c8148ff1ad55d789f867939b6b52

Delete rfp-pbscale-miner-testing.md This was a pre-mainnet proposal from over 16 months ago. Since Space Race and Mainnet became performance testing grounds, this no longer needed.

view details

push time in 6 days

PR opened aschmahmann/ipfs-check

make website more user-friendly

This adds an instructions section (copied from your message in slack) to the website.

While I was here, also added:

  • Some formatting tweaks to form fields
  • Link to Github repo
+16 -2

0 comment

1 changed file

pr created time in 10 days

push eventmishmosh/ipfs-check

Mosh

commit sha f030e56fb2925772a8fb0e258edbb0cf0b8ec2a4

make website more user-friendly - Add an instructions section - Some formatting tweaks to form fields - Add link to Github repo

view details

push time in 10 days

fork mishmosh/ipfs-check

A tool for checking the accessibility of your data by IPFS peers

fork in 10 days

PR opened filecoin-project/devgrants

Reviewers
Update accepted-open-grant-applications.md

Update link text

+20 -20

0 comment

1 changed file

pr created time in 13 days

create barnchfilecoin-project/devgrants

branch : mishmosh-patch-3

created branch time in 13 days

push eventipfs/devgrants

Mosh

commit sha a609553faceb53af02d7e2b27283e32f121c3377

Update handshake-fallback-resolver.md

view details

push time in 17 days

push eventipfs/devgrants

Mosh

commit sha 666d6eae9138d1f088e3019baf8385e0cce09817

Clean up markdown for milestones table

view details

push time in 17 days

push eventipfs/devgrants

Johnny Wu

commit sha ee56b35016953554558ef9976a952832066203fe

Create handshake-fallback-resolver.md

view details

Johnny Wu

commit sha a0376b9254621d269a30a6084830020d3b2fb3d4

Update handshake-fallback-resolver.md

view details

Johnny Wu

commit sha c85fa0df53c56ac53f8c0b1cd528ea76b28f0909

Update handshake-fallback-resolver.md

view details

Johnny Wu

commit sha 7d4d393e81e50278f154502de10c1c317cec99a4

Update handshake-fallback-resolver.md

view details

Mosh

commit sha fac3dbbca6059201d7b4b331fb12d49ed5946b3c

Merge pull request #105 from johnnywu-namebase/patch-1 Create handshake-fallback-resolver.md

view details

push time in 17 days

PR merged ipfs/devgrants

Create handshake-fallback-resolver.md

Work in progress

+62 -0

1 comment

1 changed file

johnnywu-namebase

pr closed time in 17 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentipfs/devgrants

Create handshake-fallback-resolver.md

  ## Project Description -Please fill in details about what you're trying to build. What is the purpose/context? What are the high-level requirements?+Given the goals of: -This section should be 2-3 paragraphs long.+- IPFS doesn’t want to choose winners+- IPFS wants to decouple from ICANN and support non-ICANN namespaces+- IPFS wants to avoid introducing privacy and security risks in implicit defaults+- IPFS wants the alternative namespaces to be DNS compatible. Preferably they can use DoH endpoints++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. 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).++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.  ## Value -Please describe why the work that will come out of this RFP is valuable for the IPFS ecosystem.+By implementing a fallback resolver to distributed namespaces like Handshake, IPFS makes the decentralized web massively more accesibility to anyone already using an IPFS-compatible application, which in turn accelerates the adoption of a fully distributed web.  ## Deliverables -What are you expecting the proposer to deliver at the completion of this project?+A merged PR for implementing a fallback resolver that successfully resolves Handshake names like http://namebase/.  ## Recommended Team -List the skills and experience you are looking for. Teams with this background might be a better fit for this project.+Any developer comfortable with everything listed in the below `Resources` section.  ## Detailed Requirements & Constraints -You can use this section to detail requirements that the deliverables must include.--Also include any relevant constraints that the implementer should be aware of before beginning this project.+Before starting implementation, one should post the proposed design as a comment here (how config would look like, what implicit default would be, and what needs to be changed to make that possible). Please also ping @lidel and myself to ensure the proposed design is included during their 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.  ## Milestones & Funding -**Total Funding Amount:** List the total proposed funding amount (currently in USD, eventually can be a distribution between USD/FIL)+**Total Funding Amount:** $5,000 -**Milestones:** Make sure that the values in the Funding column add up to the Total Funding Amount listed above.--| Milestone No. | Milestone Description | Funding | Estimated Timeframe |-| --- | --- | --- | --- |-| 1 | Example milestone | $X | Y weeks |-| 2 | Example milestone | $X | Y weeks |-| 3 | Example milestone | $X | Y weeks |+**Milestones:** An initial $500 will be granted to whoever proposes the best design as shared in `Detailed Requirements & Constraints`. The remaining $4,500 will be granted upon completion of the PR.  ## Acceptance Criteria -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. +Handshake names like http://namebase/ should resolve in IPFS-comptaible applications like the IPFS Companion extension, Brave browser, and Opera browser, etc.

spelling for "compatible"

johnnywu-namebase

comment created time in 23 days

Pull request review commentipfs/devgrants

Create handshake-fallback-resolver.md

  ## Project Description -Please fill in details about what you're trying to build. What is the purpose/context? What are the high-level requirements?+Given the goals of: -This section should be 2-3 paragraphs long.+- IPFS doesn’t want to choose winners+- IPFS wants to decouple from ICANN and support non-ICANN namespaces+- IPFS wants to avoid introducing privacy and security risks in implicit defaults+- IPFS wants the alternative namespaces to be DNS compatible. Preferably they can use DoH endpoints++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. 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).++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.  ## Value -Please describe why the work that will come out of this RFP is valuable for the IPFS ecosystem.+By implementing a fallback resolver to distributed namespaces like Handshake, IPFS makes the decentralized web massively more accesibility to anyone already using an IPFS-compatible application, which in turn accelerates the adoption of a fully distributed web.  ## Deliverables -What are you expecting the proposer to deliver at the completion of this project?+A merged PR for implementing a fallback resolver that successfully resolves Handshake names like http://namebase/.  ## Recommended Team -List the skills and experience you are looking for. Teams with this background might be a better fit for this project.+Any developer comfortable with everything listed in the below `Resources` section.  ## Detailed Requirements & Constraints -You can use this section to detail requirements that the deliverables must include.--Also include any relevant constraints that the implementer should be aware of before beginning this project.+Before starting implementation, one should post the proposed design as a comment here (how config would look like, what implicit default would be, and what needs to be changed to make that possible). Please also ping @lidel and myself to ensure the proposed design is included during their 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.

I would move more of the requirements from lines 14 and 16 to here, before line 32.

johnnywu-namebase

comment created time in 23 days

Pull request review commentipfs/devgrants

Create handshake-fallback-resolver.md

  ## Project Description 

Maybe add an even broader intro here for people reading this with a much more general IPFS view, like "The distributed web community is exploring the areas of namespaces, resolvers, and fallback resolvers to remove the complexity of addressing IPFS and other content-addressed protocols."

johnnywu-namebase

comment created time in 23 days

Pull request review commentipfs/devgrants

Create handshake-fallback-resolver.md

  ## Project Description -Please fill in details about what you're trying to build. What is the purpose/context? What are the high-level requirements?+Given the goals of: -This section should be 2-3 paragraphs long.+- IPFS doesn’t want to choose winners+- IPFS wants to decouple from ICANN and support non-ICANN namespaces+- IPFS wants to avoid introducing privacy and security risks in implicit defaults+- IPFS wants the alternative namespaces to be DNS compatible. Preferably they can use DoH endpoints++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. 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).++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.  ## Value -Please describe why the work that will come out of this RFP is valuable for the IPFS ecosystem.+By implementing a fallback resolver to distributed namespaces like Handshake, IPFS makes the decentralized web massively more accesibility to anyone already using an IPFS-compatible application, which in turn accelerates the adoption of a fully distributed web.  ## Deliverables -What are you expecting the proposer to deliver at the completion of this project?+A merged PR for implementing a fallback resolver that successfully resolves Handshake names like http://namebase/.  ## Recommended Team -List the skills and experience you are looking for. Teams with this background might be a better fit for this project.+Any developer comfortable with everything listed in the below `Resources` section.  ## Detailed Requirements & Constraints -You can use this section to detail requirements that the deliverables must include.--Also include any relevant constraints that the implementer should be aware of before beginning this project.+Before starting implementation, one should post the proposed design as a comment here (how config would look like, what implicit default would be, and what needs to be changed to make that possible). Please also ping @lidel and myself to ensure the proposed design is included during their 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.  ## Milestones & Funding -**Total Funding Amount:** List the total proposed funding amount (currently in USD, eventually can be a distribution between USD/FIL)+**Total Funding Amount:** $5,000 -**Milestones:** Make sure that the values in the Funding column add up to the Total Funding Amount listed above.--| Milestone No. | Milestone Description | Funding | Estimated Timeframe |-| --- | --- | --- | --- |-| 1 | Example milestone | $X | Y weeks |-| 2 | Example milestone | $X | Y weeks |-| 3 | Example milestone | $X | Y weeks |+**Milestones:** An initial $500 will be granted to whoever proposes the best design as shared in `Detailed Requirements & Constraints`. The remaining $4,500 will be granted upon completion of the PR.

Maybe split this into a numbered list for ease of reading?

johnnywu-namebase

comment created time in 23 days

Pull request review commentipfs/devgrants

Create handshake-fallback-resolver.md

  ## Project Description -Please fill in details about what you're trying to build. What is the purpose/context? What are the high-level requirements?+Given the goals of: -This section should be 2-3 paragraphs long.+- IPFS doesn’t want to choose winners+- IPFS wants to decouple from ICANN and support non-ICANN namespaces+- IPFS wants to avoid introducing privacy and security risks in implicit defaults+- IPFS wants the alternative namespaces to be DNS compatible. Preferably they can use DoH endpoints++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. 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).++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.  ## Value -Please describe why the work that will come out of this RFP is valuable for the IPFS ecosystem.+By implementing a fallback resolver to distributed namespaces like Handshake, IPFS makes the decentralized web massively more accesibility to anyone already using an IPFS-compatible application, which in turn accelerates the adoption of a fully distributed web.  ## Deliverables -What are you expecting the proposer to deliver at the completion of this project?+A merged PR for implementing a fallback resolver that successfully resolves Handshake names like http://namebase/.  ## Recommended Team -List the skills and experience you are looking for. Teams with this background might be a better fit for this project.+Any developer comfortable with everything listed in the below `Resources` section.  ## Detailed Requirements & Constraints -You can use this section to detail requirements that the deliverables must include.--Also include any relevant constraints that the implementer should be aware of before beginning this project.+Before starting implementation, one should post the proposed design as a comment here (how config would look like, what implicit default would be, and what needs to be changed to make that possible). Please also ping @lidel and myself to ensure the proposed design is included during their 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.  ## Milestones & Funding -**Total Funding Amount:** List the total proposed funding amount (currently in USD, eventually can be a distribution between USD/FIL)+**Total Funding Amount:** $5,000 -**Milestones:** Make sure that the values in the Funding column add up to the Total Funding Amount listed above.--| Milestone No. | Milestone Description | Funding | Estimated Timeframe |-| --- | --- | --- | --- |-| 1 | Example milestone | $X | Y weeks |-| 2 | Example milestone | $X | Y weeks |-| 3 | Example milestone | $X | Y weeks |+**Milestones:** An initial $500 will be granted to whoever proposes the best design as shared in `Detailed Requirements & Constraints`. The remaining $4,500 will be granted upon completion of the PR.  ## Acceptance Criteria -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. +Handshake names like http://namebase/ should resolve in IPFS-comptaible applications like the IPFS Companion extension, Brave browser, and Opera browser, etc.  ## Resources -Link any resources that might be helpful for an implementer who is working on this project.+- 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+- "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 how DNS in go-ipfs works now.

"mental model of how"

johnnywu-namebase

comment created time in 23 days

Pull request review commentipfs/devgrants

Create handshake-fallback-resolver.md

  ## Project Description -Please fill in details about what you're trying to build. What is the purpose/context? What are the high-level requirements?+Given the goals of: -This section should be 2-3 paragraphs long.+- IPFS doesn’t want to choose winners+- IPFS wants to decouple from ICANN and support non-ICANN namespaces+- IPFS wants to avoid introducing privacy and security risks in implicit defaults+- IPFS wants the alternative namespaces to be DNS compatible. Preferably they can use DoH endpoints++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. 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).++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.  ## Value -Please describe why the work that will come out of this RFP is valuable for the IPFS ecosystem.+By implementing a fallback resolver to distributed namespaces like Handshake, IPFS makes the decentralized web massively more accesibility to anyone already using an IPFS-compatible application, which in turn accelerates the adoption of a fully distributed web.

"massively more accessible"

johnnywu-namebase

comment created time in 23 days