paraspell
Additional support for Dedot API
Hi Paraspell Team!
Along with PJS and PAPI support, would you be able to also roll out support for the next-gen Dedot API? Docs for this API can be found at https://dedot.dev. My team and I have already integrated Dedot into the Staking Dashboard, and if we are to integrate Paraspell tooling to facilitate cross-chain messaging we would need support added for Dedot.
Dedot API is maintained by @sinzii.
Thanks!
Hey @rossbulat , Thanks for opening this issue!
We appreciate every suggestion for improvement!
We have a couple of notes and a couple of questions.
We are starting a process of deprecating PJS in favour of PAPI fully, as we have now successfully migrated XCM Router to use PAPI solely, as PJS is no longer being further developed and remains mostly a legacy package (We will maintain PJS version for the next 2 years to come, it will, however, only be receiving hotfixes and security upgrades, but not new features).
And now, why are we telling you this?
We wouldn't discontinue the PJS version if we did not have high additional maintenance overhead from it (Because we have it in 4 comprehensive tools in total). Almost all projects using PS (That we know of) migrated to PAPI already (And those that did not are in the process of doing so). Maintaining support for 2 different JS APIs is very difficult in maintenance, as they differ in lots of ways. One of the major benefits for us in deprecating PJS is also that we will be able to use the Typed API from PAPI, since currently we are unable to due to PJS.
We agree with you that the more JS APIs supported, the broader the usefulness, so we are definitely going to consider this step, but we need to consult everything internally, and we need to brainstorm how we may be able (if at all) to implement Dedot but keep typed API support in our current PAPI SDK (After we deprecate PJS).
There is currently only one option that comes to our mind, and that option requires projects using Dedot to install both PAPI and Dedot, which may not be as desired. Why both? Because we can generate extrinsic using the standard PAPI SDK, and then convert the outputted hex into Dedot using the addon SDK that we can build, allowing you to use the Dedot client and Dedot features. This option gives us the least maintenance overhead, will keep our support for typed api from PAPI, but is more storage-heavy for projects. Would this be something you would be willing to accept (Having 2 JS Clients installed in the dapp)?
We are not familiar with Dedot at all, so we do not know how well the library is maintained and whether it is properly funded for a while to come by treasury or W3F, maybe @sinzii could let us know regarding this? We need to ensure that if we were to implement support for Dedot, it will be maintained and it will adhere to the latest network states and changes. We would also like to have a call with @sinzii if he would be willing to, so that we can establish a stable channel for bug communication, so that both parties can resolve bugs at a fast pace. The reason for this is that if something does not work, clients contact projects, projects contact us, and we are the first layer of defence, which can do something to resolve the problem (Instead of disabling the scenario that is faulty, which can be done on the project level). So we act as a support for all parties except the user base, so dapps(collecting bugs and feedback for features, modifications of current queries), JS API maintainers and Polkadot SDK XCM team(reporting bugs, and helping to find solution/work on solution if we can bring it faster (Because runtime upgrades take weeks or months to be released)), thus we need to act very fast and be very agile in communication (Because users are working with money). We now know that Jose from PAPI is very agile and responds to any problems very fast, this needs to be ensured from Dedot too.
We hope you understand, and we are looking forward to hearing answers from both you and Senzii.
Thanks a lot!
With kind regards, Team ParaSpell✨
Thank you for the in-depth response @dudo50, it's really helpful to know the state of affairs and I appreciate your workload - we have similar issues! I'll wait for @sinzii to follow up on your latter questions, but I'd lean towards having a singular API instantiated rather than having Dedot rely on PAPI. I understand this is a greater workload, but it is the better long term strategy IMO as dapps remain lean and have less points of failure.
My team is fully committed to Dedot and we will not be migrating to PAPI - we believe Dedot is the superior API for our use cases, and it is always a pleasure working with @sinzii. We have Ddedot exclusively in production in both Staking Dashboard and the Staking API, in which Dedot is used to handle indexing of node data, it is stable and robust. The Dedot API is managed extremely well and @sinzii responds to queries and fixes very quickly - he has always been focused solely on the product and development.
In regards to the support channels, I would be more than happy to report issues as and when we find them. The staking dashboard is maintaining 500 - 800 visits per day currently - completely organic traffic, so we have the traffic to discover issues as they arise. We maintain both Discord and email support specifically for the staking dashboard, and our users regularly use it to report any problems they run into. @joeljkrb and I would relay Parapsell specific issues to you either on here or other channels in the event they arise. This could be an effective feedback loop.
Depending on the work required for xcm-tools specifically, I'm more than happy to pitch in if I can be any assistance with a dedicated Dedot package.
@rossbulat thanks for your thorough answer, we appreciate it
We will explore what we can do, but currently we do not see a way of achieving typed api in Papi and Dedot as standalone package. We will brainstorm this idea more throughly for sure once we finish our high importance tasks.
Looking forward to hearing from Sinzi
With kind regards, Team ParaSpell
Hey everyone 👋
First off, thank you @rossbulat for bringing up the discussion, and thank you @dudo50 for the detailed response.
I fully understand @dudo50’s point about the additional overhead of maintenance to support multiple JS Clients (currently 2 and potentially 3 if Dedot is counted). I would also be more careful when making such decisions. But from the perspective of dapp developers, having to install & bundle 2 JS clients at the same time would not be an ideal situation, as this will increase the bundle size of the dapp just for some duplicated things. Not to mention that 2 clients would potentially mean that dapps have to connect to a network 2 times and download metadata 2 times, etc., since ws provider or smoldot provider of 2 clients are not compatible at the moment. There are definitely ways to work around this, but this potentially means the dapps have to carry this overhead of maintaining & running with 2 clients.
So I agree with @rossbulat here that having 2 separate implementations for Dedot & PAPI would be more beneficial for dapps.
One of the goals when we started Dedot as an alternative to PJS is that it has to be easy to migrate from PJS to Dedot. So if you have some time to try out Dedot, you should see some familiarities between Dedot & PJS. E.g., for some simple dapps, to migrate to Dedot from PJS, all they have to do is simply change to use DedotClient and fix some small incompatibilities between the 2. So if ParaSpell tooling & APIs are already integrated & familiar with PJS, I don’t think it would consume a lot of time to migrate to Dedot. Dedot also offers a fully-typed API for on-chain interactions that you can use for XCM-related or other runtime interactions.
I looked around the xml-tools codebase and figured out that you’re using a generic IPolkadotApi interface that you can implement for any JS Clients. So I’m not sure if we can just implement a new DedotApi and the higher abstraction layer can just interact via this IPolkadotApi interface. I’m not really familiar with the codebase, so maybe I’m missing some big picture here.
Regarding the funding, Dedot is funded by the W3F Grants Program. We’re also receiving funds from ink!ubator grants, and we also plan to propose and get funding from the treasury as well. Over the past 2 years, we have been continuously adding more features to Dedot and adhering to the latest network/protocol changes (e.g., Metadata V16, Extrinsic V5, Pallet Revive (ink! v6), or JSON-RPC V2 etc... are already supported), and we're committed to continuously doing so. We’re running a dedicated Telegram Channel where we post announcements on new Dedot releases & improvements, as well as a place where devs can post feedback and report bugs while working with Dedot.
That said, I’m happy to hop on a call and set up a communication channel with the ParaSpell Team so we can discuss further on the integration and reporting issues/feedback. My personal Telegram is realsinzii and my email is: [email protected].
Thank you!
Thanks @sinzii for your reply,
We appreciate your direct answers to our questions. We are definitely going to start exploring options of integrating Dedot as another offered client, along with PAPI, as a standalone package, as you suggested, seeing that you have been dedicated to Dedot for 2 years already, and your funding path seems promising too. We actually had a peek at Dedot docs, and we liked how similarly it followed PJS syntax, so indeed replacing PJS with Dedot might be a very viable option currently. We would have to give up typed api for the sake of Dedot, but we see that it will definitely open up new interesting use cases for us and for new teams, so we are willing to go for it.
We will contact you on Telegram shortly to arrange a call, and we will create PS<>Dedot group to have a direct line of communication once we proceed with the implementation.
We would also like to ask @rossbulat for Telegram contact, so that we can let you know once the Dedot version of PS is available to try, and so that we can also have a direct line of support for you guys. You can contact us on telegram if you wish to keep your TG handle private: "Dudo50" - I will then create group between our teams.
Thanks!
With kind regards, Team ParaSpell✨