On Connectors

Last updated by Joe Hu 5 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: 
end users to easily configure their own integration without code 
developer to create integration (plug-ins, boosts) as self standing dApps 
dApp owners to launch and operate integration marketplaces 
dApp owners integrating grindery into their dApps for core functionality 
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. 
A  consumer  (user) would likely use a specific gmail account to do so. 
A  business  (user) would likely use the organization's SendGrid account. 
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 
W3 Consumer  
W3 Business  
W3 Infrastructure  
Each of these groups can then be broken down further: 

W3  Consumer dApps 


W3  Business dApps 

DAO Tools 
DAO financials 
Managing tokens/investors  

W3  Infrastructure  

These solutions are best analyzed one by one. 
And then there are web2  business ,  consumer  and  infrastructure  apps. 
End user messaging (email, browser, sms, …) 
Mass messaging (email, browser, sms, …) 
CRM, Marketing and campaigns (Hubspot, etc) 
Dataware Warehouse and general analytics (gCloud, etc) 
Integration Middleware (Zapier, Workato, ..) 
Generic data store (gSheetsm airtable…) 
HR, Accounting and finance (xero, quickbook,…) 
Projects and tasks and time 
Calendering and scheduling 
Document storage  
Developer tools and IT ops 
HR, Payment and Contractors 
Payment (Paypal, etc) 
Internet of Things 
Social media 
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 
Also Zapier has create several of the top 20 apps : 
Email by Zapier 
Webhook by Zapier 
SMS by Zapier 
RSS by Zapier 
Storage by Zapier 
Sheet with analysis here  


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 
Receive data from sheets/forms as well business ops (HR/Fin/Acc/CRM) 

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 



Incorporate off-chain data like the weather or change of an exchange rate. 






Use as trigger for messaging and storage just like a wallet. Start or receive a stream. Allow to start streams to from web2. 




Refreshed On: Dec 04, 2022 14:06:08 UTC+00:00