Polkadot JS Roadmap Update - BlockDeep

Ecosystem
1

Polkadot JS Roadmap Update - BlockDeep

Hello again from the BlockDeep team!

This is Part 2 of our Polkadot JS Updates. In our previous update we delved into what we have been working on so far on PJS, and some of the new features we have implemented.

In this update, we’d like to share a few feature ideas, and an initial roadmap we’re exploring. Our goal is to gather feedback from the community to help us guide the direction of PJS development:

The Road Ahead

Maintenance and Support

We will continue to provide regular maintenance and support to the entire Polkadot JS suite of tools and libraries, and this includes:

  • Updates to API and Developer Interface based on Polkadot SDK releases
  • Bug fixes and stabilization
  • Regular audits and addressing any reported security issues
  • Continuous releases and documentation

Enhancements

In addition to regular support and maintenance of Polkadot JS codebase, we will continue to improve it with new features and enhancements. To begin with, we are proposing the following new features for the Developer Interface and API:

Proposed Features

  1. :magnifying_glass_tilted_left: Event Filtering by Account (Developer Interface)
    Right now, the explorer shows all events, making it hard to find those tied to your own accounts. We’re proposing an optional toggle to filter events to only those involving user accounts registered on its PolkadotJS instance. This would improve readability and reduce noise, specially for devs that are testing on active chains where finding a specific event can become a hassle.

  2. :star: Favorite chains (Developer Interface)
    Navigating to a specific parachain currently requires diving through its relay chain and scrolling through the list of parachains which can be tedious for users who regularly switch between chains. We’d like to introduce a way to mark favorite chains for quick and easy access.

  3. :globe_with_meridians: Simplified Chain Endpoint Selection (Developer Interface)
    Selecting an RPC endpoint can be confusing for new users, who may not understand what it is or which one to use. To improve usability, we’re proposing automatic selection of a rotating default endpoint from a pool of reliable public nodes. This avoids overloading a single provider and helps prevent centralization. Advanced users will still be able to manually choose their preferred endpoint via a dropdown.

  4. :counterclockwise_arrows_button: Teleport Feature Enhancement (Developer Interface)
    While Asset Hub (AH) is expected to play a central role in most activities post–AH migration, teleporting of assets from AH still only supports the Relay Chain as a destination. This feature aims to expand support to additional system parachains, such as People, BridgeHub, and others, enabling smoother teleport UX across these chains.

  5. :bellhop_bell: Notification Panel (Developer Interface)
    We’re proposing a new notification panel in the navigation bar to improve visibility into recent transactions. It would display basic details like transaction type, status, and a clickable block number or hash. Toast notifications would also include links to the relevant block, making it easier for users to track their activity (especially on chains without Subscan support).

  6. :fountain_pen: Multisig Tab (Developer Interface)
    Multisig approval requests are currently shown via a small pink icon, which can be easy to miss. We’re proposing a dedicated Multisig tab under the Accounts page, serving as a centralized area to review and act on pending multisig transactions more clearly.

  7. :blue_book: Interactive Developer Docs for Custom Chains (API)
    We’re building a tool that lets you generate interactive documentation for your chain to make it easier for developers to understand how to use the chain specific types. It’s often unclear what values need to be passed into extrinsics, RPC calls, or runtime APIs, especially when dealing with custom types. While importing the api-augment package and setting up ESLint helps with type hints, it still doesn’t show how a parameter should be structured. This new functionality will spin up an interface (via CLI) for any given chain, displaying all extrinsics, runtime APIs, events, etc. and their parameters, along with mock data for each call.

Cleanup and Deprecation

An important part of the maintenance process is cleanup, refactoring, and deprecation of features that are not being used as intended, or not needed anymore. In light of this, we have identified the following areas of codebase that could be deprecated:

:atom_symbol: Electron App Deprecation: :red_exclamation_mark:Community Feedback Wanted

The Electron version of the Polkadot JS UI hasn’t seen much usage, and maintaining it can require ongoing effort (especially around security) that could instead be spent on developing or improving features like the ones proposed above. We’re considering phasing out active support for Electron, but we want to hear from the community first: Is it still useful to you? Your feedback will help us decide whether it’s worth continuing to maintain.

Call for Feedback

We’re excited to help improve Polkadot JS, but we want to build it with the community. Let us know which of these features resonate with you, or if there’s anything else you’d want to see added. Your input is essential in helping us make Polkadot JS better for everyone.

If you would like to share specific feedback, please feel free to post it on Twitter/X and tag us @0xBlockDeep, OR you can send it to info@blockdeep.io with subject line “Polkadot JS Feedback”.

-BlockDeep Team

5 Likes
2

I am not sure how but how does it makes sense to continue developing already half deprecated library and platform?

There is https://dev.papi.how that could use some of the new features and help in dev. Also some of the proposed features are already implemented so it seems like a waste of resources.

  1. OK? not sure how useful this is if you implement 5. Also you can find the account if you use browser search. The general event list is very unreliable in showing everything. https://dev.papi.how is much better in this regard already.
  2. This was never problem - it’s 2 clicks
  3. OKish? (There is automatic selection already)
  4. Why? There are numerous XCM tools just link to them. https://app.turtle.cool
  5. This is useful actually…
  6. Why? There is amazing https://app.mimir.global which can connect to pjs already and many other like signet
  7. Just use https://dev.papi.how we also developed multiple instances of this before and nobody used it. i.e. https://apidocs.bsx.fi

All in all these are nice upgrades that were requested years ago but never happened why does it makes sense to do it now when we should be transitioning out of pjs and there are tools being built or are already for most of these features?

3

Thank you for sharing your feedback. We appreciate your perspective, though we would have welcomed more constructive input.

To begin with, Polkadot JS continues to be actively used by a significant number of users and dApps. As such, it remains important for us to ensure its ongoing maintenance and support. We are committed to meeting users where they are, and for now, PJS remains fully supported and is not deprecated.

Furthermore, many of the proposed features are based directly on user-submitted issues and feedback, such as:

Our goal is to strike a balance between supporting existing users and adapting to the evolving ecosystem. Projects like PAPI and DeDot are indeed valuable alternatives, and we fully support users choosing the tools that best meet their needs. We will continue to iterate on the PJS roadmap in alignment with actual usage trends and community input.

4

Don’t get me wrong I was and am still using this every day for last 5 years.

I am not sure what was not constructive I tried to be as constructive as possible. I would like to see your work be meaningful and utilize it better. Of course we need to have this maintained since a lot of people still use it.

I just don’t see a reason to continue new development since the javascript library that this is built on top of is being deprecated by the maintainer. It’s in maintenance mode AFAIK. I didn’t find any new information about continued development.

5

I was just made aware of this blog post BlockDeep Labs Takes Over Maintenance of Polkadot JS | Parity Technologies which I sincirely never seen before and also nobody from ecosystem that I talked to. Thus most of the teams started moving away from pjs to PAPI AFAIK.

This is new and interesting information.

6

Anyway regarding continuation of pjs stack development.

Even if most of our team use it still, we would not recommend any new people to start working on a new project with this stack. Past architectural decisions mean there is a lot of baggage, inefficiencies and bugs that cannot be just “fixed”. It’s served its purpose and the decision to deprecate I believe was a good one. Our DEVx has drastically improved with switching to PAPI. (With bundle sizes and load times). The features it offers are great and the way the types are handled are lightyears ahead.

This propagated to pjs.apps and this decision to continue development is very surprising after the maintenance announcement. I will leave this here. It’s no way meant to attack your work. It’s just surprising decision by Parity that I was made aware of by this post.

1 Like
7

There is also the PAPI Multisig tool, which -as a dev-tool- can be very useful. Please, read the forum post if you want to know more about its motivation.

This looks to me like catching up with how the PAPI console handles transactions. We’ve had this feature in our console for more than a year now… :person_shrugging:

You probably meant to say “use https://chains.papi.how/”, right? :wink: Also, any chain can generate those same docs for their custom chain, simply doing:

npm install polkadot-api @polkadot-api/docgen
papi add <...>
papi-generate-docs --config <path-to-papi-config> --output <docs_directory>

So, I don’t quite understand why BlockDeep is wasting resources into re-inventing the wheel… :person_shrugging:

Exactly! And that’s precisely why we should be encouraging users and dApps to move away from it ASAP, instead of giving them the false impression that PJS is somehow going to catch up and keep pace with the evolving needs of the ecosystem.

It’s worth pointing out that this whole situation stems from a political decision, not a technical one. PJS should be deprecated ASAP, and we should be talking about a clear sunset timeline in the near future.

There are many technical reasons for this: it can’t support the new JSON-RPC APIs, its public interfaces are ridiculously leaky, the signPayload method won’t work with extrinsic v5, it’s still hanging on to a custom type-registry that should’ve been dropped years ago, it suffers from so many memory leaks, its code-base is a monolithic pile of technical debt… the list goes on.

I’ll be on vacation next week, but I’ll try to carve out some time to write a proper deep-dive post on all this. That said, I have a bunch of other stuff I want to write about too. Honestly, it’s wild that I even have to explain this (some of it feels painfully obvious) but here we are. :person_shrugging:

IMO parity’s announcement is a bit confusing, because the reader could interpret it as PJS getting revamped for the future needs of the ecosystem.

Also, just to be clear: that blog post is misleading. PJS isn’t owned by Parity. I do appreciate that Parity kept the lights on after Jaco vanished, and I fully get why they’d want to offload maintenance. Makes total sense.

But AFAIK, Parity doesn’t have ownership rights to the repo. And we’ve been waiting over a year for someone to do something about the PJS signer extension interface… which still hasn’t happened. So, my team has started talking to different wallets to propose a more robust alternative to the signPayload interface in PJS. That thing is a mess and simply won’t cut it for chains that want to leverage the full power of extrinsic v5.

We’ll be contributing directly to the PJS extension to implement this new interface (and no, we’re not removing the existing one). Needless to say, at this point we’re not waiting for permission from BlockDeep or Parity. They can thank us later.

Totally agree that PAPI is what’s actually pushing the needle right now. BlockDeep, from what I can see, is mostly in catch-up mode, trying to port over a bunch of the stuff we’ve already shipped. Which is great, honestly! I’m glad our work is helping improve the ecosystem, and I think it’s awesome that BlockDeep is able to use it and bring some of those improvements into PJS.

Take ECDSA support on Ledger, for example. We shipped that in PAPI over two months ago, and now BlockDeep is trying to implement the same thing in PJS. Curious if they got it to work, though? We gave it a spin yesterday, and couldn’t get PJS to sign an ECDSA transaction on Ledger successfully. :thinking:

That’s exactly the point: PAPI users got this working months ago. PJS users still need to wait until BlockDeep sorts it out. And it’s the same story with support for metadata v16, view functions, custom signed extensions, full extrinsic v5 support… the list goes on. If your chain is using the newest and most powerful stuff the Polkadot SDK offers, then yeah, PJS just isn’t a viable option. It’s way behind.

What’s frustrating is how much energy seems to be going into superficial stuff: cosmetic tweaks, interface cleanups, etc… while foundational problems (like the infamous signPayload interface that DApps are still stuck using to talk to PJS-based extensions) continue to be ignored. :person_shrugging: