Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

IPFS data spec update: schema_name and schema_version

See original GitHub issue


I suggest adding two new fields to the IPFS JSON for

  • schema_name: the name of the schema that is being used. (example: bounties_network, gitcoin )
  • schema_version: the version of the schema that is being used (ex: 0.1, 0.11, 1.0)


formalizing these two fields would recognize the business case reality that different bounty networks are likely to have different use cases and thereby, different metadata they need to store about the bounties.

by recognizing this implicit fact explicitly, different implementers of the bounties network:

  1. can have different JSON metadata formats (instead of trying to all work around one format).
  2. could formalize their JSON formats explicitly, allowing more easy management of said formats.
  3. can manage the versioning of their formats as their business needs evolve.
  4. ingestion of bounties across networks becomes easier because there is documentation of each networks presumed metadata.

suggested next steps

  1. accept schema_name / schema_version as standard parts of the IPFS json
  2. publish samples of both the bounties_factory and gitcoin formats to this repo
  3. define and publish documentation on required fields for each schema (title, description, sourceFileHash, etc).
  4. maintain those specifications over time as our business needs evolve.

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:26

github_iconTop GitHub Comments

mbeylincommented, Jan 23, 2018

Adding in tokenAddress and tokenName now. I think however we should change it to tokenSymbol instead, since what we’re showing isn’t actually the longer form name, but in fact the symbol (right?)

Also i think having optional fields in the same place as the main payload simplifies things. If platforms add extra fields it won’t step on anyone’s toes.

mbeylincommented, Feb 21, 2018

taken care of in #23

Read more comments on GitHub >

github_iconTop Results From Across the Web

IPFS-LD - Linked Data · Issue #36 - GitHub
I will use this issue to note thoughts regarding Linked Data in the IPFS context. Note this is just brainstorming. The power of...
Read more >
COD Common Record XML Schema Version 4.0e (Updated ...
19, 2021, we updated the COD Common Record XML Schema Version 4.0e posting to replace the “COD Common Record 4.0e in XML Code”...
Read more >
Enhanced Asset Information Specification - Counterparty
Below I have come up with a basic schema which allows asset owners to specify much more information about their token, including owner...
Read more >
Part of the IFC schema (Version 4, Addendum 2)
This paper proposes a Blockchain-based BIM data provenance model to support information exchange in construction projects. By testing the solution in a real- ......
Read more >
Indy DID Method Specification - Hyperledger
This specification covers how DIDs on an Indy ledger are managed and the operations for creating, reading, updating, and deleting DIDs.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found