Store extended contribution details in a separate IPFS document #154

New Issue

raucao · 2019-07-18T14:03:40Z

raucao commented

2019-07-18 14:03:40 +00:00

(Migrated from github.com)

As discussed during the last weekly call, we should extract the extended contribution details from the main contribution document and store them in a separate document, which can be side-loaded only when necessary. At the moment, no client actually needs the extended details at all, and in kredits-web, we will only need them when looking at a specific contribution.

Reasoning

Consider a typical GitHub pull request document: https://ipfs.io/ipfs/Qmbd62E98ikysm2vzgj89w1b4QutdWP1oN6YFjLqphyL7D

The size of this is ~19KB. However, the only necessary information for most clients is:

{
  "@context": "https://schema.kosmos.org",
  "@type": "Contribution",
  "contributor": {
    "ipfs": "QmbZhFsoANaGAWCV3pcpYKiGLEyJKbFcgD8ynhCWp93YBk"
  },
  "date": "2019-07-15",
  "time": "16:54:56Z",
  "kind": "dev",
  "description": "67P/kredits-web: Use ember-auto-import instead of ember-browserify"
}

A cool 309 bytes in this case, which is ~1.6% of the current document.

So the idea is to do the same as with the contributor hash (which isn't currently used by any client actually, but that's irrelevant here):

{
  "@context": "https://schema.kosmos.org",
  "@type": "Contribution",
  "contributor": {
    "ipfs": "QmbZhFsoANaGAWCV3pcpYKiGLEyJKbFcgD8ynhCWp93YBk"
  },
  "date": "2019-07-15",
  "time": "16:54:56Z",
  "kind": "dev",
  "description": "67P/kredits-web: Use ember-auto-import instead of ember-browserify",
  "details": {
    "ipfs": "QmbZhFsoANaGAWCV3pcpYKiGLEyJKbjnskjdnscnKJDSNVK"
  }
}

Pinning / backup / distribution

I would propose to then also extend the ipfs-pinner to recognize any generic JSON objects with a "ipfs" property and pin those hashes automatically as well.

As discussed during the last weekly call, we should extract the extended contribution details from the main contribution document and store them in a separate document, which can be side-loaded only when necessary. At the moment, no client actually needs the extended details at all, and in kredits-web, we will only need them when looking at a specific contribution. ## Reasoning Consider a typical GitHub pull request document: https://ipfs.io/ipfs/Qmbd62E98ikysm2vzgj89w1b4QutdWP1oN6YFjLqphyL7D The size of this is ~19KB. However, the only necessary information for most clients is: ```json { "@context": "https://schema.kosmos.org", "@type": "Contribution", "contributor": { "ipfs": "QmbZhFsoANaGAWCV3pcpYKiGLEyJKbFcgD8ynhCWp93YBk" }, "date": "2019-07-15", "time": "16:54:56Z", "kind": "dev", "description": "67P/kredits-web: Use ember-auto-import instead of ember-browserify" } ``` A cool 309 bytes in this case, which is ~1.6% of the current document. So the idea is to do the same as with the contributor hash (which isn't currently used by any client actually, but that's irrelevant here): ```json { "@context": "https://schema.kosmos.org", "@type": "Contribution", "contributor": { "ipfs": "QmbZhFsoANaGAWCV3pcpYKiGLEyJKbFcgD8ynhCWp93YBk" }, "date": "2019-07-15", "time": "16:54:56Z", "kind": "dev", "description": "67P/kredits-web: Use ember-auto-import instead of ember-browserify", "details": { "ipfs": "QmbZhFsoANaGAWCV3pcpYKiGLEyJKbjnskjdnscnKJDSNVK" } } ``` ## Pinning / backup / distribution I would propose to then also extend the `ipfs-pinner` to recognize any generic JSON objects with a "ipfs" property and pin those hashes automatically as well.

raucao commented

2019-07-18 14:06:46 +00:00

(Migrated from github.com)

@fsmanuel Interested in taking a stab at this perhaps?

raucao added the

feature

ui/ux

labels 2022-10-29 11:42:16 +00:00

raucao added the

scaling

label 2022-10-29 11:43:19 +00:00

raucao referenced this issue