feat(x/data)!: support public resolvers for IPFS support

[aaronc]

Description

This PR:

• adds the bool public field to MsgDefineResolver
• renames MsgDefineResolver manager to definer
• renames MsgRegisterResolver manager to signer

These last two proto breaking changes are okay because we are currently working with the as of yet unreleased regen.data.v2 API.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[clevinson]

@aaronc So I prematurely approved, and then after closer inspection actually have a few questions about how we expect this be used by users.

[clevinson]

Who would be the manager for the ipfs: resolver?

Can you elaborate on how you would expect this to work? In reading the documentation for the manager field, it seems like only the manager of a resolver can register data to a given resolver.

So as I understand it, this PR implies that each user wanting to host data on IPFS would define their own resolver named ipfs: ?

I wonder if it would make more sense to instead extend the MsgRegisterResolver() message to have an enum field called resolver_type. we could have the default / 0 value of that enum be HTTP_RESOLVER, and 1 = IPFS_RESOLVER. This way, if we want to support other decentralized resolvers that are similar to IPFS in the future, we could just extend this enum?

[aaronc]

I think you're right. So, there's another step of work to do here. I don't think it will be too hard. I will close this, work on that and ping you when it's R4R again.

[aaronc]

@clevinson I've updated this PR to support marking a resolver as public to support IPFS. Please take a look again when you get a chance.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.91%. Comparing base (3b21ecd) to head (be0f559).
Report is 1 commits behind head on main.

❗ Current head be0f559 differs from pull request most recent head 1d53b64. Consider uploading reports for the commit 1d53b64 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2098   +/-   ##
=======================================
  Coverage   72.90%   72.91%           
=======================================
  Files         240      240           
  Lines       13860    13865    +5     
=======================================
+ Hits        10105    10110    +5     
  Misses       3016     3016           
  Partials      739      739           

Files	Coverage Δ
x/data/server/msg_define_resolver.go	72.00% <100.00%> (+5.33%)	⬆️
x/data/server/msg_register_resolver.go	69.23% <100.00%> (+0.80%)	⬆️

[clevinson]

Reading through the updates, it looks like the approach you're intending for here is still that the defining of an IPFS resolver is something that is done in state (via someone defining an IPFS resolver via a MsgDefineResolver() tx).

So is your idea that someone from the RND team would submit a tx define a resolver for IPFS shortly after this software upgrade happens? Or perhaps we would just bake that into a state migration and ship it along w/ the software upgrade?

In either case though, I don't think we have a uniqueness constraint on resolver_url, so there's nothing preventing multiple users from creating new "IPFS" resolvers with the same resolver_url and public = true. If and when this happens, for a user wanting to register their data to IPFS, they now would be presented with several different options of which resolvers to register with, all seemingly the same.

I'm just trying to unpack this here and make sure you're tracking this edge case and that you think this is OK @aaronc. Personally it feels a bit clunky and I'd prefer an approach where as a user wanting to register data to IPFS, there is one clear way to do that, and there's no chance of several different "resolvers" in state that all in practice mean identical things. But if there are reasons why you thinks approach is better than what I wrote in my comment (#2098 (comment)), which I think addresses the issue of end-users only having at most 1 way to register their data with IPFS, let me know.

[aaronc]

There is a uniqueness check on the resolver,manager pair even when manager is nil in the case of being public. So I don't think double definitions are possible. I can add a test case to check

[aaronc]

@clevinson I added a test here which demonstrates that a public resolver URL can only be defined once.

[paul121]

This LGTM, just one question to clarify how an IPFS CID would be used.

[paul121]

Content hashes must be adapted to IPFS's CID format.

Just want to clarify how this works.. For both raw and graph content hashes, the hash will be set to the full cid, where the cid was generated using either the multicodec raw (0x55) or multicodec rdfc-1 (0xb403)?

[clevinson]

The content hash on Regen would still be the same as if it were registered w/ an HTTP resolver. I think this comment just communicates that users must take the resulting Regen IRI, and convert it to a specific IPFS CID in order to fetch the data from the IPFS network.

[aaronc]

Exactly

[paul121]

Ah thanks, this makes more sense. With an example I think this would be very clear. Hopefully soon...