On Connectors
Last updated by Joe Hu 2 months ago
On Connectors
In order to better understand use cases, produce more targeted partnership proposals and prioritize development we should categorize connectors.
Our first obvious differentiation is web2 and web3 .
Nexus standardizes (and as a result requires) all external systems to communicate using the WebSockets protocol. WebSockets allow for a higher amount of efficiency compared to REST because they do not require the HTTP request/response overhead for each message sent and received. WebSockets keeps a single, persistent connection open while eliminating latency problems that arise with HTTP request/response-based methods. We want the workflow engine to work in real-time and as a result ongoing updates about the state of other systems - as enabled by WebSockets - is a good fit.
Connectors need to understand what to listen for and what information to relay in order to trigger a workflow in Nexus. This in turn means I need to be able to receive definitions of trigger criteria.
Types of Connectors
Web2 Connectors
To implement web2 connectors this usually requires an api-wrapper around existing APIs. For example <gSheet example here>.
Web2 connectors also usually require authentication. <how is authentication done today> <how will it be done later>
Web2 connectors then provide a CDS (an enhanced version of the standard ABI) that is stored <where>. <What the CDS does exactly>
Essentially there is an API Wrapper + a CDS per web2 system or app. While the API wrappers today introduce another centralized system and (potentially) single point of failure we believe that these systems can be increasingly run on decentralized infrastructure and further integrated into the actual web apps by the provider. Grindery will focus on allowing signaling redundancy and establish validation and reputations systems to build a reliable network.
Web3 Connectors
First of all web3 protocols do not have any authentication and as such do not require any authentications nor the related credential management. However, Nexus relies on Blockchain APIs to interact with the different chains. While this initially introduces - similar to the web2 connectors - a centralized system with single point of failure we already see this achilles heel of web3 being tackled by solutions link ANKR. And, similar to web2 connectors, Grindery will focus on allowing signaling redundancy and establish validation and reputation systems to build a reliable network.
Once a blockchain API has been connected any protocol or dApp can simply declare a CDS and by that allow the workflow engine to listen for events (triggers) and execute transactions (actions).
Since blockchain APIs usually support multiple blockchains and no API support all Grindery will rely on multiple blockchain connectors. This also facilitates the implementation of signal redundancy and reduces the risk of single point of failure.
Once a blockchain has been connected via an API all of the smart contracts on that blockchain can be added as a CDS and made available to the workflow engine.
Use cases
Grindery nexus can be useful in different way to different users:
When it comes to discovering and defining use cases we need to understand the true end user scenario as well as the app and dapps they use. The easiest way to start is to differentiate between B2B and B2C or business and consumer users, use cases and (d)apps.
A good example is to think about a case where you want to send an email notification as a result of something happening on a blockchain.
Then there are infrastructure triggers and actions. Infrastructure can be Celer, TheGraph, ChainLink, Ceramic and XMTP to name a few. Many of their triggers and action will only be useful for developers since they require technical understanding of technology and protocols. This does not mean that developer might not take advantage of the Nexus no-code UI but the use cases are much less frequent and wide in adaption. However, developer will be able to integrate infrastructure triggers and actions to improve their dApp user experience or allow their users to only specify the trigger or action freely. An example of this would be to use a few end users provided parameters to perform a subgraph query with TheGraph and send an email address of the user already stored in the dApp.
At way to analyze is to group create high level groups
Each of these groups can then be broken down further:
W3 Consumer dApps
W3 Business dApps
W3 Infrastructure
These solutions are best analyzed one by one.
And then there are web2 business , consumer and infrastructure apps.
Given the complexity we should simply ask what actions and triggers make sense for web3 Dapps and tools when it comes to the different categories as well as the most popular Zapier Apps .
And the most popular categories are clearly
The - by far- most popular APIs in the top 20 are
Sheet with analysis here
Focus
Consumer dApps
Allow wallets and Defi dApps to
trigger messages and store data in sheets. This can be done permissionless or pre-integrated or simplified and embedded in their UI. Build in Nexus dApp and then sell it to them to integrate when decentralized.
Business dApps
Allows DAO, Multsigs, DAOTools and DAO treasury tools to
Trigger messages, store data in sheets as well as business ops (HR/Fin/Acc/CRM) and create tasks in Task systems
The Graph
Extend Nexus to trigger workflows based on queries as well as to obtain data by queries to be added into another workflow.
Celer Network
ChainLink
Incorporate off-chain data like the weather or change of an exchange rate.
Ceramic
SelfId
XMTP
Superfluid
Use as trigger for messaging and storage just like a wallet. Start or receive a stream. Allow to start streams to from web2.
