It’s extremely basic, it lacks all the token related functionality: staking, initial distribution, etc… and doesn’t have any UI, a good place to start but far from the “no code” solution the SNS is meant to be.
2 Likes
Can you clarify this point that Jan made a couple months back?
Also, there was talk of a “blog post” that would be released on this subject.
I think a lot of this “pushback” from the community is coming from either a big miscommunication, or a flip-flop of DFINITY’s position in terms of it’s relationship to the community and the NNS.
We’re all just trying to find out where DFINITY stands with respect to the community, and to the NNS.
- What are DFINITY’s mandates to the community and the NNS (are there any?)
- What are the activities that it partakes in to oblige the community (but does not feel it is mandated to do so and could refuse).
It would be nice if communications at DFINITY could draw these lines for us.
4 Likes
Not sure what you mean with “overengineer the SNS” therefore just want to point out the fact that from the NNS-dapp frontend, “JavaScript code wise”, and my personal perspective, it is being developed with the same architecture as NNS related services - i.e. not “over-enginered”
There is a JS library sns-js that is being actively developed so that NNS-dapp can use it to interact with Snses but also, so that any devs can use and embed Sns related features in their dapps or NodeJS scripts without having to rewrite that particular layer.
It’s the same approach as with the other library nns-js for Nns.
Both libs are available in a mono-repo but, still need proper documentation as @diegop said in his original post. That’s the plan.
Hope this clears a bit some worries about “overengineering” the frontend. Let me know if you have questions about it.
3 Likes
I semi get this. Not quite enough if I were tasked to fix it (the bar for true grokking).
To me a simple Tokenized dapp DAO that would address your intent would be:
- A ledger canister
- A governance canister that uses tokens from #1 to vote and execute on code upgrades
- A backend canister controlled by #2
- A frontend canister controlled by #2
Would that be closer to what you are looking for?
1 Like
To be honest, that’s a very very reasonable ask, but I’d like to confer to Jan first to make sure I grok his intent (and how it may have evolved) to reconcile past and present. (This may take a while because he is out this week).
1 Like
ICP is not Ethereum and Ethereum is not Bitcoin. Just as the functioning of the Bitcoin network cannot be a model for the Ethereum network, the functioning of the Ethereum network, which has fostered a bunch of centralised monopolistic providers, is not a perfect model for the IC. The IC does far more than Ethereum can ever hope to do and consequently the Dfinity Foundation has to build out further than the Ethereum Foundation does, way beyond ‘core protocol’.
Having said this, there are trade-offs in the Foundation building apps as a number of contributors have pointed out. While I strongly support the initiative to build the II, and think the SNS is also a net positive, there is no doubt that there are downsides. First, Dfinity remains all-powerful and the final decider on prioritisation, as @harrison has pointed out. Secondly, a crowding out of developer initiatives in areas that Dfinity has staked out, as @skilesare has recorded.
My suggestion is that Dfinity should adopt a five year decentralisation roadmap. In this, the philosophy of the Ethereum Foundation is absolutely relevant:
“We often describe this as a philosophy of “Subtraction”. This means resisting the natural tendency of organizations to grow and accumulate value within themselves, and cultivating value creation outside the Foundation in the broader Ethereum ecosystem:
Instead of capturing opportunities, we distribute opportunities for others.
Instead of being defensive when others create value, we’re thrilled.
Instead of trying to matter more, we try to matter less.”
The first five years of the IC involved Dfinity directing almost all development. The five years from genesis should aim to put Dfinity on a path of subtraction, where its workforce first plateaus and then begins shrinking as independent developers gain more leverage. The third five years would involve the philosophy of subtraction being fully realised, and nominated developers gaining voting rights within Dfinity itself, so that the Dfinity neuron more fully expresses the will of the community.
2 Likes
The criticism of “excessive design” does not stop at the front end, but at the design of the “initial token exchange”, “rewards module”, “community fund” and so on.
This shows the DFINITY Foundation’s consistent attitude of guiding the development of applications in a strong manner.
It is mind-boggling that the token standard related system includes a launchpad. Why does this application-level item need to be part of a basic system feature? And as a necessary part of the sns?
Another excessive point is that developers must first propose to NNS, and only after the proposal is approved can they use the initial token exchange function of SNS, thus deploying tokens in the dedicated subnet of SNS and enjoying the security of the dedicated subnet.
Otherwise, developers can only deploy their own tokens and DAO in the application subnet and endure lower security.
Most of the above discussion is from the developer’s point of view, but we have never thought in terms of community users. The community of ordinary users will only accept messages from the official (DFINITY foundation), and the official recommendation of roadmap and SNS makes users only dare to accept tokens under SNS guarantee.
In other words, even if the developers themselves use the SNS source code to deploy a set of their own tokens and DAO contracts in the application subnet, the community users do not dare to trade these tokens, they will think that these tokens are “not certified”, the community will only pay attention to those certified token.
Therefore, “anyone can pass the source code of SNS is not their DAO” is a nice but useless slogan, in fact developers are still put in a very awkward situation.
NNS vote actually put a heavy tax on developers, who must owe the ICP a huge whale.
So what can developers do? Please give developers some reasons to persist.
3 Likes
I have always been a big supporter of IC and they have done a lot of great work in the past. But unfortunately, since launch, the IC ecosystem has been really slow to grow, and one of the reasons is that DFINITY have been too forceful in prescribing what developers should do, rather than encouraging them to create.
Obviously, part of the development of the roadmap will be decided internally by the foundation and part of it would seek the community’s input. Therefore DFINITY chose to produce all 25 options at once and let the community vote on them to gather feedback.
But, embarrassingly, these votes were meaningless and more like a “decentralized” political show. Launching 25 proposals at once only tells the community what the IC can achieve in the future, not a roadmap, because there is no mention in the proposals of the time and cost needed to get there, or the benefits. Also NNS cannot determine the order of priority for each of the roadmap options.
The DFINITY Foundation shouted 25 slogans but had no actual plan. In the eyes of the general governance of the community, every proposal is of course good for IC and they will inevitably vote to adopt it. But what the community really needs is a roadmap for “when we should do the right thing”.
At the same time, the community is completely unaware of how these proposals are being implemented with DFINITY Foundation, which is very opaque. For example, why did the DFINITY Foundation implement the People’s Party first, instead of developing a token standard for the DeFi model, when the proposals were all adopted at the same time? Why did DFINITY suddenly abandon the development of the People’s Party and invest in the BTC integration? Why did you suddenly delay the development of “BTC integration” and implement “SNS” instead? Why didn’t you let the community decide the priority at the beginning? Who is responsible for the waste of resources and time in the middle?
The community did not know about this, the Foundation made the decision and invested the resources on its own. The foundation also did not tell the community the reasons for making this decision. The community was simply informed, “Now we plan to devote major effort to xx, so we are delaying xx.” This is where the community felt they were not being respected and that the governance of NNS was almost null and void.
I think it’s okay to be properly centralized early on in a project to accelerate growth. In fact many protocol foundations have been successful this way. But DFINITY only tells the community what we will do, but there is no actual plan.
6 Likes
The problems with SNS actually reveal the principle mistakes made by DFINITY Foundation in making the underlying design. That is, the infrastructure should be kept pure, and should not dictate to the application layer, and should not increase the cost of developers.
As you can see, much of the system layer design of IC leaves no space for future developers, and many possible paths are blocked.
For example, II is indeed a cool technology, but its overly aggressive design at the application layer results in the same identity not being consistent across multiple conisters, which directly results in data not being interoperable.
While data interoperability is basically the cornerstone of Web3, the foundation of IC builds a large number of usable data layers for Web3, but II makes it impossible to connect the data. If DFINITY had designed II to include more optional privacy models, rather than brutally mandating that all users must be in the highest privacy state (deriving a new ID for each conister visited), developers wouldn’t be as embarrassed as they are now.
Examples of this also appear in the initial token exchange for SNS (why not let the community make its own LaunchPad?), the community fund embedded in NNS (why not let the community implement its own Venture DAO?), and many other details.
DFINITY should focus more on what developers really need, rather than trying to guide developers on how to implement applications. Even centralized Apple doesn’t limit its eco-developers in this way.
2 Likes
Sorry to interrupt any other conversations going on here, but I wanted to provide feedback and thank @diegop for typing all of this up.
I’m so happy to see this table and get more transparency into how DFINITY is allocating its resources. I want to emphasize that I wanted the community to strongly consider DFINITY’s role in things, and getting more transparency was a key point to understanding more. Now that I can see more clearly where the resources are going, I do feel better. It seems there could be up to 20% of resources that I personally feel are misallocated (again, UP TO 20%, probably not a full 20%), but I don’t see a deeply existential problem like I feared might have existed here. I do think on a case-by-case basis there are things I think DFINITY should or should not focus on, and I believe a guiding principle should be to focus more on the protocol layer.
4 Likes
I agree that the NNS is quite integral to the IC protocols, though I’m not sure how integral II is. There are other ways to authenticate. I really like the core principles of II and I’m not necessarily saying DFINITY shouldn’t have built it or shouldn’t continue to improve it, but I’m not sure it’s as integral as some think it is. And to be clear, I’m trying to point out that technically and practically speaking, I believe II did not necessarily have to exist. There were other paths, possibly much simpler paths for authentication that would have still worked. Basically something like a MetaMask extension/Plug/or any of the other ways blockchains authenticate themselves.
2 Likes
I agree with you on much of your first two of 3 posts, but not sure I follow this point.
Users own their data in Web3, not applications. Web3 means users have greater privacy and their direct interactions and data sharing with applications are NOT traced across applications without their consent.
II is pretty brilliant in that it does exactly this, and it is unique to the IC - no other blockchain has a similar solution.
I therefore don’t believe something like II would have ever been built by anyone other than DFINITY. They have user privacy at the front of mind, and don’t have any competing financial interests that could compel them to monetize user data and compromise that privacy.
I for one do not want to be linked across the IC, and that’s why I exclusively use II or solutions based off of II. For those who still want it, the other IC wallets provide a more traditional web2 experience, but they also allow one to be easily traced through a single, unified principal.
@blockpunk Features such as the new alternative origins feature for user login help II achieve what you’re struggling with - allowing users to have a single principal throughout a developer ecosystem, but not outside of that ecosystem.
2 Likes
I don’t mean any disrespect to any devs/engineers working on the frontend code. My opinion here is based on my own frontend engineering experience.
The fact that the NNS frontend was first written in Flutter was an engineering mistake. The limiting factor as pointed out was that the dapp had to be rewritten. If it had been built from the ground-up using sounder frontend engineering principles (declarative design, component model, standards-based web components, or similar tech) then it would not have had to be rewritten.
And the current SNS frontend from my knowledge will not be based around native, standards-based web components that can be used across nearly all frameworks and libraries for all of the major browsers. These engineering mistakes, IMO, will cost DFINITY and the community as they already have. The II is another example, I’ve seen the frontend code and it isn’t declarative and component-based and doesn’t embrace native web components that can be used across nearly all frameworks and libraries.
DFINITY isn’t embracing the most sound frontend engineering principles, and even with their rewrites they aren’t doing this (to the extent I would like to see). Perhaps my opinion here is very subjective, but it’s based on what in my experience have been the most sound principles you can build on top of for frontend engineering.
Basically:
- Declarative design
- Component model
- View as function of state
- Embrace web components (custom HTML elements in particular)
This would lead to the simplest code, easiest to understand, easiest to compose applications across the community, and the longest-living code (won’t have to change because built on standards).
5 Likes
Clarifying question:It seems to me you are suggesting the NNS Frontend dapp could have used a simpler Metamask/Plug style authentication and not have the more complex II (at Genesis or after).
Did I get that right?
1 Like
If the NNS dapp were built from custom HTML elements that were designed to be extremely composable, then many SNSs of various kinds could have easily been built. But it hasn’t been designed this way and continues to not be designed this way AFAIK. What’s worse is that we’ll now have to be under the same domain as the NNS and even get an NNS vote to approve our SNS. I’ve stopped following the SNS lately, so if I’m out of date please let me know.
It’s not the composable system that I hoped to have, where I could pull in the backend and frontend components necessary to build my own solution. Instead I’m being provided a highly permissioned solution that I will feel trapped in. Basically, if I’m even going to use the SNS, I will have to fork. The main purpose of the SNS I felt was to allow people to quickly spin up what they needed, with minimal forking and custom code.
2 Likes
I thought one of the main purposes of the SNS was so that we did not have to launch our own versions suited to our needs, the SNS was supposed to provide a DAO-in-a-box.
4 Likes
Even if the code is open, if it’s not designed in a modular way it will take more work for devs to incorporate it into their dapps. I would like to cargo install or npm install and have simple well-documented interfaces, relying on the stability of upstream code. I don’t want to have to fork and then maintain my own version of the SNS unless I absolutely have to.
Here’s the engineering issue I most foresee: the SNS will not be modular, it will not be a set of reusable frontend/backend components with clean API interfaces that I can drop into my applications. Instead, I imagine I will have to fork the core code and modify it to my needs. Foreseeing this, I will probably just develop my own solutions, and sadly I may have to build and encourage others to join me in building the composable building blocks I hoped the SNS to be.
Also, guiding the whole community towards one way of launching a decentralized dapp, especially with the fundraise, seems inappropriate for various reasons, mostly focused around legal. Each dapp is responsible for their own legal compliance, and officially sanctioning one way of fundraising is very strange and I think legally questionable.
6 Likes
And even given the table of DFINITY resource allocation, in the case of the SNS, I feel too much time has been spent on it. I keep hearing how certain features or issues are blocked by the SNS. IMO it’s blocking far too much, and it won’t even be the modular solution that I hoped for.
Hopefully I’m wrong about all of this, it’s just the feeling I was getting as the SNS continued to move forward, seemed the modular design I had in mind was slowly fading away.
6 Likes
Correct, I’m assuming that would have been/is possible.
1 Like
I am not quite sure I follow here. I see these as two very different potential goals in your sentence:
a. DAO-in-a-box to make it easier for people
b. Inhibit/discourage anyone in ecosystem to make a DAO framework by having the DAO-framework for all time
In your mind, do you see as a) and b) linked? For context, I have never thought b) was a potential goal of SNS project based on any communications… but its possible I am misunderstanding or mischaracterizing your sentence.