[Draft] [OBRA] Vue Safe App SDK and Template Development - [IOPLUS]

Proposals Archive
1

Abstract

This proposal aims to expand the Safe ecosystem by developing a Vue.js version of the Safe App SDK and a Vue template for Safe Apps. Currently, Safe provides React-based tools, but there’s an opportunity to broaden the developer base by offering Vue alternatives. This initiative will create a Vue Safe App SDK and a Vue template for Safe Apps, making it easier for Vue developers to build and integrate Safe Apps, ultimately expanding Safe’s user base and ecosystem.

Aligned strategy

[Strategy 2] Foster module ecosystem.

Funding request

30,000 USDC

In our plan, contributing modules and apps to the safe ecosystem is a long-term and ongoing task. Therefore, we shall divide the task into smaller segments. Currently, we are developing safe-apps-vue-sdk and vue-template-safe-app.

Relation to budget

Budget Details:

  • Senior Frontend Developer: $8,000 per month for 2 months = $16,000

  • Project Manager: $7,000 per month for 2 months = $14,000

10% of Total Initiative Budget (30K out of 300K)
100% of Remaining Budget (30K out of 15K)

Initiative Description

Background:
According to the latest State of JS 2023 survey, Vue and React have consistently dominated the top two positions in frontend framework usage. Over half of the developers have experience with Vue.js, reporting excellent user satisfaction. Notably, 99.6% of programmers have heard of or are familiar with Vue.js, making it an almost essential framework for frontend developers to understand.

In js-framework-benchmark performance tests, Vue even outperforms React and Angular.

However, it’s important to note that many survey reports often overlook data from the Chinese market, where Vue has an enormous developer base.

Vue’s influence has extended into the blockchain sector, with many prominent projects such as zkSync, StarkNet, Optimism, and Arbitrum extensively utilizing Vue in their application and module development.

As shown by Safe’s official packages:

1280×754 23.1 KB

There is no template for Vue and no safe-apps-vue-sdk.

(Note: By 2024, most of the projects will not start using Vanilla JS.Because this means they give up the huge mature ecosystem and need high-level programmers to reinvent the wheel from scratch.)

This initiative aims to develop two key components for the Safe ecosystem to complete the Safe ecosystem:

  1. Vue Safe App SDK: A Vue.js version of the existing Safe App SDK, providing Vue developers with the necessary tools to interact with the Safe contracts and integrate Safe functionality into their applications.

  2. Vue Template for Safe Apps: A starter template for Vue developers to quickly bootstrap Safe Apps, similar to the existing React template.

These tools will:

  • Lower the barrier to entry for Vue developers wanting to build on Safe

  • Expand the potential developer base for Safe Apps

  • Increase the diversity of Safe Apps available to users

  • Promote ecosystem growth by supporting multiple frontend frameworks

More modules and app development are planned

Maintenance:
Our team is committed to ongoing support post-delivery. We plan:

  • Monthly review and updates to align with Safe’s latest changes
  • Dedicated resources for at least 1 year post-launch for bug fixes and minor updates
  • Open communication channels with the Safe team to stay informed about upcoming changes

Security & Testing:
In fact, the Vue version of the SDK is based on the existing safe-app, and does not use ethers or web3 to interact directly with the safe contract, so security issues will be greatly reduced.

Of course, in order to ensure quality our SDK, our code will be written in Typescript and have sufficient test cases and enough review to ensure that the code functions with as few bugs as possible.

At the same time, we will invite the community to review our code to reduce the possibility of BUG.

Documentation:
Documentation is indeed key for SDK adoption. We will:

  • Comprehensive and detailed API documentation
  • Provide quick start guides and example projects
  • Step-by-step tutorials and interactive examples for novice developers
  • Establish a process for keeping documentation updated with each release

Usage Analytics:

It may not be appropriate to add statistics function to safe-app-sdk, but we can add statistics to our vue-template, as well as npm statistics about these two packages, which should be able to reflect some usage.

Closing Thoughts
In fact, we are also preparing more directions and are ready to invest in the development of the safe ecosystem.

Current status

The design for this proposal is ready and discussed with IOPLUS team.

The funding will be used to create both the Vue Safe App SDK and the Vue template for Safe Apps from scratch.

Risks

The risks involved are implementation and execution risks. Given the experience of our teams the risks should be minimal.

Timeline and milestones

Week Focus Cost (USDC) Description outcome
1-2 Design 6,000 Research of existing sdk and design of vue-sdk and template, API documentation design, Based on the The plan refactoring the SDK,consider the design of the arch, init the projects readme API docs draft and The two packages safe-apps-vue-sdk and vue-template-safe-app are under safe-apps-sdk
3-4 Development of safe-apps-vue-sdk 10,000 Development of safe-apps-vue-sdk , test cases and documentation safe-apps-vue-sdk, test case and documentation
5-6 Development of vue-template-safe-app 10,000 Development of vue-template-safe-app and documentation vue-template-safe-app package and documentation
7-8 Testing and submit 4,000 Review and submit safe-apps-vue-sdk and vue-template-safe-app review and npm publish these packages

Initiative lead

cosin2077 An experienced full-stack developer skilled in front-end, Node.js, and Web3 technologies.

Team

The initiative will be led by cosin2077, supported by a small and dedicated team proficient in web3 developments.

cosin2077: Developer and tech lead with 10 years of senior engineer experience.
wirender: Experienced and responsible project manager

Additional support/resources

  • Potentially help from Safe team on further github repository transfer or pull request.

  • Assistance in integrating the new tools into Safe’s official documentation and resources.

updates

After discussions with multiple contributors and developers, we have changed the application cycle to two months, and the application amount has been adjusted to 30,000 USDC.

1 Like
2

Hey @chris, thanks for taking the time to write a proposal.

In terms of the proposal, under “Relation to Budget” - these should be in relation to the strategy. In your case,

5% of Total Initiative Budget (15K out of 300K)
100% of Remaining Budget (15K out of 15K)

Additionally, if you want to move your proposal to Phase 1, The proposal needs to be submitted as Phase 1 by today, Monday at 23:59 UTC by updating the title to [Draft] [OBRA] and changing into Phase 1 category.

Also, we usually have Phase 1 proposals present at the Governance call which is this Wednesday at 16:00 UTC. If you would like to join/present, please DM me your email on Discourse or Discord (@amy_safe).

3

Hi Chris, thanks for this proposal. Do you have any quotes/data that prove there is demand for a Vue version from existing Safe builders?

4

@LuukDAO

Thank you for this insightful question. I appreciate the opportunity to clarify this important point.

To be completely transparent, we don’t have specific data from existing Safe builders .Unless the existing SDK has relevant technical statistics, it is difficult for even the safe team to know the technology stack of all safe builders.

But one thing is very clear: as long as it is a safe builder related to the front end, there is a high probability that you cannot bypass react and vue.

As a front-end developer with 10 years of experience, I know this very well.

Our proposal is based more on recognizing a gap in the current Safe ecosystem and the potential opportunity it presents.

We can point to several indirect indicators that suggest there could be significant demand:

  1. Vue.js Popularity: According to the State of JS 2023 survey, more than half of developers have experience with Vue.js, indicating a large potential developer base.

  2. Vue in Web3: Major blockchain projects like zkSync, StarkNet, Optimism, and Arbitrum use Vue extensively, suggesting its relevance in the Web3 space.

  3. Ecosystem Diversification: By offering Vue tools, we could attract developers who are currently not engaged with Safe due to the lack of ecosystem.

  4. Underestimated: Many survey reports often overlook data from the Chinese market, where Vue has an enormous developer base.

We believe creating these tools could itself generate demand by lowering the barrier to entry for Vue developers. It’s a “if you build it, they will come” approach, aimed at expanding Safe’s potential developer base.

2 Likes
5

Thanks for the quick and detailed answer. This helps!

1 Like
6

Hi Chris,

As a fellow builder, it is always amazing to see the dev community rallying together to build tools that make it easier for other builders and I am happy to see that the proposal covers a number of key details. However, there are some key points that are missing which I’ve listed below, hopefully it helps.

Maintenance
I encourage you to provide more input on your post delivery maintenance plans. Given that Safe is an ever evolving product how is your team planning to support the ongoing changes for this SDK once it has been delivered.

Security
What steps will the team be taking to ensure that the solution that is delivered has accounted for any potential vulnerabilities. Given that the plan is to provide a wide spectrum of builders the ability to develop with Safe & Vue, a poor management of the security of this SDK can create supply chain risks which can have devastating impact to the ecosystem.

Testing
Related to the point on security, given that the plan is for wider adoption I’d highly recommend a much more thorough test plan so that we reduce the chances of a bug potentially causing critical failures for users of the SDK.

Documentation
A key part of developing SDKs is to ensure we have proper guides and documentation to help teams get started. Would love to hear your thoughts on whether your team will be allocating time to create documentation and to keep documentation updated post delivery.

Usage Analytics
Although this is not a critical factor, I would also encourage you to think about how this SDK would help with creating some insight on what types of frameworks developers want to use, it’ll be a real waste if your team builds this amazing SDK and you don’t get to see who is using it for their projects.

Closing Thoughts
It is always exciting to see developers taking the opportunity to build things to help the ecosystem grow and the delivery of the SDK would be just step one of the entire plan, therefore I’d encourage you to provide a longer term view of the SDK in order to build confidence in the community that this SDK will be well built, well documented, well maintained and secure.

Excited to see this proposal and looking forward to seeing the updates!

2 Likes
7

@Sunny
Thank you for your thoughtful feedback and questions. Your insights are invaluable, and I appreciate the opportunity to address these crucial points. Let me respond to each of your concerns:

Maintenance:
You’re absolutely right that maintenance is critical, especially given Safe’s evolving nature. Our team is committed to ongoing support post-delivery. We plan:

  • Monthly review and updates to align with Safe’s latest changes
  • Dedicated resources for at least 6 months post-launch for bug fixes and minor updates
  • Open communication channels with the Safe team to stay informed about upcoming changes

Security & Testing:
In fact, the Vue version of the SDK is based on the existing safe-app, and does not use ethers or web3 to interact directly with the safe contract, so security issues will be greatly reduced.

Of course, in order to ensure that there are no problems with our SDK, our code will be written in typescript and have sufficient test cases and enough review to ensure that the code functions with as few bugs as possible.

At the same time, we will invite the community to review our code to reduce the possibility of BUG.

Documentation:
Documentation is indeed key for SDK adoption. We will:

  • Allocate 10% of our development time to creating comprehensive documentation
  • Provide quick start guides and example projects
  • Establish a process for keeping documentation updated with each release

But as you can see, we only applied for 15,000 USDC in total. If we had more budget, we would also like to develop a website specifically for the SDK documentation and create more detailed documentation.

Usage Analytics:
Great point about usage insights.
It may not be appropriate to add statistics function to safe-app-sdk, but we can add statistics to our vue-template, as well as npm statistics about these two packages, which should be able to reflect some usage.

Closing Thoughts
In fact, we are also preparing more directions and are ready to invest in the development of the safe ecosystem. If this proposal is accepted, we will contribute more and better modules and apps.

8

I’d suggest looking at requesting more funding and expanding the scope to accomplish more of the above items. My fear is this proposal as written doesn’t get far enough and could place novice developers at risk. What could you do with $30k?

1 Like
9

@kdowlin

Thank you for your suggestion.
It seems that the remaining budget for strategy 2 has been exhausted. Will it be acceptable if it exceeds this budget?

If our budget is $30K.
We can do much more than we do now.

  • Extended Development Phase to Increase quality and improve functionality.
  • More robust error handling and comprehensive type definitions for better developer experience.
  • Extensive Testing.
  • Comprehensive and detailed API documentation(Separate documentation website)
  • Step-by-step tutorials and interactive examples for novice developers
  • Post-Launch Support and Maintenance 1 year
  • Community engagement for feedback and improvement suggestions

Maybe more.

However, can we introduce additional and enhanced functionalities through subsequent proposals?

Moreover, should the proposal be extensive, prolonged, and fraught with variables, the implementation may encounter challenges.

Maybe we can complete this proposal first, and then consider the subsequent proposal.

10

Just a heads-up on our plans with regard to the Safe Apps SDK going forward.

Internally, we’re discussing refactoring the SDK to be more standards-oriented. Namely, it will leverage EIP-1193 and EIP-5792 (which aligns very well with how Safe multisig transactions work). This will allow both an easier integration with existing dapps via various wallet connectors, as well as a framework-agnostic way of building new apps that can act as both standalone dapps with any wallet and as Safe Apps that support things like batching.

More details here: Dinky Dog: shareable flow diagrams

11

Thank you very much for the information you provide.

EIP-1193 was drafted as early as 2018 and has garnered support from a multitude of prominent libraries, including ethers.js, web3.js, viem, etc.
In fact, most of the current web3 development is built upon this proposal.

EIP-5792(Created at 2022-10-17) primarily aims to augment JSON-RPC methods, enabling applications to handle batches of on-chain write operations(wallet_sendcalls) while verifying these actions(wallet_getCallsStatus).

It is happy to see the safe team engaging in these refactorings.

It is important to clarify that this is not in conflict with the Vue.js version of the SDK we are developing, along with the templates. We are a complementary community to the Safe App SDK.

Refactoring can be a prolonged and difficult task, especially for a project with high security requirements like Safe. The timeline for such endeavors in the realm of robust security measures may span across years.
However, our development efforts can be completed within a mere month’s span.

In fact, irrespective of the frontend framework employed, with the utilization of @safe-global/safe-apps-sdk, we can accomplish the development of the application.

Furthermore, we possess the capability to interact with Ethereum directly by invoking JSON-RPC, even without the reliance on external libraries.

But as we all know, there are great differences in the technical levels of programmers. In order to meet the needs of programmers of different levels, it is imperative to lower their development threshold.

This is also the point to which the Safe App SDK development team has consistently dedicated their efforts right?

In discord and issues, many developers have been asking questions about Vue, and even more people, perhaps because there is no Vue version of the SDK, have given up their development or switched to a framework they are not very good at.

Indeed, we intend to consistently synchronize the Safe App SDK with its updates.

Welcome everyone to engage in discussions.

12

Fair enough, just keep in mind an integration with the current version of the SDK will be somewhat outdated when this new refactored version comes out. There’s no timeline for that yet but it’s not years. Likely by the end of this year.

I must also add I don’t see a sufficient scope for a senior developer working on this for an entire month. From our estimation based on the time it took to create the React wrapper, to create a Vue starter template and bindings + write documentation for it is a matter of a few days.

14

Since there are many recent discussion updates. Tagging @auryn @v3naru @BraveNewDeFi @pet3rpan-1kx @kdowlin @denham @0xBaer @adamhurwitz.eth @bernard @jengajojo @Ivan @Sunny @LuukDAO @corbinpage @0xjack as well to either approve with voting power or provide feedback, in case the original folks don’t notice in time.

1 Like
15

Given the SDK sounds like it is being refactored and limited budget in this strategy I’m not convinced this is the correct time and sprint for this proposal.

16

We apologize for not updating the proposal promptly. We have now adjusted the timeline to two months and the budget to 30,000 USDC.

17

Hey Chris,

Thank you for the updates. Whilst I do appreciate the effort, I think you’ll probably need to wait and gather more input from other community members, the Safe Dev Team and further refine this proposal. I understand that this might end up delaying the work but I hope your team will keep trying to refine the proposal and push forward because I do see the value in having support for Vue.

Additionally, I would also like to recommend that for a proposal like this you should first work towards identifying what is the minimum deliverable needed so that I creates value for the community, for example in this case, you’d need have things docs etc to be in place so that community feels confident in using it. Once the minimum deliverable is determined, you can then look at how much time and money it’ll cost and quote accordingly.

By approaching it this way, you will ensure that the deliverable is something that is immediately useable and creates value. Then the community can look at its metrics to determine whether there should be further investments into increasing the value the SDK brings.

Otherwise, you’d potentially end up with a deliverable where if it ends up not being used actively, you wouldn’t be able to confirm whether it is because the community doesn’t see its value or because it is not complete enough to be used effectively.

All the best!

1 Like
18

Thank you very much for your response, we will consider it seriously.

19

Hello, unfortunately this proposal did not receive sufficient signaling from Guardians and Delegates to move onto Phase 2: Voting on Snapshot.

You may propose again at a later sprint (earliest is Season 3, Sprint 4 on September 2nd).

20

There is only one month left until 2025. Any updates about your SDK refactor?

21

As I mentioned, the new SDK won’t be a proper SDK anymore – it will be a regular, RPC-based, Ethereum provider, so framework-agnostic. Most of the apps we see added to the Safe Apps “store” are regular dapps + some glue provider code to make them work in Safe. We don’t see the demand for a custom SDK.