Hi there,
On my second device I cannot access nns app or nns page.
Page failed to load.
Any advice?
Thanks
I have my identity number and my 24 phrase. But when I try to restore it needs 25 phrase.
How to restore it with 24 phrase?
Your comment was flagged as not related to the thread. Which is technically correct, but as a moderator of this forum, i do not want to penalize a new community member for not being aware they should just start a new thread, so i approved your post so I can help you.
To answer your question:
This should help you: https://twitter.com/aa_dfn/status/1658856849481900032?s=20
The first slot of the recovery phrase corresponds to the Internet Identity âanchorâ id number. The next 24 words consist of the recovery phrase. The UI will soon be updated to make this more clear to avoid confusion.
The first entry is your internet identity number followed by the 24 word seed phrase
1 Like
To achieve this we have developed a multi-canister architecture for the ledger which operates multiple aggregators deployed on different subnets and a single ledger on another subnet. With every heartbeat, the aggregators forward transaction requests in batches to the ledger where they get processed
1 Like
How can recover my account
Unfortunately, I always had an identity number there and I just logged in using the Trezor one. Now, almost a year later, I wanted to log in to NNS, but it asks me for the identity number that I lost, is there any way to log in if I donât know the identity number but the key is created using Trezor one?
In order to best help troubleshoot your issue, the first word of the recovery phrase always corresponds to your anchor ID. ie, the recovery phrase should begin with the anchor id. The first word of the recovery phrase is your anchor id number. If you have your recovery phrase saved, you should be able to also locate the anchor id.
If you donât have your recovery phrase you can obtain the Anchor id using the following method:
The IC dashboard https://dashboard.internetcomputer.org/ has a chart that shows Internet Identity Anchors growth over time, which you can use to determine the anchors created during a specific time window.
Go to the home page
Click the 
icon next to the Internet Identity Anchors sparkline chart to expand it to a large chart.
Click the 1Y button under the chart to set the date range to one year.
Use the sliders under the chart to zoom the chart in to the dates youâre interested in.
Hover over the chart to see the total count of anchors at that time.
Add 10,000 to the number of anchors to get the anchor number (anchor numbers started at 10000).
Doing this, you can narrow the number of anchors created on the date you created your anchor id to a few hundred.
Then you can try logging in with each anchor id sequentially until you find our anchor id.
Best,
Hey there, everyone!
Please take a look at ICRC-35. This is a new draft that offers an alternative solution to the interoperability problem, which does not rely on signers at all.
Thanks in advance!
Have a great holidays.
2 Likes
Hey there, I just read the rationale on GitHub. This appears like a big deal. Lots of non technical people never open up GitHub. Might I suggest a bigger forum post on it?
Am I correct in thinking this will allow II wallets to be used across dApps? A simplified post would be helpful.
Congrats team. All the big blockers to adoption seem to be getting knocked out 1 by 1.
Hi, @dfisher!
Thanks for taking interest in this topic.
The reason Iâve posted this information to this forum thread, with most of the information being published to github is because the specification is dedicated for technical people from the Working Group 
. I donât mean it like âif it is too technical for you - it is not your businessâ, no. In contrast, I wanted to first discuss this idea with people from the Working Group, in order to get their feedback and make the specification more mature. Once this is done, and there is a common understanding that this protocol should be standartized, I (or maybe not only I) will publish a less technical post to a forum thread dedicated specifically to ICRC-35 and the effect we expect it to apply on the ecosystem.
ICRC-35 is only a draft, which is designed to be an alternative to ICRC-25, which is also a draft. There is no guarantee it will be adobted first by the Working Group and then by the community in general.
I donât quite understand what do you mean by that. The idea of the specification, if short, is to instead of relying on wallets (we call them signers), dapps to be able to integrate with other dapps, could just speak to each other directly.
If widely adopted, this would enable the original Open Internet Services vision, where web-services donât build all their functionality from scratch in-house, but instead they just integrate with other web-services, which provide the needed functionality for them, and then build their business-value on top of that provided functionality. This could save them a lot of time and money. For regular users this would translate into cheaper and better services.
1 Like
Thank you for the response, that makes sense.
What I mean is that each time I use II to log into various dApps it recreates a new wallet in that dApp. I was wondering if this standard would enable me to take the same wallet across dApps.
For example, suppose I have 10 icp in my nns dApp that I use II to log into. Will I be able to use this 10 icp in different dApps in the ecosystem? Today, if I use the same II anchor number to log into OpenChat it will not reveal the 10 icp I have in my nns wallet.
Oh, now I see.
No, the standard is about you still not being able to use the same wallet on different dapps. Because this property is very important from the security perspective. Other wallets (e.g. MetaMask) allow that and this is the problem theyâre facing today. You donât want to lose your money to some scam website that looks exactly like OpenChat, but is located at https://0c.app instead of https://oc.app. You donât want to be in âalarm modeâ each time youâre surfing the internet.
Instead, ICRC-35 proposes the following way of handling this situation: what if instead of being able to use the same 10 ICP you have at NNS directly (by your wallet being able to call NNS canisters using the key pair responsible for your interactions with NNS), OpenChat website could just âaskâ NNS website to transfer some amount of your ICP to some pre-defined address. So you would be redirected to NNS and you will be asked, if you really want to purchase something on OpenChat for, letâs say 1 ICP, or not.
A picture is worth a thousand words, so I would suggest you to see MSQâs demo video. MSQ already implements ICRC-35, so you can see what I mean by that. The part about being able to use 10 ICPs I have on <website-A> at <website-B> starts from 3:10.
Once you see that demo, you can imagine how could all other services integrate with each other the same way.
Thank you for the detail.
While I agree interoperability is the goal (not just for the IC but for Web3 as a whole), I fundamentally disagree with the assumption that accessible interfaces that describe whatâs being approved in a personal signature prompt are impossible to scale.
Moreover, I didnât find anywhere in your rationale a discussion of the trade-off youâre making, which is a shifting of trust assumption from user to prompt provider (i.e. dapp). I would be very uncomfortable with such a sweeping abstraction of responsibility.
Hey there @dostro,
Thanks for replying!
The scaling of consent messages is not the main topic of that section of the rationale, if I understand you correctly. Yes, they might scale well, but they might also not - nobody did this before, we donât know what the future brings. The main problem with them, and we know it well, because we have examples before our eyes (like MetaMask) is that after some time human vision blurs when dealing with repetitive actions like this. When people lose focus, scammers take their money. When regular people get scammed so easily, they donât (at least not all of them) take responsibility, admit their mistake and start learning software security. They just get scared and quit crypto. We donât want that.
Then, I assume, you should be uncomfortable interacting with the Internet Identity? From the perspective of ICRC-35, II is just another service provider. It receives requests from service consumers, does something internally (requests our WebAuthN signature, makes canister calls) with usersâ help and then responds with results. For a regular user the II is just another black box. Users canât inspect messages the II signs with their WebAuthN device (which II uses as a signer, in terms of ICRC-25). They donât see what canisters does the II call internally in order to authorize them on some website. What if, for example, there is a bug in II and they accidentally generate the same identities for ânns.ic0.appâ and âfake-dirty-website-2010.comâ? But we trust II.
We audit its code each time it is updated, to vote against, if we spot something bad, right?
And If we donât trust it, then we just donât use it - we use something else. Service providers (like II or NNS) always manage something valuable (assets or sensitive information) for a user. If a user uses a service provider, they by-definition trust it, because why would you give complete access to something valuable to somebody, if you donât trust them? So there is no trade-off, this is just how things work and how we live.
I understand, that from a perspective of somebody from the WG, my way of going in with a completely orthogonal solution, which proposes to negate all the work you did during last several months, might look nasty. And Iâm sorry for that. On the other hand, what else could I do, if this is the way I see things?
Please, give ICRC-35 a chance.
My point is that step 1 of self-sovereignty was to enable it. Step 2 should be to make more clear whatâs being signed and what the simulated outcome of that transaction would be (which teams are making great progress on outside of ICP).
You seem to be redefining âself-sovereigntyâ to be more like âsemi-self-sovereigntyâ by introducing a trusted mechanism to abstract the complexity.
Yes, you are correct, Iâm not 100% comfortable using II. Itâs a singleton app thatâs governed by the NNS and the only reason I trust it is because I trust DFINITY and II developers.
But what youâre proposing is to spread the risk across all application developers, and Iâll never audit that code each time itâs updated. I vote for trustworthy mechanisms first, then improving their UX. Interoperability can only be scaled with a base assumption of trust, and I canât trust such abstraction.
Iâm not saying thereâs no place for it, Iâm sure there absolutely is! Iâm simply communicating my fundamental issues that make me cautious about working on it, at the very least before the wallet and signer standards are completed next quarter.
And please donât worry about the optics of proposing an orthogonal solution. I recognize your desire to move the space forward and appreciate all your work
2 Likes
Iâm just saying that if we already accept Internet Identityâs interoperability mechanism. If we tell people that II is the safest way to manage their keys. Then why donât we just spread the same mechanism over other dapps?
Thank you, I appreciate that a lot!
I think thereâs no single solution for all problems.
Right now I see two different situations that need different solutions:
- User is asked to spend 200 icp to buy an NFT by a market dapp, the user approves in the wallet dapp (icrc-25 and optionally 21)
- User want to give access to his files in dapp A to dapp B (icrc-35?)
The first example is explicit, just like traditional fiat transactions, you see the transfer request and approve. This makes sense from a zero trust perspective.
The second example is implicit, you give permission once to a specific scope and the dapp can use this permission without user interaction untill itâs revoked.
In icrc-25 we used json rpc as data message format, the data channel (post message, url etc) itself it not specified in the spec but handled in separate spec(s).
The icrc-25 spec does not require the icrc-21 spec, e.g. the dapp could implement something else instead of consent messages that might not even require user interaction. Maybe icrc-35 could hook into things here to extend icrc-21?
My apologies if I mistook any details, I only have had a small time to look through the icrc-35 spec.
Hey there @sea-snake,
Thanks for taking interest in this topic!
The second example may be both: âimplicitâ and âexplicitâ, depending on the use-case.
If weâre talking about ICRC-35, during this flow, the user would be redirected to the dapp A (where the files are) and be guided through a process of selecting files, which the user wants to share.
The sharing mechanism may be different, but in the most straight (and not very suitable for big files) option, the dapp A window would download these files and transfer them over the browser-based protocol to the dapp B window, which would do with these files whatever it wants. This way of sharing files my be the most suitable for the example from the rationale (with photoshop.ic). This option is âexplicitâ - dapp B gets one-time access to users files from dapp A.
Another option would be (if the files are big) is to not transfer the files, but instead transfer links to those files. Here everything depends on the privacy policy of the dapp A - if the dapp offers private files, which can be shared and then un-shared with third parties, then it might employ an encryption mechanism (based on VETKeys, for example), to always keep these files in secret from those who shouldnât have access to them; if the dapp is something like pastebin, then it could just generate random ids for those files and if you know the id, then you have an access to the file. This option is âimplicitâ.
In other words, there are many ways to implement this flow. All of them are accessible with ICRC-35.
Donât worry! I would suggest you to start with the rationale first, instead of the spec. It contains an example (with images!) of how such an integration flow could look like.
II doesnât have an interoperability mechanism, as far as Iâm aware. In fact, itâs taken a somewhat antithetical approach to interoperability by generating new principals for every domain. Weâve seen examples in other networks of global identifiers accelerating the development of interoperable applications. Do you mean the work being done on cross-principal verifiable credentials?
And I donât prescribe to the belief that II is the safest way to manage keys.