The most compelling and logical solution is to allow Taggr to reset the dApp, with minimal losses, and promptly commence the strategic planning of a robust and effective policy for the NNS.
I appreciate and respect your views… always have!
However, my penultimate point is that by design the NNS DAO can do this. It’s already voted to launch and control a SNS for an application.
I completely get what you want the NNS to be… but it is not that today.
3 Likes
Btw, this exact process step has been implemented and will be required for voting in the future but let’s be real this is not realistic for a multi-million user uber decentralized app that wants to remain competitive with continuous updates.
It also doesn’t mean the code is right and could mean that the ability to push proposals breaks and we’re right back here.
2 Likes
Here are some of the things that consumers may want to consider when determining their confidence in an Dapp. I added identity decoupling and awareness that the NNS could potentially change the state and code of a canister.
Enterprises will want to have confidence that their Dapps and Data are safe from unpredictability. While using the NNS may resolve the Taggr situation, it generates uncertainty and may undermine confidence in placing enterprise class services on chain in the future. This needs to be better framed if the ICP is going to be positioned as ready for prime time and a challenger to web2.
5 Likes
Can we get more information on the alternatives before voting on this proposal? Did I understand correctly from this thread that Taggr a) has a backup and b) the only obstacle to re-launch in a different canister is the principal-mapping of II?
Then it can really be fixed with a one-off fix in the II. So it would be an application-level change to help another application. Moreover, the change would be in an application (II) which is already controlled by NNS and for which the NNS has a clear mandate to control it. Whereas whether the NNS has the mandate to overwrite a canister binary is controversial, judging by this thread.
Moreover, I would like to point out that this is not urgent. Taggr will survive if this takes a few days or even weeks. Maybe Taggr will attract even more users after the fix the longer this story is being discussed. I see no urgency to rush through a controversial proposal.
15 Likes
Anvil named neuron is voting ‘yes’. In our opinion, the IC ecosystem is still in experimental stage. Things break and will need to be fixed. I doubt changing Internet Identity is going to be a better solution - messing with user credentials instead of canister upgrades - doesn’t sound very good or a less powerful intervention.
Long term, @skilesare Social Recovery DAO sounds good.
I would like to have easy to use a rollback feature at a protocol level where the controller can roll back to an older version and its previous memory with one proposal. This will also solve issues when something wipes canister memory.
Similar to the UX: When you change your screen resolution you have to click “confirm” or the new resolution gets rolled back in 20 seconds.
This way the DAO users can experience the upgrade and see if they like it or not.
It will allow users to review the changes, instead of asking them to review the code.
For SNS that will be a good fit, since the ledger is not part of what the SNS DAO controls.
6 Likes
This could potentially result in inequity for numerous dApps that have experienced issues in the past and may confront similar problems in the future. Furthermore, it bears the possibility of being exploited for nefarious purposes.
Yes, it would be a Taggr specific fix but that doesn’t have to be a problem. It can be a Taggr specific fix for now but it can later be migrated into a more general feature of II that allows a form of “redirection”. I share the opinion, expressed earlier in the thread, by @lastmjs that the importance of immutable canisters will rise and that we will see upgrades happen by forking to a new canister id rather than overwriting the binary of the old canister id. Such things would require a notion of mapping or re-direction in II if II users are to be able to follow the upgrade.
The fix can also be made opt-in by the user so that old Taggr users need to check a box in the II frontend to opt-in to a redirection and new users of Taggr don’t have to know about this. The redirection list can even be further decentralized so that it doesn’t have to be maintained inside the II itself.
In summary, I think there is a migration path for this one-off fix to become something useful.
12 Likes
Are DR canisters an option to future ways of canister management?
The idea is:
- OG Canisters is considered Production, DR Canisters are the Recovery canisters
- DR canisters can choose to identify as an OG Canister
- OG Canisters will have to approve the addition of DR canisters
- IIs can be configured to identify DR canisters as OG canister hence allow use of same principal across canisters
This allows for:
- Portability of User data
- Better Release process (Release on OG canister, make DR canister the main meantime and test)
- Better up time
I’m sure the above has a lot of holes, but intent isn’t to solutionize but to give an idea of a rough concept
I don’t think the redirect option needs to be in the II. Taggr just needs 2 buttons: signup and signin. Signin takes them to the old derivation origin and signup takes them to the new derivation origin. A frontend change is needed to the II, but no canister change. The frontend change won’t be evident to the user.
Or a migrate button and old accounts can migrate to their new principal. I believe taggr already has the change principal option.
Many solutions here that don’t require any significant changes.
1 Like
That would not work, though, since II expects the “old” canister to signal confirmation. But in this case the “old” canister is dead.
3 Likes
Agreed, so the old canister is queried by internet Identity frontend which returns a list of ii-alternative-origins. Well it’s dead, so instead of querying it, the ii-alternative-origins for that specific canister is hardcoded into the ii frontend.
Wouldnt that work? @bjoern
Yes, if we encode a Taggr-specific rule in II that states “if derivation canister id = old Taggr canister id AND requesting canister = new Taggr canister then accept”, that would work.
1 Like
Just one more thing, I don’t believe this would require a backend canister change and only a frontend change to the javascript, is this correct?
The change is in JS only, that is correct. As the JS is included in the Wasm module and thus upgraded via the same process, it doesn’t make too much of a difference, though.
1 Like
Thank you, imo there is a perception of changing the frontend relative to the backend where one is changing the smart contract and one is changing the human interface. Just my observation though.
Also maintenance wise, it should be far cheaper to maintain a frontend js change.
1 Like
Not to draw away from the conversation (as it draws to an end), however, I would like to reflect @dfisher opinion as well. This was a topic I thought could easily go either way and everyone in the discussions was surprisingly professional and very polite. This was really nice to see in the community given the topic of debate. I really hope I keep reading more debates like this on issues of severity as they arise.
In full disclosure, I voted yes despite the precedents. I wholeheartedly believe in what @dominicwilliams wrote.
I do hope these issues continue to pan out publicly in a civil manner.
Thank you all 
4 Likes
I’m genuinely confused by the push back this proposal is receiving.
It’s not that I disagree with the pushback. But let’s be honest, @mechaquan isn’t wrong in his observation that this well within the norm for this network. I’ve seen several people refer to this as our “The DAO” moment, but I can’t help feeling like we’ve already experienced several of those moments. IIRC NNS node providers have their own proposal system by which they can push canister upgrades without stakeholder consent. Is that cability restricted in any way or are we putting trust in the NPs not to collude and act maliciously? DFINITY directs an overwhelming amount of liquid VP on non-governance topics. With this much influence they could literally change any aspect of the protocol that they wanted. Motion proposals are nice; but they are basically a courtesy to stakeholders and nothing more. Is everyone pushing back going to start pushing for a follower reset on all topics?
I hope everyone reading this understands that I’m not trying to FUD; I just want to understand why this proposal? Is it because it’s such an obvious departure from the crypto ethos that we feel compelled to speak out? Would we care as much if DF had decided to just take it upon themselves to push the replica upgrade without submitting a motion proposal? Maybe, but how quickly would we have just written it of as “this is how governance works; they are largest stakeholder; deal with it or leave”.
Can we really have a “The DAO” moment if we never really had any guarantees of immutability to begin with? We all trust DFINITY. That is the reality. I’m glad they gave us the courtesy of posting a motion proposal. We can all vote to reject and they would probably honor that decision, but that doesn’t mean they’ve lost their ability to push this change in the future.
If we do reject this proposal I hope we continue the trend and push for follow-on changes that would actually prevent this from happening in a worst case scenario where DF is forced to make this change regardless of stakeholder consent. Otherwise, we haven’t really achieved anything other than preventing TAGGR from recovering their canister.
I apologize ahead of time to whomever I may have upset with this post.
11 Likes
Just cause it is possible it shouldn’t be justified, technically all chains are mutable if a majority of hashrate/VP decides to reorg/fork, that doesn’t mean such things are taken lightly in the crypto space and I think we should take a page from their book.
The closest thing I can think of is the Mario64 event, which while sharing some similarities, i.e the debate about what the NNS should be capable of, isn’t comparable as the canister owner removed it by his own will and hosting illegal content on chain is a much more complex topic cause it involves technical problems that are hard to overcome due to how the protocol is designed, still it was a heavily topic and after that Dfinity chose to move forward with BN for censoring content so I assume and hope deleting canister will be a rare occurence in the future and only be done in extreme cases, e.g vulnerabilities, CP, etc… after careful considerations.
If there are other similar situations I’m missing let me know.
I’m not aware of any NP specific proposal system, it is true that if they collude they could run any binary version they like though, but from my understanding it would be a breach of the “declaration of good intent” whatever that means legally and could be technically seen as a violation of Dfinity’s source code license, so they might be sued by Dfiinty on that basis.
Because we have to start somewhere, there are alternatives but for whatever reason the higher ups have decided to go with the one that is less in line with the crypto ethos and that could further worsen IC public image and possibly scare away existing and potential new projects from considering the chain.
Many community members have been pushing for it for months but have largely been ignored, @wpb ,@justmythoughts and myself even made a proposal back in August to have fundamental NNS features prioritized, Dfinity decided to ignore it, vote against it and focus on the compounding feature instead, a must have feature for any DAO /s, if you look at the voting outcome and take away Dfinity’s VP the proposal should have passed: Proposal: 72189 - ICP Dashboard so it is clear what the community wanted.
I’m not sure what we can do which hasn’t been done on this front, Wenzel is working hard to make replica upgrades more decentralized but it will take some time, for now Dfinity pretty much controls the NNS and if they decided to ignore feedback there isn’t much we can do other than point it out.
Many builders have also been pushing for better DX for canister upgrades, unfortunately it seems we have a bad habit that causes many pressing issues to be ignored until shit hits the fan.
I don’t think any reasonable person wants to prevent TAGGR from recovering their canister, but we should consider all alternatives before opening Pandora’s box, there might and most likely are better solutions that don’t violate crypto principles and at the same time will help making the IC infrastructure more robust.
Personally I would have preferred if the thread started with the intent of brainstorming what those solutions might be and eventually agree on one.
These are just my 2 cents.
10 Likes
Not sure if it is just me but after reading ALL again top to bottom it just feels more and more like the moment Dominic posted it was already decided that DFINITY will do this no matter what.
1 Like