BuildHub | Devpost

on-chain pull requests
renaming forks
attribution ~ indexing forks

INSPIRATION

Builders need on-chain processes to successfully connect and collaborate on the blockchain operating system. For example, if a user's Near Social profile does not include their GitHub account or any contact information, contributors might have to tag them in a message to notify them about suggestions and proposed changes, which would normally go through pull requests or discussion threads.

The mission of BuildHub is empowering open web developers to coordinate around highly reusable common goods: infrastructure, apps, tooling, and other solutions.

FUNCTIONALITY

This project introduces new capabilities for builders on the BOS:

Key Features

Merging On-chain Pull Requests
Indexing Forks (on-chain)
Reverting Changes
Organizing Discussions
Powering Attribution

Widgets

repository
summary
source
discussion
update
fork
requests
merge

Note: when you navigate to a repository, there is a default src (james.near/thing/directory), which offers a sample. You can pass in other sources through props to view details of anything else.

HOW IT'S BUILT

I decided to leverage the ComponentDetailsPage (controlled by the root near account), in order to improve developer experience and facilitate possible integrations.

First, I abstracted that details page to work with any type of BOS data, not only widgets. Then, I added support for on-chain pull requests via notifications, which enables users to request updates to be merged by creators of widgets and other things. Next, I enabled reverting changes based on the blockheight of a previous iteration listed in the commit history. Finally, I developed a way to index forks, unlocking the potential for gateway-agnostic tracking of valuable activity.

CHALLENGES

Each gateway (near.social, near.org, etc.) has its own idiosyncrasies, which make it somewhat difficult to implement consistent UI / UX across gateways. Additionally, I dealt with a specific problem involving renamed forks, which require tracking both upstream and downstream for linked lists.

ACCOMPLISHMENTS

I've managed to create several features that I'm going to use in collaborations. Plus, I'm gathering feedback from hackers to ensure applicability for them. Now I better understand the ins and outs of a SocialDB contract.

LESSONS LEARNED

Exploring the SocialDB led to many useful insights. One worth highlighting is the idea of graphs with many different versions of widgets, etc. This promotes opportunities for groups to build resources together. Anyone could fork something, enhance it, and propose updates. We could also visualize these connections to identify opportunities for cooperation.

FUTURE PLANS

Let's experiment with attribution systems that help everyone understand who is building valuable components in terms of reusability, integrability, and other important factors. This can provide the basis of a retroactive compensation / funding model to sustain public goods made for open web developers.

I'd love to work with DevHub to evolve this product!