Skip to content
This repository has been archived by the owner on Aug 2, 2021. It is now read-only.

multihash support in swarm #166

Closed
cobordism opened this issue Dec 13, 2017 · 9 comments
Closed

multihash support in swarm #166

cobordism opened this issue Dec 13, 2017 · 9 comments

Comments

@cobordism
Copy link

We are often asked about multihash support.

We should have a proper discussion about pros and cons at least. I suggest this issue shall be the place for that discussion until someone formulates this as an EIP (or is it SIP?)

@cobordism cobordism added this to To do in Swarm Core - Sprint planning via automation Dec 13, 2017
@cobordism
Copy link
Author

I'll start:

Pros: allows multi-hashes to be stored in ENS making it easy to use ENS with swarm and ipfs and other p2p storage solutions.

Cons: Makes ENS registration a little more expensive (store two words instead of one because multihash is longer than a swarm hash)

@cobordism cobordism moved this from To do to discussions in Swarm Core - Sprint planning Dec 13, 2017
@Arachnid
Copy link

I'd like to see Swarm move to Multihash for ENS, at least, because it would allow us to have a single resolver profile for all content-addressed networks, and because it provides an upgrade path for changes in hash function.

@nagydani
Copy link

Is the proposal only for root hashes or also for intermediate chunk hashes in low-level Merkle trees?

@cobordism
Copy link
Author

I must admit that I'm not entirely sure how multihashes look. I understand that it is a hash with metadata about what type of hash it is.
Thus I thought we could keep the internal structure of swarm intact and just use the longer multihashes (swarm hash + extra data?) as roothashes stored on ENS.

@nolash
Copy link
Contributor

nolash commented Dec 14, 2017

the metadata bytes should be a separate data field from the hash value itself

storing metadata should be optional, meaning I should be able to only pay for / use 32 bytes if I want to.

As long as we open this discussion, another question that follows is should ENS allow for even longer data values than this? In fact, should it allow for arbitrary values? Let's say someone comes along who wants to use ENS with some scheme that uses 512 bit or 1024 bit hashes? The latter would thus require 5 data fields.

Yes, internally in swarm we should definitely keep the hash as-is.

@cobordism
Copy link
Author

should ENS allow for even longer data values

That's a question about the resolver contracts. As such it is possible to write a resolver that stores any data.
The current discussion pertains to the content() field of the default resolver contract. How can we use it to store hash such that we can easily use Swarm and IPFS and other hash-based storage networks?

@zelig
Copy link
Member

zelig commented Dec 30, 2017

ok I dont see a problem with using multihash in ENS.
As long as intermediate hashes of the swarm hash as well as hashes in manifest entries remain 32 byte long

@cobordism
Copy link
Author

but doesn't the ens entry have to be a swarm root hash?

@cobordism
Copy link
Author

@zelig
as we discussed at the cafe today: let' s do it:
#186

Swarm Core - Sprint planning automation moved this from discussions (SIPs) to Done Jan 2, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Development

No branches or pull requests

5 participants