-
Notifications
You must be signed in to change notification settings - Fork 30
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
WIP: Hyperboard contract #1068
base: develop-contracts
Are you sure you want to change the base?
WIP: Hyperboard contract #1068
Conversation
Just added a function to update the base URI as well, I am not sure if updating the base URI is a good idea or not. I can remove it if needed. |
8ffae95
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this! Most of the comments above are not breaking, and since the hyperboard is currently 'only' a registry I think this a good PoC to roll with. There are things to mature, but I don't see any big issues at the moment.
When this actually rolls out, we can give the code a more thorough review. Plus add the test cases for the Graph ;)
} | ||
|
||
|
||
type Hypercert @entity { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the purpose of this specific entity? From my understanding, the hyperboard links to a claim (e.g. an uncertified hypercert), which in this case can be refered to using the Claim entity
/// @author Abhimanyu Shekhawat | ||
/// @notice This is an NFT for representing various hyperboards | ||
contract Hyperboard is ERC721, ERC721URIStorage, ERC721Enumerable, Ownable, EIP712 { | ||
string public subgraphEndpoint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This variable is used for the dynamic NFT we specced out, correct? I think this setup is tricky because a change in the subgraph endpoints would result in a breaking change. To compare, an ipfs:// URL can be mapped to a gateway, but subgraphs don't follow these kind of standards I believe.
One solution could be a central registry for the IPFS uri so that the rendered page and the subgraph URL can be governed on a protocol level.
nvm, the contract is the central registry. Still, maybe we can find a way around something like the Graph.
What do you think?
P.S. this is something beyond PoC scope, but we should be aware of the implications.
Update hyperboard deployment script
This is a WIP PR, so I will be pushing more things to it with time.
HyperboardNFT contract mints new Hyperboard NFT, it prepares a URI using the base IPFS hash of the webpage + some URL parameters that the webpage can use to show the data.