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… 
You probably meant to say “use https://chains.papi.how/”, right? 
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…
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.
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. 
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.