-
Notifications
You must be signed in to change notification settings - Fork 27
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
feat: add CType block number support #694
Conversation
54ef85f
to
c41855a
Compare
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.
Looks reasonable
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.
I would argue that CType.fromChain
is not following the original convention any more, according to which fromChain
functions are decoders. I'd say we rename it and remove the necessity of calling api.query.ctype.ctypes
before calling it (as it performs state reads anyway). I'm undecided whether the original fromChain
should be kept, which would simply return a block number and ctype owner.
*/ | ||
export function fromChain(encoded: Option<AccountId>): DidUri { | ||
return Did.fromChain(encoded.unwrap()) | ||
export async function fromChain( |
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 used to be a simple decoder (which frankly I think we didn't really need). Given this huge extension in functionality, I'm in favour of replacing this with something like lookupFromChain
, which does what this does but additionally calls api.query.ctype.ctypes
internally on the hash extracted from the ctype id.
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.
I also thought about it, and wanted to do the same for the public credentials, since we do something very similar. In my opinion, we should get rid of the need to call api.query
or api.call
for those places that need to do something else with the result anyway, namely ctypes and public credentials. What do you think?
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.
As far as they are comparable, yes, that would be my preference. I know very little about how it's done with the public credentials though
I agree that the code doesn’t really fit the name |
If we have a similar case with the public credentials, I'd agree it would be good to rename/change that as well. |
I see your point guys, but I also think that considering changing the approach we use for block-based information retrieval is out of scope of this PR. Definitely having an RPC endpoint that clients can call could be beneficial, but we need to remember that RPC methods and types need to be manually upgraded anyway whenever the client is updated, which I would argue is even less "clear" than a runtime update since there could be nodes running different versions of the client software, and since the polkadot library does not support versioning for RPC calls, we would have the same issue of "forcing" node operators to upgrade anyway. |
In the end, this approach, albeit not the optimal, is still better than no approach, and we are not releasing it right away today. |
Oh yes, i did not want to say that this would keep us from merging the sdk support as it is right now. |
Do you still want to include the renaming of the function in this PR? |
@arty-name For public credentials, we call the methods |
When I was looking at these PRs I didn’t properly consider the naming convention and everything looked fine to me. Now @rflechtner has raised this topic, and I can see what he means, while I still don’t have a strong opinion. Then I felt that the point was forgotten about in the discussion, and wanted to clarify whether Raphael still thinks it should be done. I believe it’s his call and I will be fine with both outcomes. |
Ok summing up to avoid confusion:
|
@rflechtner I addressed your points 1, 2, and 3 in the commits above. In general, I think that mentioning the use of the Regarding point 4, we do have a ticket for it, but I don't think it is actually a scalable approach. Now we are putting more load on the server, which is a single instance, rather than putting the parsing load on the client, which are distributed. This will have to be considered carefully, as if we have, potentially thousands of credentials which we want to filter by, say, attester, the node would have to do that once for each client request, while the client could fetch all the data it needs and perform the filtering on its side. |
…-blocknumber-support
…-blocknumber-support
…-blocknumber-support
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.
Besides some small issues in the docstrings this looks great!
Concerning your remarks, we can have decoders for runtime calls as well; I don't think these are exclusive to state db queries. The convention we introduced simply says that if a function is called *fromChain()
it's a simple decoder that transforms a SCALE encoded value into a JSON-like object.
I'm not entirely sure what you're referring to with the wrapping of functions for convenience? If you were talking about the decoders, I would be happy to not have them at all, but could also see that it may get tricky to understand how certain on-chain data is decoded, especially when using js or where e.g. account ids get transformed to URIs/DIDs. I assume it's not fetchFromChain
and its publicCredentials cousin, is it? I'd agree we're moving away from what we originally wanted for the sdk with these, but given their complexity writing a recipe instead is just not an option. That's one of the reasons I was pushing for moving this logic to the node side, next to the side effect that this reduces traffic and may help in minimising breaking changes that applications need to try and keep up with.
Side note: I'm not sure I agree that we must try to minimise load on rpc nodes and treat them as 'servers'; should the rpc node not be part of the client-side setup wherever this is feasible (i.e. outside of mobile & browser environments)?
Fixes https://github.com/KILTprotocol/ticket/issues/2330.
It follows a similar process as to what was done for public credentials, and it indeed also refactor some common code into a
utils.ts
module within thecore
package, which is not exported outside.I cannot be merged before KILTprotocol/kilt-node#440 is merged in the node codebase, but it can be reviewed nonetheless.
Checklist