I always use incognito mode for local development because I have trust issues with JS caching and local server reloading. Since I frequently close and reopen private windows, I lose the local state, and I have to restart the sign-in process without the identities being listed. It’s not an issue per sé, but often, from day to day, switching between projects, I forget which identity I used for testing purposes, like “was it 10005, 10011, or 10017 etc.?”. Since what I’m developing is often tied to specific use cases, I often end up either trying my luck one anchor after the other or re-creating a new identity and populating it with the necessary data to continue developing, which takes time.
In short, I’d like to suggest a feature: it would be helpful if the local DEV build would automatically pre-populat the list of available anchors when the storage is empty. This way, when I open a new incognito mode window, all recent anchors (10006, 10005, 10004, etc.) would be available.
Note: definitely NOT something I want in production, and also not something for which I would like the II backend code to be extended for but, if it’s something doable without those kind of changes, that would be cool for my DX.
3 Likes
It’s an interesting idea for DEV only, there are security implications, which make this unsuitable for production environments. I can see how it could be done if the II backend is extended to serve the existing II numbers to the frontend, but can’t see how it could happen otherwise.
Food for thought, thanks for sharing 
I want to clarify a few points.
First, I explicitly mentioned that this idea was for the developer experience, for the DEV environment, and I am fully aware of the security implications. There was never any intention to develop this for the mainnet.
Second, after taking the time myself to have a look to the II candid interface, I can confirm that this feature can be implemented without the need for backend code changes.
The DEV frontend code can query for example the stats endpoint to determine how many users have been registered. Knowing that the dev identities are indexed by 10000, it can then use the lookup endpoint to gather information about the identities, if necessary, and ultimately populate the local storage.
In summary, there is my opinion no need for backend changes to implement this feature for developers, and it can be relatively easily implemented for the DEV environment, unless I have misunderstood the feature and II’s capabilities.
2 Likes
It can also be a browser plugin btw. but, again, maybe I am missing something. Happy to hear if technically the above is not accurate.
1 Like
Great ideas, thanks for sharing those!
You’re welcome. However, this seems a bit concise. What are the next steps or actions we should consider based on this thread? Should we wait to see if other developers are interested as well, or should I take the initiative to build it myself on my spare time?
This is gonna be added in the roadmap and prioritised accordingly. Right now, I would say this is gonna end up being lower priority than features currently under design or development (e.g., like the feature to allow dApps to query the auth type the user used).
So by all means, if this is something you’re keen to have, it would be awesome if you start the dev and we can all discuss details in the PR 
1 Like
Lower priority definitely makes sense, thanks for the more detailed feedback.
Just a note: if I end up tackling this in my spare time, I’m more likely to address it with a script or plugin due to its specific nature, rather than providing a PR for II. However, for now, I don’t plan to work on it in my spare time. I guess I’ll continue to deal with this small DX issue while I develop Juno and other dApps for the foundation for a while.