Thanks to @jaxcoder for the feedback on this idea.
Tldr
This document proposes building pubsub (publish subscribe) into Allo protocol V2 in Q1/Q2 2024.
Pub/Sub is short for Publish/Subscribe. PubSub is a standard way of thinking about data models on the web, having been used for many open source projects as a design pattern pattern.
Pub/Sub in the context of Allo protocol means being able to publish Allo grants to other registries. And subscribe from other registries.
Pub/Sub would be of great strategic importance to Gitcoin. Implementing Pub/Sub in H1 2024 would enhance Gitcoin’s network effects greatly by allowing Allo Protocol to be used on every Grant Platform in the ecosystem. It would also make Gitcoin’s Builder tool into a very valuable tool for every Grant hunter in the ecosystem. and could work to further solidify Allo as THE library for capital allocation in web3.
Essential intent
Problem
1. Lack of Adoption of Allo Registry
Right now, there are several prominent Grants standards created by Gitcoin (5% market share by 2023 ETH public goods funding GMV) Optimism (90% market share) Giveth (2%) CLRFund (1%), Hypercerts (1%) and more (1%).
Allo v1 tried to standardize them on Allo, but that didn’t work.
It’s almost like there is a pattern to how standards proliferate.
2. Cold start problem
Network effects of these tools are reflexible. The more people use the Allo registry, the more people use the Allo registry, the more people use the Allo registry, and so on…
Tools that are trying to boostrap network effects have what we call the cold start problem.
If we were still the top market leader in EVM based grants, we could bootstrap it with our dominance. But after the rise of Protocol Guild + Optimism Retro PGF, we are not the dominant market leader anymore.
We need to solve this cold start problem.
Solution
Owocki/Jaxcoder propose the following solution: Pub/Sub For Allo v2.
High level this would be two things
- Publish: The ability to publish your Gitcoin Grant to any major registry.
- Subscribe: the ability to subscribe to any grants registry and import it into Allo.
Subscribe
We could effectively solve Gitcoin’s cold start problem by importing other registries into Allo v2.
Once this has hit scale, there is much more value in building things on top of Allo v2 (reputation, impact attestations, etc…) because all grants in the ecosystem are on the same registry.
Publish
In college applications in the United States, students can fill out a “common app”. One college application that allows them to apply to hundreds of schools.
This is a killer app for college applicants who want to make multiple bets + have their time respected while doing so.
We should build a “common app for web3 grants” that allows grant owners to build / manage their grant in one place, then publish it to other registries.
Conclusion
Implementing Pub/Sub into Allo protocol would enhance Gitcoin’s network effects greatly by allowing Allo Protocol to be used on every Grant Platform in the ecosystem. It would also make Gitcoin’s Builder tool into a must-use tool for every Grant hunter in the ecosystem. It would solidify Allo as THE library for capital allocation.
Appendix A - Implementation Details
Thanks @jaxcoder for authoring this part of the post.
Implementation
Subscribers typically receive only a subset of the total messages published. There are two common forms of filtering: topic-based and content-based. I think we could also add a third and possibly a fourth, or more, filter method.
We could start out with simple pub/sub options.
- Add a IRegistryWrapper interface - this will allow the user/developer to use the wrapper instead of the IRegistry (the wrapper will inherit this) which will contain the EAS functions.
- Add a RegistryManager contract - this will allow the user/developer to subscribe to any registry within the protocol and allo registries to publish ‘profiles’ and any other relevant information.
Current Problems:
- Cross-chain registry synchronization
- Wrapping each other registry “profile” into IRegistry for consumption
- How do we define the interface(s)?
- EAS uses a registry specifically for attestations, to me this means we will still need a layer on top of EAS to map the UID (this is returned when an attestation is made) to a profileId (this profileId can exist on any registry that the RegistryManager has subscribed to and may even be called something different).
- Registries leveraging other registry data.
Solution(s):
- Use a hybrid pub/sub system where the user’s profile publishes the attestations via the registry or registries they subscribe to using the registry manager.
- To allow for a mapping from a profileId to a UID we need a contract layer to handle this and the other features we want to build out for managing multiple registries in one place.
- The user can then start to include many features provided by other registries within Allo by using the IRegistryWrapper interface. This will include all functions previously offered by the Allo IRegistry interface plus additional plug-and-play features that a user can turn on and off. One of the key features will be the PubSub model of providing profile and registry data.
- A flag that can be used to include EAS by default.
- Diagram currently representing the idea of having a RegistryManager and IRegistryWrapper interface.