Questions and concerns about DFINITY Foundation working "beyond core protocol"

No b is not what I’m thinking here at all. Instead I was hoping/thinking that the SNS would lift a huge burden off of the community by creating many modular pieces that could be composed into most DAO solutions that we would want, so not necessarily discouraging other DAO solutions, but the idea is not many other DAO solutions would be necessary because the SNS would be so generalized. And the pieces could be formed and pre-packaged into specific DAO tools, by anyone.

And then others could create just the modular pieces that are missing, if the SNS didn’t provide them. They could be pushed to crates.io or npm and downloaded by whoever needs them. Many would be SNS modules built by DFINITY, some would be built by the community.

6 Likes

@diegop Well said by Jordan, but to simplify it just a bit:

Developers expected the SNS to be a set of easy-to-use & modify, modular, plug-and-play libraries.

What developers seem to be getting is an easy-to-use, opinionated (hard to customize), end-to-end product.

9 Likes

Ohh nice simplification, I think this captures it.

But also, I don’t have a problem with products being offered to us, as long as the libraries are also offered to us. The idea is that anyone can create products out of the libraries.

7 Likes

Yes and no.

Yes that’s correct, the current UI components that are developed for Sns in NNS-dapp are developed in Svelte.

But no, it is not integrated in a monolyth way.

As I said in my above post, a library called sns-js (repo) is developed for the API layer to communicate with Snses.

So while I agree, there isn’t currently out of the box UI web components, developers can use this library to interact with Snes - i.e. develop their own UI without having to re-develop the API layer.

In addition, this is the current state. As far as I know the foundation is open to the idea of components for the future as well.

Of course, here I am biased. Based on my experience, I think the architecture of NNS-dapp fist well a modern frontend architecture. We split the app in various layers (api, services, stores, ui, etc.) and develop libraries (nns-js, sns-js, etc.) so that the community can reuse the communication layer. In addition we are in the process of extracting all UI components (“design system”) to a dedicated lib.

That being said, as for the libraries, NNS-dapp need documentation including architecture. We are aware of this and it’s something we aim to improve soon.

p.s.: happy to have a chat about these subjects if you wish

8 Likes

Just discussed with my colleague @lmuntaner and to give a bit a more concrete answer to your comment about architecture: yes we think that points 1 to 3 are indeed covered by NNS-dapp architecture except 4, as we both know.

3 Likes

:100: I’m almost more disappointed in the community for not understanding this basic point. Not surprised if DFINITY feels the need to babysit us.

I’m incredibly grateful for the unique properties of Internet Identity compared to potential alternatives, and for what it can enable in things like NFID.

I also appreciate that it was built by DFINITY. By using the NNS I’m already implicitly trusting the foundation so it’s not much more to ask to trust their authentication mechanism as well.

If there were only 3rd party ways to authenticate I probably wouldn’t have felt comfortable without doing a lot of research.

7 Likes

For us it’s not so much about the SNS, it’s about the payment

Nothing to stop you from using II in the context of a wallet like Infinity Wallet, to preserve identity across devices. Identity provider != wallet imo.

1 Like

Sorry, not sure I follow, which “payment” are you referring to? (Apologies if obvious)

@lastmjs, I would like to clarify your constructive criticism of Dfinity’s front-end work.

Would you like Dfinity to stop building application level tools or would you like them to build them better? All of your suggestions and recommendations are about how they could have made them better. Or both? Do you not see a world where Dfinity hears customer (dev) feedback such as yours and incorporates it going forward?

@diegop to the extent this doesn’t already happen, I do think it would make sense to incorporate feedback and institute WGs on all application level tools. It seems this happened with the token standard but maybe not as much with II or the NNS. Am I right here?

3 Likes

Good question. We have the following WGs:

  1. Topic: Identity & Auth
    DFINITY lead: @frederikrothenberger

  2. Topic: Developer Tooling
    DFINITY lead: @dfx-json

  3. Topic: Ledger & Tokenization
    DFINITY lead: @mariop

  4. Topic: Scalability & Performance

So I think both are true (non controversial) statements:

  1. There is an II working group
  2. It’s still early days in WG so more WGs (and deeper collaboration) is an improvement we all agree on
  3. Not all WGs listed above would have likely have addressed @lastmjs and others concerns

The NNS UX should have been cleaned up before the SNS was started. Currently the nns looks like a hello world bootstrap project and that’s my personal biggest gripe.

I would also add that dfinity creating products like a SNS in my opinion has slowed down adoption. Everyone in the ecosystem has to wait for the SNS. If the ecosystem would have created a launcher project we would have several and competition would decide which one is best. But in current world people don’t want to compete with dfinity and why would they. Dfinity will use their power to market the sns and competing projects will be looked at as off brand.

I’m not a developer in the ecosystem but as an outsider that’s what I see.

That’s where I think I could see projects complaining

3 Likes

Hi @blockpunk

I’m working on the II team and I would like to address the points raised here:

We absolutely do understand that interoperability needs to be improved. And yes, right now II does not support any form of interoperability between services. But starting from a strong privacy model and adding opt-in features to relax it is by far the better approach for a sound and sane system than going the other way (which might not even be possible; once you give information away, you cannot get it back).

To address this, we have the following items on our roadmap (see our roadmap update thread):

  • Delegation of fine-grained permissions
  • 3rd party attributes
  • Renewable short lived delegations (which is required to do long-term delegations)

Unfortunately, all of those are a) a lot of work and b) pushed back by other items that are required to just keep Internet Identity accessible and working (i.e. II Domain Migration and Multi-Canister Architecture).

Be assured that we want to improve Internet Identity for both users and developers.

Also, Internet Identity is open to external contributions. If you want to speed things up and help with the development of one of the issues above please reach out. It would be greatly appreciated. :slight_smile:

9 Likes

This is all great! Though what I am getting at here is that in addition to not having to re-develop the API layer, it would be nice for developers to not have to re-develop the UI layer.

2 Likes

If the design system is also being pulled out then most of my concerns on the frontend architecture, for the NNS and SNS, have been addressed. I just hope the design system will be web components and not dictate a framework.

3 Likes

Very excellent. It would be nice for Internet Identity to be developed in the same way.

2 Likes

I guess I’ve been conflating the two arguments. I think I’m coming to a personal conclusion that I believe DFINITY should have the guiding principle of giving highest priority and focusing most resources on the protocol level, and I believe they are mostly doing that after the recent round of transparency on where resources are allocated. On a case-by-case basis I think app-layer concerns might be appropriate for DFINITY to get involved in. For the SNS, I started off very optimistic but over time have changed my opinion. Now I feel it may be better for DFINITY to not work on it. But if they are, then I would like it to be architected as well as possible so that I can work with it (both working in the codebase if necessary and incorporating it into my own applications).

So, I want to see DFINITY aggresively focus on the protocol layer and prioritize it over anything at the application layer. On a case by case basis, some app layer meddling may be appropriate. Personally, I don’t think I’m in favor of DFINITY working on SNS and People Parties, as two examples. If DFINITY wants to pursue them, I’ll most likely provide feedback to help them succeed.

3 Likes

Drive-by comment:

I think some amount of application-layer development is necessary in order for DFINITY to eat their own dog food.

7 Likes

Yes, and I feel it somewhat inappropriate for me or other community members to even try to dictate what DFINITY, an independent contributor to the IC, does with their time (besides providing feedback and suggestions). But, there’s a conflation with DFINITY and the NNS DAO it seems, and DFINITY has invited us to direct their efforts through governance proposals…

2 Likes

I appreciate that. If it makes it easier, we the foundation are asking for feedback on this from smart dedicated folks such as you all. This is a dialogue and we see it as such @lastmjs . Definitely something we ask… so it’s all fair play.

3 Likes