New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where should people find the hashes? [Discovery] #4

Open
VictorBjelkholm opened this Issue Mar 28, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@VictorBjelkholm
Member

VictorBjelkholm commented Mar 28, 2016

How can people find new modules with their hashes?

You have to trust the place where you get them from.

One way could be to have signed git tags that includes the hash of that version.

Another way could be to have a platform for this, maybe it's possible to use the npm registry for it?

@LeoTindall

This comment has been minimized.

Show comment
Hide comment
@LeoTindall

LeoTindall Mar 29, 2016

A package system really has three parts:

  1. a list of packages and their metadata, and software to retrieve it
  2. a repository of package content data code (NPM index, PyPI) or binaries (Debian repositories)
  3. a dependency resolver

IPFS solves problem 2. any tool aiming to be universal must solve problem 3 (which, while not trivial, is not particularly hard and is a solved problem) and allow its solution to 1 to be customized.

So, what I'm saying is, rather than making a universal tool, we should make a pluggable module which can be added to tools like APT, yum, pip, npm, etc that allows IPFS hashes to be substituted for URLs. This leaves problem 1 unsolved but creates the most immediate solution. Problem 1 can be solved at a later time; it is more a matter of preference than a technical issue.

LeoTindall commented Mar 29, 2016

A package system really has three parts:

  1. a list of packages and their metadata, and software to retrieve it
  2. a repository of package content data code (NPM index, PyPI) or binaries (Debian repositories)
  3. a dependency resolver

IPFS solves problem 2. any tool aiming to be universal must solve problem 3 (which, while not trivial, is not particularly hard and is a solved problem) and allow its solution to 1 to be customized.

So, what I'm saying is, rather than making a universal tool, we should make a pluggable module which can be added to tools like APT, yum, pip, npm, etc that allows IPFS hashes to be substituted for URLs. This leaves problem 1 unsolved but creates the most immediate solution. Problem 1 can be solved at a later time; it is more a matter of preference than a technical issue.

@VictorBjelkholm

This comment has been minimized.

Show comment
Hide comment
@VictorBjelkholm

VictorBjelkholm Apr 2, 2016

Member

@SilverWingedSeraph thanks for the input, but as I said in a different issue (#6), you're probably looking for a different project, solving a different problem ( https://github.com/whyrusleeping/gx ).

Many thanks for the input though! It's valuable to have the breakdown and your feedback on this.

Member

VictorBjelkholm commented Apr 2, 2016

@SilverWingedSeraph thanks for the input, but as I said in a different issue (#6), you're probably looking for a different project, solving a different problem ( https://github.com/whyrusleeping/gx ).

Many thanks for the input though! It's valuable to have the breakdown and your feedback on this.

@VictorBjelkholm

This comment has been minimized.

Show comment
Hide comment
@VictorBjelkholm

VictorBjelkholm Apr 2, 2016

Member

Current thinking I have about this, is kind of lose but might work (but slow!), is to randomly walk across the network, check found hashes for a package.json and read the name + version + author. Then we could build a index but probably, it'll be very slow to update...

Member

VictorBjelkholm commented Apr 2, 2016

Current thinking I have about this, is kind of lose but might work (but slow!), is to randomly walk across the network, check found hashes for a package.json and read the name + version + author. Then we could build a index but probably, it'll be very slow to update...

@hugozap

This comment has been minimized.

Show comment
Hide comment
@hugozap

hugozap Apr 5, 2016

You have to trust the place where you get them from.

Why is this a requirement? If the packages are signed and the cli tools can verify / display author identity information then multiple independent list sites could exist and it would not matter. Introducing a trust requirement could defeat the purpose of some of the initial assumptions.

Some people could build index sites with their authored and favorite module hashes. Others could build an index scraping the hashes from the network like you suggest, but maybe this problem should be left to the community to solve?

Some services like https://onename.com/ could be useful to verify the author identity, so it won't matter where the hash is listed, as long as the final user can verify the package author identity

( I'm very excited about descentralized ideas and tools, but I'm just starting, so I may be doing wrong assumptions or have conceptual errors, sorry if that's the case! )

hugozap commented Apr 5, 2016

You have to trust the place where you get them from.

Why is this a requirement? If the packages are signed and the cli tools can verify / display author identity information then multiple independent list sites could exist and it would not matter. Introducing a trust requirement could defeat the purpose of some of the initial assumptions.

Some people could build index sites with their authored and favorite module hashes. Others could build an index scraping the hashes from the network like you suggest, but maybe this problem should be left to the community to solve?

Some services like https://onename.com/ could be useful to verify the author identity, so it won't matter where the hash is listed, as long as the final user can verify the package author identity

( I'm very excited about descentralized ideas and tools, but I'm just starting, so I may be doing wrong assumptions or have conceptual errors, sorry if that's the case! )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment