You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to enable provider self registration, we need to create an account implementation that can be used when minting grid.hypr (that name is arbitrary, and we may want to use something versioned, but for now we will assume that is the top level entry of the Hypergrid namespace.
It is possible that the requirements mean that we need two account implementations, one for grid.hypr itself and another for its sub-entries.
The account implementation for the Hypergrid namespace will behave similarly to the one for the .os TLZ.
hard requirements:
Anyone will be able to permissionlessly mint a sub-entry (providername.grid.hypr)
These sub-entries should be 9 characters or more to prevent any obnoxious and noisy domain-squatting behavior.
users should not be able to mint further sub-entries (no entry.providername.grid.hypr)
nice-to-haves:
sub-entries should only allow the minting of the following data-keys: ~provider-id, ~wallet, ~price, ~description, and instructions. There should be no restriction on what can be put in those data keys or how many times they can be updated, but no other data keys should be permitted (note that per Remove ~provider-name field from protocol #30 we're removing the ~provider-name data key from the protocol entirely as it is made redundant by the entry name itself)
we should be able to whitelist addresses that are able to subsequently mint sub-entries underneath the provider entries themselves. we'll use this feature as a means of endorsing "official" or otherwise noteworthy providers, so something like endorsement.providername.grid.hypr, which could only be minted by us, will serve as a kind of official badge. This feature is particularly low priority however, since we can always just stand up a list of "official" providers elsewhere onchain (or even fetch it offchain).
In order to enable provider self registration, we need to create an account implementation that can be used when minting
grid.hypr(that name is arbitrary, and we may want to use something versioned, but for now we will assume that is the top level entry of the Hypergrid namespace.It is possible that the requirements mean that we need two account implementations, one for
grid.hypritself and another for its sub-entries.The account implementation for the Hypergrid namespace will behave similarly to the one for the
.osTLZ.hard requirements:
providername.grid.hypr)entry.providername.grid.hypr)nice-to-haves:
~provider-id,~wallet,~price,~description, andinstructions. There should be no restriction on what can be put in those data keys or how many times they can be updated, but no other data keys should be permitted (note that per Remove ~provider-name field from protocol #30 we're removing the~provider-namedata key from the protocol entirely as it is made redundant by the entry name itself)endorsement.providername.grid.hypr, which could only be minted by us, will serve as a kind of official badge. This feature is particularly low priority however, since we can always just stand up a list of "official" providers elsewhere onchain (or even fetch it offchain).