Quick formal reaction to the great town hall that Psychedelic did today. A couple of affirmations and a couple of critiques.
We need discussion like this - some of this was critical to the DFINITY Foundation, but critique is healthy and in helping any organization get better.
All eyes on the foundation - The foundation has assembled such an amazing set of researchers, programmers, and crypto experts that all the eyes are justifiably on them. When they speak people listen and when they say something will happen, everyone who was working on that thing stops. Supernova took everyone’s attention in a good way…the community needed that bump. A few other initiatives have moved all the eyes onto a single solution and keeps others from engaging in experimentation. It is both a blessing and a curse and I don’t envy the foundation in trying to make the decisions about when to step up and when to let the community run. It is hard! So I hope the foundation can take the critiques in a positive light and work to better identify when they should step in and when they should let the community run with things.
Psychedelic’s suggestion was that the rubric to use should be stick to 1. Stick to the protocol level and 2. You can’t/shouldn’t solve every issue at the protocol level. I don’t know that that is the right rubric, but I also don’t have a better suggestion. When the Foundation says they are going to solve a problem all but the most well-funded outside contributors stop working on that problem. When the SNS was announced work on DAOs from the community drastically fell. I think maybe Origyn and FlowerPowerDAO are a couple of the few that took a swing at the plate. In helping Origyn I’ve learned how insanely hard they can be and what nuance is necessary to keep them going.
That brings us to the SNS. I’m a Min/Maxist on the SNS. I think it is an amazing solution in 5 years, but an extremely dangerous thing to accelerate in the short term. I don’t have any insight into the actual timing DFINITY has, but it FEELS way too fast. If we’ve one of these protocols securing hundreds of millions of dollars for an extended period of time and demonstrating competent and functional governance, we could absolutely consider elevating it and putting it under the purview of the NNS, but to my knowledge that is not the process that is being proposed. We haven’t even proven that the DFINITY network is well tuned to support the PoS model for on-chain governance. We are currently voting on Internet Computer Network Status which specifically pits short-term gain vs. long-term health of the network and short-term gain seems to be competing to a level that might undercut the fundamental assumptions about how this on-chain governance stuff is support to self-balance itself.(There is lots of nuances here that we can/should debate over on the appropriate thread)
On the other hand, I’m very bullish on the DFINITY foundation publishing audited and working contracts that other people can fork and experiment with. They have the resources to build great code and then release it into the wild.
How do you walk back where the SNS is right now? Release the open source contracts for SNS ledger, SNS governance canister, SNS Swap canister with strong defined and decoupled interfaces between them. Let 50 DAOs select the pieces they want and experiment with others. Give us a rust + motoko ledger and a rust + motoko governance canister and a rust + motoko swap canister and let us fiddle with them. Once we have lessons learned we can talk again about promoting things to the NNS and if that is a good idea or not.
To push back on Psychedelic a bit I raised that the ICRC-1 standard was very much community-led. ORIGYN pushed very hard for some attempt at a solution to the many-standards problem after implementing the OGY token with Sonic. This was way more complicated than it should have been for the sole reason that DIP20 and the IC Ledger Canister both use “transfer” as a function name. Our request for a solution coincided with other community desires and DFINITY agreed to run the workshops. I think this is/was a good use of DFINITY’s power. They have done a decent job of listening. The pressure for burning in the standard for the purpose of the SNS is not a great pressure to have, but in general, I think the working group has made some good progress. The goal is maximum interoperability. In the last meeting, we discussed making sure we present a narrative that while there is a “base standard” there are also “Recommended Extensions” that provide maximum interoperability with other pieces of the IC. Those are 1. Approval/TransferFrom, 2. Transfer and Notify, and 3. Query Blocks. Other optional extensions like a rosetta extension were also discussed. We also discussed(and are still discussing) having the SNS team commit to implementing those recommended extensions on a timeline so they can move forward and the rest of the community can begin to prepare for a maximally interoperable world.
Psychedelic has indicated that they are open to namespacing(which would likely make the need to have “1” standard unnecessary and enable health competitive innovation). I’ve discussed how this can be used on a go-forward basis by both EXT and DIP20 just 1. adding namespace functions 2. using them as wrappers for the current functions and 3) removing the unnamespaced functions from the documentation. This solution would be almost no new code(and certainly very safe code to add) and I’ve talked about it before(Proposal to Adopt the Namespaced Interfaces Pattern as a Best Practice for IC Developers).
I don’t think we need to re audit:
Public shared(msg) transfer_dip20(principal, amount) : async Nat {
return _transfer(principal, amount;
};
Public shared(msg) transfer(principal, amount) : async Nat {
return _transfer(principal, amount);
};
They also indicated that they wished that DFINITY had tried to improve an existing standard. I think the ICRC group was being pretty accommodating to the things that Psychedelic was bringing and trying to come up with good accommodations that also preserved some of the power of the IC(like sub-accounts that canisters might want to use because they can’t natively have multiple principals). I don’t think any on the ICRC-1 working group is tied to calling the thing ICRC-1 over DIP20 2.0. The concepts also map 1:1. If DIP20 concedes on sub-accounts and DFINITY concedes approval flow, don’t we have a win and the name on the thing is irrelevant? Transfer and notify can come in DIP20 2.1. There are real and important use cases for transfer and notify.
I’ll also push back on the idea that we should do wrapped tokens just because ethereum does it that way. This came up during the town hall with the suggestion that DFINITY was motivated by a desire to not have WICP. In general, the IC is much more powerful than other chains, and limiting ourselves to previous patterns that emerged due to a single “shard” and limited gas set us up to fail by choosing not to use the superpowers we have at our disposal. From my personal experience, there was an intense desire to not have the OGY token wrapped when interacting with DeFi from our leadership team. We wanted the token itself to be used. In simple scenarios like a fungible token, wrapping is a convenience and an accident of implementation. I think it ultimately ends up being bug because once you go to any kind of complexity(and the IC enables complexity), wrapping is a way to route around the intended logic of the underlying smart contract. A simple(maybe dumb) example would be a token that wants to support some feature based on a transaction tax(like a sales tax). If you wrap the token and trade the wrapper the smart contract can’t operate as intended(we are about to see this problem when neurons become trade-able once ecdsa lets canisters hold neurons. Creating wrapping resistance is hard but will ultimately enable more complex and useful smart contracts.
That wasn’t very quick or formal. Sorry about that. Hopefully, we can keep having constructive conversations about this. The community will only get stronger if Psychedelic communicates more and lays out their reasons. There is a TON of lessons learned in that organization that we all can learn from.
Thanks for contributing to the conversation and moving it forward.