Zemo - Your Web3 Inbox

Sorry for the delay in sending a forum posts that elaborate ZCG’s questions about Zemo. First, let me say that I personally love the enthusiasm and the track record you have of completing grants with ZCG. In my personal opinion, the concerns around Zemo is more about correctly evaluating cost, use case timing, and coordination with others. I will outline the specifics points we had questions about below:

  1. Quick anecdote: I have been an advisor to Status for at least 4 years. Status is a mobile crypto wallet and messaging platform that uses a decentralized messaging framework for censorship resistant conversations. Status has not seen very much growth/adoption, even when there are loud complaints from various crypto communities for alternatives to Discord and Slack. Although I feel like their team had great ideas and were super early innovators, things didn’t pan out because building, maintaining, and marketing a messaging app is very difficult.
    Status’s messaging platform in their app did not require payment, but it seems like Zemo’s would if they were publishing shielded memos to the chain. It is hard for me, personally, to see people replacing Signal and other messengers with E2E messaging with Zemo when it will cost $. Even if the costs are fractions of a penny at first, shifts in ZEC price or explosions in adoption will make the messaging costs rise, especially with heavy use. You mention potentially moving to L2s, but in my opinion L2s are just getting their grounding in other ecosystems like Ethereum and it has taken years for building and adoption.

  2. You mentioned in the grant you plan to coordinate with other wallet devs and the ECC. Have you connected with anyone from either of those groups yet and what was their feedback? This will be helpful because you also mentioned in the grant that you want your code to be open sourced and for others to build on it.

  3. ZecWallet is a barebone, minimalist Zcash app for sending payments. How do you plan on repurposing the app? Specifically, would you be making upstream changes to ZecWallet, would users need to download both a ZecWallet App and a Zemo app, and would there be an import function for keys from the ZecWallet app to import to the Zemo app?

  4. Has your team deployed mobile apps? If yes, please list them.

  5. As the potential launch will be in 2nd half of the year, do you plan to support Unified Addresses by default?

  6. Conversation apps are complex and we would like more details of implementation beyond a few paragraphs of intro.

  7. Modifying the existing ZecWallet codebase to Messaging first is manageable, what often gets overlooked is the cost of ongoing maintenance. Who is going to keep up to date with the fixes for the underlying codebase? What would those costs look like after the 6 months funding period?

  8. ZecWallet’s future is uncertain as @adityapk00 has taken a step back, how do you plan on maintaining a fork a customized codebase that is partly diverged from the upstream lightwalletd backend service? Who will be responsible to maintain the app in the App Store/Play Store?

  9. You mention in the grant “Shielded messaging has risen to become a popular use case in the Zcash community.” What information are you using to back up this statement?

  10. How would you be licensing your software and how does your license interact (if at all) with ZecWallet’s?

  11. What is the rationale for using IPFS for the avatars? Pinning in IPFS is still dependent on a server deciding to pin the avatar and if you plan on holding that data forever it is no better than an AWS server for for the sole purpose of storing pictures. Many NFTs on Ethereum use IPFS for their images and now no longer have access to the images for the NFTs because the startup who made the NFT decided to stop pinning the image.

  12. How many team members will be working on Zemo? The budget seems high for a 2 person team based on some previous grants that have been administered.

Thank you for taking the time to read through this and respond. Sorry again for the delay!

10 Likes

Sorry for the delay in sending a forum posts that elaborate ZCG’s questions about Zemo. First, let me say that I personally love the enthusiasm and the track record you have of completing grants with ZCG. In my personal opinion, the concerns around Zemo is more about correctly evaluating cost, use case timing, and coordination with others. I will outline the specifics points we had questions about below:

I appreciate the good words and the apology. :beers:

Quick anecdote: I have been an advisor to Status for at least 4 years. Status is a mobile crypto wallet and messaging platform that uses a decentralized messaging framework for censorship resistant conversations. Status has not seen very much growth/adoption, even when there are loud complaints from various crypto communities for alternatives to Discord and Slack. Although I feel like their team had great ideas and were super early innovators, things didn’t pan out because building, maintaining, and marketing a messaging app is very difficult.
Status’s messaging platform in their app did not require payment, but it seems like Zemo’s would if they were publishing shielded memos to the chain. It is hard for me, personally, to see people replacing Signal and other messengers with E2E messaging with Zemo when it will cost $. Even if the costs are fractions of a penny at first, shifts in ZEC price or explosions in adoption will make the messaging costs rise, especially with heavy use. You mention potentially moving to L2s, but in my opinion L2s are just getting their grounding in other ecosystems like Ethereum and it has taken years for building and adoption.

Thanks for sharing. Status is a great app. I’ve been a user for years.

You mentioned Status has not seen very much growth/adoption. It’s probably important to define what you mean by “very much”. I did some digging into Status’s quarterly reports, and Status seems to be showing impressive growth by my standards. In their Q1 2021 report, they’ve stated they grew by 830,000 users across 190 markets.

It is hard for me, personally, to see people replacing Signal and other messengers with E2E messaging with Zemo when it will cost $

I agree. Free messaging will always win out for casual conversations. With that said, I don’t feel we’re competing on the same use case. Zemo introduces new use cases due the nature of having payments built into each message. Think of Zemo more as a way to monetize your attention vs conducting casual conversations.

For good reason, you or I wouldn’t freely share our private Signal handles or email address on social media. It would result in an enormous amount of people filling our unpaid inboxes. Zemo encourages people to do just that. The whole idea is for people to share their z-addr publicly so that more people can write to them. It’s a paid inbox that people must pay to write to. Each inbound message comes with an incentive. I refer to it as a Web3 inbox.

You mention potentially moving to L2s, but in my opinion L2s are just getting their grounding in other ecosystems like Ethereum and it has taken years for building and adoption.

It’s been exciting to see the recent developments in L2 tech. I estimate that Zemo would need somewhere around ~1M daily active users in order to fill all of L1’s capacity as it exists today. Realistically, that’s not going to happen anytime soon.

You mentioned in the grant you plan to coordinate with other wallet devs and the ECC. Have you connected with anyone from either of those groups yet and what was their feedback? This will be helpful because you also mentioned in the grant that you want your code to be open sourced and for others to build on it.

There have been some very casual Twitter conversations floating out there, but nothing concrete yet. We have this work scheduled for our 1st milestone.

The biggest rough edge to smooth over here is how we’re currently using the ‘reply-to’ approach used across wallet apps, which is not a viable solution. We plan to coordinate on how to improve Zcash memos for messaging and develop a more practical standard each wallet provider can inherit.

ZecWallet is a barebone, minimalist Zcash app for sending payments. How do you plan on repurposing the app? Specifically, would you be making upstream changes to ZecWallet, would users need to download both a ZecWallet App and a Zemo app, and would there be an import function for keys from the ZecWallet app to import to the Zemo app?

Zemo will be coded from the ground up. We plan to use ZecWallet mostly as a reference. In the end, there will be more differences than similarities, and therefore it makes more sense to start from a fresh codebase. With that said, we do expect we can cherry pick a lot of good code from ZecWallet to streamline our process. There’s no need to reinvent everything.

Users won’t need ZecWallet installed in order to use Zemo. Zemo is a full standalone app.

Yes, we’re planning that a seed from other wallets can be imported into Zemo. Zemo underneath the messaging-like UI is still a full wallet app, but with a different presentation layer.

For example, importing a seed with multiple z-addresses into Zemo would break each address into a unique user profile in Zemo. Toggleing through z-addresses on Zemo would switch between different user profiles.

Has your team deployed mobile apps? If yes, please list them.

Yes, many. I’ll reach out and provide a list.

As the potential launch will be in 2nd half of the year, do you plan to support Unified Addresses by default?

I’ve put a lot of consideration into UAs and I’m currently unsure if they’ll be great for messaging purposes. For the record, I could be wrong on this topic. The information regarding UAs is still relatively sparse so I may be misunderstanding how they work.

For messaging purposes, a single Z-addr can be used indefinitely and we can ensure a memo can always be delivered to a Z-addr. However, due to the nature of UAs being associated with T-addr, I’m worried they may need to be recycled after every use and there are cases where memos can’t hop between the T to Z transaction. Again, I may be misunderstanding the nature of UAs here, so please anyone feel free to chime in and correct me if I’m wrong.

Conversation apps are complex and we would like more details of implementation beyond a few paragraphs of intro.

Happy to explain more. I think i’ll try to break this out into a separate response. Or if anyone from the committee has specific questions, feel free to add them below.

Modifying the existing ZecWallet codebase to Messaging first is manageable, what often gets overlooked is the cost of ongoing maintenance. Who is going to keep up to date with the fixes for the underlying codebase? What would those costs look like after the 6 months funding period?

We’re looking to work with a blockchain platform that is committed to investing in messaging as part of their core utility. I’m open to discussion on how best to explore funding option beyond the initial proposal.

For example, Zemo could turn into a non-profit approach that is fully funded by the ecosystem.

Or we can attempt to turn it into a business to attract VC money. I’m personally more interested in the former approach, but open to ideas if anyone has any.

ZecWallet’s future is uncertain as @adityapk00 has taken a step back, how do you plan on maintaining a fork a customized codebase that is partly diverged from the upstream lightwalletd backend service? Who will be responsible to maintain the app in the App Store/Play Store?

Whatever happens to ZecWallet shouldn’t change the course of how Zemo works in any way. We’re fully capable of managing our own codebase. We would however be reliant on lightwalletd.

You mention in the grant “Shielded messaging has risen to become a popular use case in the Zcash community.” What information are you using to back up this statement?

Anecdotally many users in the community have used Zcash for shielded memos / love notes / etc. No real way to bring metrics into how many people are doing it right now, but people have expressed a lot of excitement in exploring this use case more.

I personally share my Z-addr from time to time on Twitter and I get flooded with messages from the community. It’s really a special experience. I’ve also onboarded 100+ people in this way through a simple message and a few cents in Zcash. The reaction is usually positive.

How would you be licensing your software and how does your license interact (if at all) with ZecWallet’s?

MIT license across the board.

What is the rationale for using IPFS for the avatars? Pinning in IPFS is still dependent on a server deciding to pin the avatar and if you plan on holding that data forever it is no better than an AWS server for for the sole purpose of storing pictures. Many NFTs on Ethereum use IPFS for their images and now no longer have access to the images for the NFTs because the startup who made the NFT decided to stop pinning the image.

Fair points. However, IPFS is better than a cloud storage provider in this case because it does at least give the option for additional gateways. It could potentially be a good idea to have the grant committee or ZF to also run a gateway to ensure there is longevity in the avatars.

How many team members will be working on Zemo? The budget seems high for a 2 person team based on some previous grants that have been administered.

We’re a 2 member team.

Can you please reference the previous grants you are referring to? Specifically mobile app grants? I poked around the grants platform earlier and it appears our hourly rate was significantly less than other mobile app grants.

Chris is a blockchain wizard. He’s built backed services for Bitcoin, Bitcoin cash, Filecoin, dabbled in Avalanche, Ethereum and other platforms. He wrote the server component for the decentralized ecommerce network called OpenBazaar, which also was ported to a mobile app and was called Haven. He was lead dev for https://bchd.cash/ and created the Bitcoin cash mobile app https://neutrino.cash/. Even if Zemo doesn’t play out, we would be very lucky to onboard him as a dev into the Zcash community.

I’m a former director of design on crypto applications. I’ve lead design on many mobile applications. I was an early employee at many top-tier venture backed startups, one which was acquired by a fortune 500 company. I started my career as a software engineer and continue to write front-end code mostly in react and react native.


Thank you for the detailed questions. Having more dialog like this with the committee would be super useful so that we can continue to properly explain our proposals.

6 Likes

To elaborate on some of the points in more detail, Hudson, I’d like to suggest we steer the focus away from trying to determine if Zemo could surpass Signal in usage at some point. In my opinion, this comparison is not the point of our application. We’re trying to grow shielded usage on Zcash with new use cases. We’re not trying to compete and/or surpass leading platforms right now. Our goals should be prioritized around Zcash usage and adoption.

If you don’t mind, I’d like to ask the committee a few questions —

  1. Do you feel Zemo could help grow the Zcash community?
  2. Does Zemo offer an attractive way to onboard new users into using Zcash?
  3. Does Zemo expand the utility of the ZEC asset in meaningful ways?
  4. What are the downside risks if Zemo doesn’t achieve meaningful growth?
  5. If Zemo becomes a leading tool in the Zcash ecosystem, will the committee stand by us and continue to fund development?
  6. Are there ways ZF, Zcash community grants, etc. can contribute to driving usage of Zemo? e.g. Messaging parties on Twitter Spaces, Ambassador program promotion, etc.

I wouldn’t want to build Zemo without the full support of the grant program. If we want Zemo to succeed, we’ll need more than money from the committee and community.

Thank you for your consideration.

5 Likes

Solid responses!! Kudos @Ziga. If I were on the committee I would approve this grant.

3 Likes

I honestly think & believe Zemo is going to bring best UX to Zcash ecosystem.

For the record, I’ll start using it & share with my friends to onboard them to Zcash.

3 Likes

Hi @Ziga, really good answers to the questions above from Hudson, i had similar concerns which you’ve addressed well.

I love the enthusiasm you bring and onboarding new devs to the ecosystem is something we need.

I’ve been reviewing the previous thread to re-familiarize myself with the discussions from back then and I have a couple of questions.

Collaboration:

@aiyadt mentioned reaching out to the Light Client Working Group, via Discord or the regular calls, have you had any interactions with this working group yet?

The Cost:

Originally the staff cost was $288,000 for 4 people for 6 months, or $12,000/person/month, or ~$75/person/hour (assuming 40 hour weeks for 24 weeks).

In this proposal the staff cost is $180,000 for 2 people for 6 months, or $15,000/person/month, or $93.75/person/hour (assuming 40 hour weeks for 24 weeks), which is a 25% increase.

My question, would you consider bringing this down to the original average rate of $75/hour, which would result in a total staff cost of $144,000 for 2 people for 6 months. I personally think that it would be worth taking a chance on at this rate*.

*Obviously I don’t make any decisions here, just voicing my opinion.

3 Likes

Great questions and I look forward to see the answers.

I think this conversation will help clarify ZCG’s position on what they’re willing to fund and why.

Best of luck with the proposal @Ziga.

4 Likes

Community can do market research on what the hourly pay looks for experienced & specialized devs. https://geomotiv.com/blog/software-engineer-hourly-rate-in-the-usa/

Also it’s a good opportunity for grant committee to hire someone or use market data to come up with comperitive hourly rate for working with Zcash for different roles (one that matter to us).

2 Likes

I love the enthusiasm you bring and onboarding new devs to the ecosystem is something we need.

Thank you!

I’ve been reviewing the previous thread to re-familiarize myself with the discussions from back then and I have a couple of questions.

Collaboration:

@aiyadt mentioned reaching out to the Light Client Working Group, via Discord or the regular calls, have you had any interactions with this working group yet?

We haven’t joined the conversations yet. If Zemo becomes an app the committee and community decided to support, then we’ll be excited to participate in the conversations.

The Cost:

Originally the staff cost was $288,000 for 4 people for 6 months, or $12,000/person/month, or ~$75/person/hour (assuming 40 hour weeks for 24 weeks).

In this proposal the staff cost is $180,000 for 2 people for 6 months, or $15,000/person/month, or $93.75/person/hour (assuming 40 hour weeks for 24 weeks), which is a 25% increase.

My question, would you consider bringing this down to the original average rate of $75/hour, which would result in a total staff cost of $144,000 for 2 people for 6 months. I personally think that it would be worth taking a chance on at this rate*.

Great question. The previous proposal was drafted for a 4 people team. Chris and I were both on the original team. Of the two other team members, one lived in a country with a significantly lower cost of living and the other was a designer with less experience with lower salary requirements.

The avg. hourly cost per person for the initial proposal was quoted at $75. Chris and I were going to be making higher than $75 per hour, while the other 2 were making roughly $50 an hour. Both proposals work out to about the same cost per hour for Chris and I.

4 Likes

My 2zats about why this project excites me.

Onboarding users! How much is a new user worth? Investing $100,000s with the hope of educating and introducing 100,000s of new users to Zcash sounds like a shoe in to me!

Let me explain. When I tell my IT friends about Zcash this is how the conversation goes…

– “hey you should install this crypto wallet and I’ll send you some tokens! It’s private blah blah…”
“Cool, I won’t do it now but Ill definitely look into it…”

Here’s how I hope Zemo will help onboard my IT friends…

– “Hey you should install this new messaging app. I was kinda annoyed that I have to allow signal to see my phone number so thought we should give this a go. Zemo works with public keys not phone numbers. I’ll send you some tokens…”
“Cool! I always like trying new messaging apps. Give me a sec to install it.”

But even better I can now onboard my family. I swear at least once a month they’ll have a mini freakout about some data leak reported on the news.

“did you hear about the recent XYZ big company data leak?”
– “oh yeah this is why I don’t use Facebook”
– "hey you should install this new secure messaging app. It doesn’t use your phone number/contacts like WhatsApp/Signal. Just send me your user ID key once you’ve installed it.
“Ok I’ll install it now”

So I’ve onboarded all these people. Then what? They inevitable stop using it? Nope! I introduce them to new usecases.

– “Thanks for lunch!” $10

If we all do this I can imagine this will help introduce 1000s of new people to Zcash every month. Over 12-18months that’s 100,000users!

Note: I have no evidence this will happen it’s just a dream. Can Zemo make this happen?

5 Likes

I love it @gguy. Thanks for sharing your ideas!

– “hey you should install this crypto wallet and I’ll send you some tokens! It’s private blah blah…”
“Cool, I won’t do it now but Ill definitely look into it…”

I’ve personally onboarded dozens of people (friends and family) to invest in Zcash. Whenever I tell them to install a wallet and try a real shielded payment, they’ve also put it off and mostly never come around to it.

There can be many new use cases that emerge from Zemo. And I think @gguy hit on some of them well.

One idea I like is… imagine a presenter at a conference puts their Z-addr on their final slide and tells the audience to private message him/her on Zemo about what they thought of the presentation. The ability to receive private messages from an audience, without having to expose your email address or signal handle to everyone, could be very useful.

Also, if we eventually have a Zcash podcast, the producers of the show could create a new user profile on Zemo for every episode released. The avatar would be a cover photo from the episode and the display name would be the episode number. Fans could privately send comments, thoughts, feedback to the podcast hosts for each specific episode.

I don’t know for sure what use case will be the most compelling for Zemo, but I think there’s enough creativity in our community to find a way to grow it. The best part is we’ll all be using shielded transactions more too.

5 Likes

Hi, Ziga and Grant Committee,

As you know, I am very supportive of the Zemo project, but I want to clarify why that is and what my specific interests are – what would make this proposal pop out to me.

I think it is critical to understand what the potential of messaging with cryptocurrency is, why it could be superior to something like Signal, and why Zcash. Strong cryptographic guarantees of privacy are essential in messaging, but beyond not requiring a phone number, the reason that this would be far better than current encypted messaging is because of micropayments. As alluded to above, having to pay for messages is a feature, not a bug. Historically, using micropayments to improve messaging was one of the original motivating factors for even inventing digital cash in the first place.

How do micropayments improve messaging? By solving the spam problem. What is most needed in imo is to define a simple protocol for message payments that disincentivizes spam. It could be as simple as by default not displaying messages that cost less than a threshold, and always sending back an Ack for the value of the threshold to approved parties.

So, for example, suppose you and I are connected[*]. I always send you a messages for 0.01 ZEC (a default below which you do not read memos), and because we know each other, you always automatically refund me. This serves as a receipt, gets me over your spam threshold, and reduces my cost to the transaction cost unless I am a spammer. If someone tries to send you spam over the threshold, it’s prohibitively costly because you don’t refund them. You won’t need to “block” a user. Set their payment threshold to infinite so the app never displays their messages, just keeps the cash.

[*] This immediately presents an authentication problem for Zcash, because there is no proof of sender. Therefore, I think the development needs to include designing some kind of signature / handshake to establish “connection” for the purposes of automatic refund, and this may need cryptography expertise to model.

I also think Zemo should be working with whatever the new standard protocol is that ECC is developing for a wallet, rather than on ZECwallet.

Basically, I think the priority of development should be in how the messages and payments are handled at the protocol level so that any app could be made to interact with Zemo. In other words, the app itself is just one implementation of the protocol to showcase how it can work. The protocol design development makes or breaks success of this use case for Zcash as much as the usability of the app, in my opinion. I used to think about micropayment messaging a lot in the days before Bitcoin, and I’m willing to advise on protocol design if you want.

So what I would like to see is something like the first milestone being an RFC on establishing trust and message ack / refunding, and then building the app to implement the protocol with a pretty UX. Then maybe there could be other more complex features later like automatically splitting long messages to fit into memos and re-merging them on receipt, or figuring out how to have multi-way conversations.

6 Likes

Messaging on special purpose social networks like LinkedIn, etc is not free. So I agree with Amber that paying to message is a feature (in defined contexts).

Given user needs ZEC to use Zemo, Zemo network could be Zodler network.

6 Likes

Great thoughts, Amber! Thank you for chiming in.

As alluded to above, having to pay for messages is a feature, not a bug.

How do micropayments improve messaging? By solving the spam problem. What is most needed in imo is to define a simple protocol for message payments that disincentivizes spam. It could be as simple as by default not displaying messages that cost less than a threshold, and always sending back an Ack for the value of the threshold to approved parties.

Another super interesting use case for Zemo. I love it.

Basically, I think the priority of development should be in how the messages and payments are handled at the protocol level so that any app could be made to interact with Zemo. In other words, the app itself is just one implementation of the protocol to showcase how it can work. The protocol design development makes or breaks success of this use case for Zcash as much as the usability of the app, in my opinion. I used to think about micropayment messaging a lot in the days before Bitcoin, and I’m willing to advise on protocol design if you want.

I’d like to echo this point, Zemo is intended to be the first application on the messaging protocol. We hope our app will inspire additional devs to fork Zemo and create different messaging apps, while ensuring there is interoperability across all of them.

A big selling point vs say Signal, is you can import your seed phrase into a forked version of Zemo, benefit from different UI features, all without being tied down to a single provider. This is the true beauty of Web3 messaging.

So what I would like to see is something like the first milestone being an RFC on establishing trust and message ack / refunding, and then building the app to implement the protocol with a pretty UX. Then maybe there could be other more complex features later like automatically splitting long messages to fit into memos and re-merging them on receipt, or figuring out how to have multi-way conversations.

I’m glad you brought more attention to the protocol design process. On our end, Chris has started working on handshake concepts. I’ve asked him to chime in here with more details when he has a chance.

What I think could potentially be helpful here, Amber, is if you feel comfortable, it may make sense to appoint you as the point person to lead the process of creating the RFC. There’s a good amount of work to write the specs, coordinate with stakeholders across different projects, etc.

I feel it would be best to open a separate grant proposal for this line of work. Regardless of if Zemo gets funded, the RFC would be a valuable contribution to the community. Is that a process you would be interested in leading via a separate grant?

7 Likes

Haha. I walked right into that one.

Possibly. Maybe I could chat with you and Chris about it offline.

4 Likes

@Ziga - Thank you for the detailed responses you provided to our questions and concerns. We appreciate the lively dialogue here from the community and are working on some responses for the questions you raised about our views of Zemo. We think it would be very beneficial to create a spec that addresses the protocol design which the community could use for interoperability between wallet implementations. We like ambimorph’s suggestions and are interested in seeing a proposal from ambimorph or inclusion of a spec initial milestone into the Zemo grant. More to come from us soon hopefully by mid-week. Thanks for your patience!

5 Likes

I feel like there would be some overlap (in terms of work) between Elemental Zcash and this project. One of my plans with Elemental Zcash is to modularise some of the ZECwallet React Native/Electron codebase to make it more portable for use in other apps.

Also, my hope with Elemental Zcash is that it would save developer time by reducing the amount of work needed to manage a React Native codebase, and an Electron codebase, by abstracting away styling/platform differences.

If you’d be interested in the idea of using Elemental Zcash (or say a few of the UI components or locales), I’d be happy to spend some time on helping with some integration or discussing possibilities.

I feel that for devs to fork a project, the project needs to be heavily modularised and be built up of open-source libraries that are decoupled from the original app. A naive fork will end up diverging from the original codebase relatively quickly and build up a high technical debt; there would need to be a good developer ecosystem for other developers to build apps on top of the messaging protocol.

Possibly. Maybe I could chat with you and Chris about it offline.

Yes, sounds good!

1 Like

Sounds great, thank you!

One of my plans with Elemental Zcash is to modularise some of the ZECwallet React Native/Electron codebase to make it more portable for use in other apps.

I just checked out your website and it looks like Elemental Zcash is still a ways out from being finished. I’d be happy to take a closer look once you have something more concrete.

Keep in mind that Zemo will require new UI patterns due to it being a messaging app.

I feel that for devs to fork a project, the project needs to be heavily modularised and be built up of open-source libraries that are decoupled from the original app. A naive fork will end up diverging from the original codebase relatively quickly and build up a high technical debt; there would need to be a good developer ecosystem for other developers to build apps on top of the messaging protocol.

I guess it would depend on what the devs are trying to accomplish. UI libraries are nice for speed, but can end up being too restrictive to fulfill unique use cases. If a library emerged that fulfilled our needs, we’d be happy to consider integrating it into Zemo.

3 Likes