Pull request(s) not being reviewed. Is this repo dead?

[julian-payne]

There are now a few PRs waiting for a review for their network to get included into the registry (including mine).

There are even some that haven't seen daylight for a few month.

What does it require for a PR to get merged and released that is not documented in the root README?

[bkchr]

If you look at your pr, you just removed some unrelated chain from the json?

[julian-payne]

@bkchr
Hmm... that's weird. Either way that wasn't my intention and I'm guessing it's probably because the upstream branch has changed?

I'll make a new commit ASAP.

As for my question, do you have an answer?

[julian-payne]

fixed: 6bf95e0

[julian-payne]

I'm still waiting for someone to give me some kind of feedback on the PR as well as this issue. Anyone?

[blakebyrnes]

@bkchr This repo does feel odd with the number of PRs that are dormant without any feedback. Is the intention to provide a roadblock to being added to the default manifest? If so, very reasonable, but it would help to list the actions a network should demonstrate in order to be eligible for inclusion.

Do we need to get to know someone on discord or element? I have found that to have too many channels to know where to go. I also heard nothing back from any of the ambassador programs.

@ggwpez - I've really appreciated your work on stabilizing and simplifying the developer journey for substrate. Perhaps the step of getting into the polka testnet world could be part of that process (assuming I haven't just missed it)?

Happy to do whatever you guys need, but some kind of checklist/commentary would be very appreciated.

Aside: I know there's a proposal to remove the need for many of the prefixes that live in the same consensus on the forums, but solo chains will still need to have their own prefixes in that proposal, and it would seem that almost all chains need to go through a solo chain process before getting to parachain worlds.

[ggwpez]

Sorry i am entirely unfamiliar with this repo or its historical story. Not sure why it is in the hands of Parity instead of the community anyway.
Maybe we can move this to the fellowship and have approval rights for ecosystem members?

[bkchr]

and it would seem that almost all chains need to go through a solo chain process before getting to parachain worlds.

Why? I mean this it not required at all.

If so, very reasonable, but it would help to list the actions a network should demonstrate in order to be eligible for inclusion.

We had before someone doing this work. Aka checking that projects are legit etc.

[blakebyrnes]

Maybe we can move this to the fellowship and have approval rights for ecosystem members?

Seems to make sense. Is that something I can initiate somehow?

and it would seem that almost all chains need to go through a solo chain process before getting to parachain worlds.

Why? I mean this it not required at all.

I guess I'm thinking mostly of our use case, but building a solo chain is complicated enough to test and get working for what we're doing, so testing it out with external users feels prudent before layering on the parachain world. Not to mention that CoreTime and JAM seem like they're moving things into a different direction anyway. Both of which have led us down a solochain-first path for the time being.

Maybe I've overstated it by saying most solo chains need it though. You've probably got more perspective there than I do.

---

I realized I've been assuming the substrate/polkadot world still believes in the security benefits of having a unique ss58 address. Is that a wrong assumption? I just poked around a little, and despite this being a polkadot-apps ui feature, and a core feature of creating addresses, the polkadot-sdk repo is pointing at version 1.34 (while latest in crates.io is 1.47, and the repo is actually at 1.49). Is this a legacy feature, or simply something that fell through the cracks?

In 2021, this file seems to have been part of core substrate. It got pulled out, but seems to have lost having an owner. This feature seems to be related to the apps-config PR process of polkadot-js apps. Should the ss58 prefix be considered a UI thing? I would say it could also make sense for the apps-config details to be in a central registry as well, but it does still need some kind of approval/review flow. @ggwpez, what would the flow look like for fellowship?

[bkchr]

I realized I've been assuming the substrate/polkadot world still believes in the security benefits of having a unique ss58 address.

The idea is that you will have/should have one unique ss58 per "consensus system". This means that for Polkadot/Kusama there should only exist two prefixes and everything on top of these chains is using the same prefix. There was already some discussion around this in the Polkadot forum.

Generally I don't see that this repo should be part of the fellowship. We will open some thread in the Polkadot forum to discuss the future of this repo. From our side, there is no real need for this repo. Maybe having some kind of UI collective or whatever taking over this repo could be a possible future.

Not to mention that CoreTime and JAM seem like they're moving things into a different direction anyway.

Parachains will continue to work on JAM as they work right now. From the POV of a parachain there will not be any difference.

[julian-payne]

@blakebyrnes @bkchr @ggwpez
Thank you all for your comments. Took me a journey to understand it all but I think I get it.

For those of us who are going the solo-chain route, a ss58 registry is still needed to distinguish themselves from the Polkadot/Kusama consensus system.

In the meantime of being decided what to do, what do ya'll suggest we do?

forking the SDK and providing our own registry seems the only way to provide a patch for the time being, but I'd like to know your thoughts.

Thanks for helping out a rookie.

[itsbirdo]

I've reviewed and cleaned up some old PRs. Have requested review from Basti for the projects.
This registry will likely be deprecated in the future based on the discussion here: https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072