Consolidate User Registry and Establish Processes for Keeping it Up to Date

[flyingzumwalt]

Background

Piece: awesome-ipfs
We have also had the awesome-ipfs repo for years, where people can submit their own projects (read the contribution instructions at https://github.com/ipfs/awesome-ipfs#contribute-to-this-list), but that repo is not broadly publicized and has been intermittently used. It became much more useful and compelling when @hacdias and @victorbjelkholm made awesome.ipfs.io -- a site that renders the info from awesome-ipfs as a website that you can browse through.

Piece: User Registry in Airtable
In early 2017 @mishmosh created an initial version of the IPFS User Registry in Airtable [Note: this document isn't public. This note discusses why, and points to solutions.]. It's designed to be a more complete user registry than awesome-ipfs, with additional information about those users' needs, their location along the adoption curve, etc. It has been a useful resource for some teams but we never pushed to make the list of users complete and the sheet hasn't gotten broad adoption from the teams who could use this info.

Piece: Google Forms experiment
In the leadup to the 2018 Developer Meetings we ran an experiment with Google Forms, using a User Registry entry form to gather more detailed information for the User Registry. About 40 projects submitted information there. The information was useful for prioritizing applicants who wanted to attend the developer meetings but we don't think people will be inclined to keep filling out a form like that on an ongoing basis -- we have gotten better results with awesome-ipfs.

Putting them Together
These three lists of IPFS Users have never been consolidated anywhere. There are definitely overlaps, but there are also many projects that appear in one place but not the others. There are also a huge amount of users who we know about but haven't listed in any of these places.

• It definitely makes sense to keep using awesome.ipfs.io and encouraging people to enter their info into awesome-ipfs.
• The working groups and product owners need a way to also track additional information about some users (ie. if they tell us privately that they're preparing for a big launch, or if someone reaches out privately about possibly adopting IPFS)

What to do

• Confirm that we will use awesome-ipfs as the venue for publicly listing IPFS users. Promote it and update awesome.ipfs.io as necessary (ie. add ability to feature projects)
• Choose where to track an internal copy of this User Registry (ie. should we keep using the airtable?)
• Consolidate the information, making sure the internal registry is complete and making sure awesome-ipfs reflects a resonably complete listing of publicly known projects
• Define processes for keeping the User Registry up to date

ref #218

[mikeal]

Choose where to track an internal copy of this User Registry (ie. should we keep using the airtable?)

We could probably automate the creation of new rows in Airtable every time we get a new awesome entry.

Consolidate the information, making sure the internal registry is complete and making sure awesome-ipfs reflects a resonably complete listing of publicly known projects

With one caveat. We don't want to put projects up unless the projects want the attention/promotion. This doesn't mean we have to wait for them to submit something to awesome-ipfs but it does mean we need to log an issue with them or find some way of getting their permission before posting. This obviously isn't the case for our internal list.

Define processes for keeping the User Registry up to date

It shouldn't be too hard to make sure new entries in awesome-ipfs but it's quite difficult to maintain any kind of sync between them with the details of the project if awesome-ipfs is improved because the airtable list is expected to have additional private data mapped onto the entries.

Google Forms experiment

We could create a form that literally opens a pull request to add use cases to awesome-ipfs. If what we want is a lower barrier for submissions that we can include when we do events we can just map that interface on top of the current "source of truth" which is the awesome-ipfs list.

[meiqimichelle]

Just a 👏 here -- thank you for articulating this and pulling this background of each piece into one issue @flyingzumwalt , and I'm excited about your ideas for this @mikeal ! 👍 on your thoughts to automate awesome.ipfs.io entries --> AirTable, and other ideas to keep this info organized and relatively up to date.

[daviddias]

I would also like to include https://github.com/ipfs/ipfs/issues?q=is%3Aopen+is%3Aissue+label%3A%22applications+of+ipfs%22 as one more place we created and that has information about specific categorizes of applications on top of IPFS.

I'm 100% onboard on consolidating all these lists and diving deeper in each category so that WGs and the rest of the community can feel that they are well informed about user needs. That said, the concern in which why the User Registry is not public is still valid.

I see valuable in having the information presented in 3 formats:

• awesome.ipfs.io - Community generated list, includes applications, features, datasets and more. Everyone is welcome to add items to the list but the reality is that these items won't include what are the requirements they have from IPFS
• Public registry of Categories of Applications of IPFS - This list (which can be Github issues or something else) would be a summary of what the applications in each category are trying to do and how IPFS fits on their critical path for success, identifying clearly what IPFS needs to achieve in order for the Category to be successful (without listing Company names, maturity of the projects, etc).
• Semi-Private (open to direct collaborators that are doing User Research) User Registry - The same categories as above but this time with specific company needs an channels between IPFS org and these users so that we can keep each other informed of what are the priorities and blockers.

[flyingzumwalt]

Important addition: https://app.co/ipfs lists blockchain-based dapps that use IPFS. Specifically within the blockchain space, this list is likely to be consistently far more complete than awesome-ipfs or something we maintain ourselves.

[mikeal]

So, I don't think it's sustainable to have several sources of truth.

If we want to be able to maintain this we need to have a single open "root" that contains all the relevant public data. If we have additional data with additional access controls those resources need to be able to pull data from the root source and add additional protected data.

                                  Open Contributions
                                          +
                                          |
                                          |
                                          |
         +-------------+           +------v-------+
         |             |           |              |
         | app.co/ipfs +-----------> Awesome IPFS |
         |             |           |              |
         +-------------+           +------+-------+
                                          |
                               +----------v------------+
                               |                       |
Private Contributions +--------> Private User Registry |
                               |                       |
                               +-----------------------+

@diasdavid what is in the "Public registry of Categories of Applications of IPFS" that can't be in awesome IPFS?

[daviddias]

@diasdavid what is in the "Public registry of Categories of Applications of IPFS" that can't be in awesome IPFS?

It's pretty much an entirely different presentation. Awesome IPFS is a collection of cards with fantastic uses of IPFS. The User Registry contains way more detailed information about a Category of Application. The Awesome IPFS is awesome as a one stop shop for all the exciting things that keep popping up, from demos, talks, datasets and so on, while the User Registry actually collects and curates info from each Category and informs the contributors to the Protocol of a large set of needs and how they different from category to category.

[mikeal]

It's pretty much an entirely different presentation.

Can we consolidate the data into a single source and just display it differently in Awesome IPFS?

[parkan]

100% agree about having a single source of truth (or at least automated synchronization)

from my perspective, the Collaborations Tracker can very easily build on the User Registry (more details in the collab repo)

who currently owns the User Registry? are there any objections to me prototyping a collaborations tracker on the same airtable base?

EDIT: ok, the registry had been kind of abandoned and I'm tentatively fostering it try try out a tracker built on top

+1 for pushing awesome-ipfs entries in there