profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/momack2/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.
MollyM momack2 @protocol @ipfs @libp2p Www.mollymackinlay.com @ipfs Project Lead @filecoin Network Lead. Building #web3 @protocol to be #p2p & #LocalFirst.

filecoin-project/community 171

Filecoin community and ecosystem channels, discussion forums, and more

filecoin-project/FIPs 88

The Filecoin Improvement Proposal repository

ipfs/devgrants 70

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

jbenet/data 56

package manager for datasets

ipfs/local-offline-collab 44

Local Offline Collaboration Special Interest Group

libp2p/website 23

Webpage of the libp2p project. A multi protocol approach for a interoperable network stack that follows the 'self description' in favor of assumptions

jbenet/datadex 21

a dataset index

Digital-MOB-Filecoin/QABot 14

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

filecoin-project/sentinel 14

A Filecoin Network Monitoring and Analysis System

push eventprotocol/web3-dev-team

jnthnvctr

commit sha 629fca18f819ab59f2c2dbe2a40af3445a1befcf

Update fil-storage-homepage.md

view details

push time in 3 hours

push eventprotocol/web3-dev-team

jnthnvctr

commit sha 84d1a3516b8347dd51c4e89db72b833fa1ce846a

Rename fil-storage-homepage to fil-storage-homepage.md

view details

push time in 3 hours

push eventprotocol/web3-dev-team

jnthnvctr

commit sha cfa9e73492e66058daf3dc0323d2cb073a01f4ff

Create fil-storage-homepage

view details

push time in 3 hours

create barnchprotocol/web3-dev-team

branch : jvictor/fil-storage-homepage

created branch time in 4 hours

push eventprotocol/web3-dev-team

Alan Shaw

commit sha 7a2d2ec4931dcc250bceff26cd8a91d634665dfa

docs: add diagrams

view details

push time in 6 hours

delete branch ipfs/local-offline-collab

delete branch : readme-updates

delete time in 12 hours

push eventipfs/local-offline-collab

Teri Chadbourne

commit sha 44e9ceb7f6a314f12706afbda6107ef02ffcb3b8

Update README.md

view details

Teri Chadbourne

commit sha f4f6add6310ba3cc0c30f4c77df9ec6ee45915be

Merge pull request #28 from ipfs/readme-updates Update README.md

view details

push time in 12 hours

PR merged ipfs/local-offline-collab

Update README.md

Updating to reflect our new on-demand meeting schedule and highlight channels for async discussion. Very open to tweaks!

+17 -8

0 comment

1 changed file

terichadbourne

pr closed time in 12 hours

PR opened protocol/web3-dev-team

Create filecoin-strorage-tutorials-docs.md

Initial draft of filecoin.storage docs. More details in the Notion doc: https://www.notion.so/protocollabs/filecoin-storage-tutorials-docs-41d9cd9ed170416e8b4c48192b5f6b02

+31 -0

0 comment

1 changed file

pr created time in 19 hours

create barnchprotocol/web3-dev-team

branch : filecoin-strorage-docs

created branch time in 19 hours

push eventfilecoin-project/FIPs

nemo

commit sha 16f00fb16068252ff723fbd8372dd16de14361a2

fix: add comm_rs to the aggregate/verify method signatures

view details

Jennifer

commit sha dc1a6248bab6e4b297775c93d680b0d91cc83f88

Merge pull request #115 from cryptonemo/fip13-api-update-2 fix: add comm_rs to the aggregate/verify method signatures

view details

push time in 21 hours

pull request commentfilecoin-project/FIPs

fix: add comm_rs to the aggregate/verify method signatures

This PR is required to update the API signatures after the finalized SnarkPack audit. The comm r's are now required in the aggregation calls, and they were previously missing.

cryptonemo

comment created time in 21 hours

push eventprotocol/web3-dev-team

Alan Shaw

commit sha f23ca1e143035cdf735ce410a9541a6ff9023cae

docs: update to reflect actual strategy

view details

push time in a day

PR closed protocol/web3-dev-team

Proposal: Gateway++ Phase 1 Nitro
+93 -0

7 comments

1 changed file

mikeal

pr closed time in a day

pull request commentprotocol/web3-dev-team

Proposal: Gateway++ Phase 1

this is being superceeded by filecoin.storage

mikeal

comment created time in a day

PR closed protocol/web3-dev-team

Reviewers
initial proposal for maintaining index of content on miners Bedrock ease:low impact:high
+92 -0

5 comments

1 changed file

willscott

pr closed time in a day

pull request commentprotocol/web3-dev-team

initial proposal for maintaining index of content on miners

asking for project pipeline purposes -- since we have another proposal for sharded dag store that is in progress, will move this one to the project backlog (or we can close it if you think it's redundant)

willscott

comment created time in a day

pull request commentprotocol/web3-dev-team

initial proposal for maintaining index of content on miners

The sharded dag-store will accomplish the goal outlined in this proposal

willscott

comment created time in a day

pull request commentprotocol/web3-dev-team

initial proposal for maintaining index of content on miners

this project isn't currently in progress, right @willscott ?

willscott

comment created time in a day

create barnchprotocol/web3-dev-team

branch : mpp-car-native-dag-store

created branch time in a day

PR opened ipfs/team-mgmt

Update TEAMS_ROLES_STRUCTURES.md

needed to join collaborate

> A byproduct of both of these team structures achieves another important goal: making it easier for new users and contributors to subscribe to updates and get ramped up quickly to the current project focus.
**Tiger Group**

Tiger group are a small, temporary group of people usually formed to solve a specific problem or build a particularly complex feature. They frequently form when significant iteration/collaboration across team or project boundaries is required to achieve success. Once the objective is achieved, the tiger team dissolves back into their normal working groups.

Some great examples that would likely benefit from a tiger team include: a scoped collaboration between infra, go-ipfs, and Libp2p on a specific issue; a complex and involved feature on the intersection of IPFS and IPLD; or a specific time-sensitive project involving members of the community, gui, and js-ipfs working groups.

A tiger group has a DRI (directly responsible individual) that drives the team's engagement and agenda. They are responsible for initiating communication channels and ensuring the group has a unified definition of success they drive toward efficiently. Tiger teams interface through a set of temporary ad hoc communication channels (such as an IRC channel, github project, mumble standup, weekly call, email list, slack etc) to encourage quick iteration amongst teammates.

## Team Roles
+3 -3

0 comment

1 changed file

pr created time in a day

issue openedipfs/team-mgmt

Collaborate PenentrationTesting and Vulnerability invitation

<!-- Hello! To ensure this issue is correctly addressed as soon as possible by the IPFS team, please try to make sure:

  • This issue is relevant to this repository's topic or codebase.

  • A clear description is provided. It should includes as much relevant information as possible and clear scope for the issue to be actionable.

FOR GENERAL DISCUSSION, HELP OR QUESTIONS, please see the options at https://ipfs.io/help or head directly to https://discuss.ipfs.io.

(you can delete this section after reading) -->

created time in a day

Pull request review commentprotocol/web3-dev-team

Proposal: CarV2

+# CAR v2++Authors: @willscott++## What is the problem this project solves?+_Describe the status quo, including any relevant context on the problem you're seeing that this project should solve. Who is the user you're solving for, and why do they care about this problem? Wherever possible, include pain points or problems that you've seen users experience to help motivate why solving this problem works towards top-line objectives._ ++This project implements a second version of the Content addressed data ARchive format.+The goal is to provide a standardized way to take a collection of content addressed data, as currently exists in the car format, and be able to efficiently provide random access reads and appends to it.+We know through the carbs and carbon experiments that both of these are possible.++With this functionality we can avoid the need to take an existing car file and import it back into a blockstore like badger before being able to perform random access reads over it.++## Impact+_What goals/OKRs are being addressed (for w3dt, a specific program, etc.)? Why is this project important? What do we get with this project that we can't get without it?_++This project aims to impact the goals of:+- low latency retrieval from filecoin++These are core goals that the Bedrock program aims to address. ++## The idea+_Describe the proposed project solution, at a very high level. Stay at the level of the high-level requirements. Diagrams and interface descriptions can be useful, if you have any that help clarify and explain the idea._++As described in the [sharded dag store](https://docs.google.com/document/d/118fJdf8HGK8tHYOCQfMVURW9gTF738D0weX-hbG-BvY/edit?ts=60bf961f) design document we want a minimal format for carv2 consisting of

we can update to point to the spec you're working on once it's in linkable form. I think there's enough of a description in the text here that anyone wandering by can get a reasonable sense of what this project work looks like, and if they really care about the internals they're of course welcome to reach out and ask us :)

willscott

comment created time in a day

PR opened ipfs/community

docs(projects): create 4EVERLAND.md
+105 -0

0 comment

1 changed file

pr created time in a day

PR opened ipfs/community

[Project Submission] Interplanetary Contact

Looking forward to hearing from you.

I hope that I have correctly followed instructions to get this to you.

+96 -0

0 comment

1 changed file

pr created time in a day

Pull request review commentprotocol/web3-dev-team

Proposal: CarV2

+# CAR v2++Authors: @willscott++## What is the problem this project solves?+_Describe the status quo, including any relevant context on the problem you're seeing that this project should solve. Who is the user you're solving for, and why do they care about this problem? Wherever possible, include pain points or problems that you've seen users experience to help motivate why solving this problem works towards top-line objectives._ ++This project implements a second version of the Content addressed data ARchive format.+The goal is to provide a standardized way to take a collection of content addressed data, as currently exists in the car format, and be able to efficiently provide random access reads and appends to it.+We know through the carbs and carbon experiments that both of these are possible.++With this functionality we can avoid the need to take an existing car file and import it back into a blockstore like badger before being able to perform random access reads over it.++## Impact+_What goals/OKRs are being addressed (for w3dt, a specific program, etc.)? Why is this project important? What do we get with this project that we can't get without it?_++This project aims to impact the goals of:+- low latency retrieval from filecoin++These are core goals that the Bedrock program aims to address. ++## The idea+_Describe the proposed project solution, at a very high level. Stay at the level of the high-level requirements. Diagrams and interface descriptions can be useful, if you have any that help clarify and explain the idea._++As described in the [sharded dag store](https://docs.google.com/document/d/118fJdf8HGK8tHYOCQfMVURW9gTF738D0weX-hbG-BvY/edit?ts=60bf961f) design document we want a minimal format for carv2 consisting of+- a magic byte sequence to cause previous car1 libraries to properly warn they aren't using a compatible version+- a fixed length header indicating features and offsets+- the exact bytes currently in a carv1+- an index compatible with carbs++A more complete spec is described [here](https://github.com/ipld/specs/pull/248#issuecomment-833141588)++## Success/acceptance criteria (optional)+_How do we know we're done with this project? How do we know we're successful? This field is OPTIONAL for the first draft of an MPP. Sometimes this field needs to be filled out once we have more detail on the shape of the actual solution._++Initial success/acceptance criteria:+- Can read and write carv2 bytes on disk as described+- provides an efficient read/write blockstore interface+- Can export the index of a carv2 to bytes for separate storage+- Can extract the carv1 bytes from a carv2+- Can combine a carv1 and a spearate index to get carv2 equivalent behavior (and to write to a carv2 if desired)+++## Detailed plans (optional)+_Link to more detailed project plans, e.g. product requirements documents (PRDs) and technical design docs, once they have been created for this project._++Ongoing work is in the [wip/v2](https://github.com/ipld/go-car/tree/wip/v2) branch of go-car.

And a little bit in https://github.com/ipld/js-car/pull/30 .. not sure it's worthy of mention. We may not add write support any time soon to JS but we may add index reading functionality since it would fix with the existing API, and I'll probably keep pushing to that branch & PR until the spec has broad enough agreement.

willscott

comment created time in a day

Pull request review commentprotocol/web3-dev-team

Proposal: CarV2

+# CAR v2++Authors: @willscott++## What is the problem this project solves?+_Describe the status quo, including any relevant context on the problem you're seeing that this project should solve. Who is the user you're solving for, and why do they care about this problem? Wherever possible, include pain points or problems that you've seen users experience to help motivate why solving this problem works towards top-line objectives._ ++This project implements a second version of the Content addressed data ARchive format.+The goal is to provide a standardized way to take a collection of content addressed data, as currently exists in the car format, and be able to efficiently provide random access reads and appends to it.+We know through the carbs and carbon experiments that both of these are possible.++With this functionality we can avoid the need to take an existing car file and import it back into a blockstore like badger before being able to perform random access reads over it.++## Impact+_What goals/OKRs are being addressed (for w3dt, a specific program, etc.)? Why is this project important? What do we get with this project that we can't get without it?_++This project aims to impact the goals of:+- low latency retrieval from filecoin++These are core goals that the Bedrock program aims to address. ++## The idea+_Describe the proposed project solution, at a very high level. Stay at the level of the high-level requirements. Diagrams and interface descriptions can be useful, if you have any that help clarify and explain the idea._++As described in the [sharded dag store](https://docs.google.com/document/d/118fJdf8HGK8tHYOCQfMVURW9gTF738D0weX-hbG-BvY/edit?ts=60bf961f) design document we want a minimal format for carv2 consisting of+- a magic byte sequence to cause previous car1 libraries to properly warn they aren't using a compatible version+- a fixed length header indicating features and offsets+- the exact bytes currently in a carv1+- an index compatible with carbs++A more complete spec is described [here](https://github.com/ipld/specs/pull/248#issuecomment-833141588)

This is only the "spec" for the magic bytes. TODO is to replace this link with a doc I'm working on getting up in a PR in the next day or two.

willscott

comment created time in a day