On Connectors

Last Modified Avatar

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:
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

Wallets
Exchanges/Dex/Defi
Games/Gambling
Marketplaces
NFTs

W3 Business dApps

Multisigs
DAOs
DAO Tools
DAO financials
Managing tokens/investors

W3 Infrastructure

These solutions are best analyzed one by one.
Celer
TheGraph
ChainLink
Ceramic
XMTP
Superfluid
Filecoin


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)
eCommerce
Internet of Things
Social media
Advertisement
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
Messaging
Forms
Files
Tasks
CRM
Social
The - by far- most popular APIs in the top 20 are
Google
Microsoft
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



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
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

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.

IPFs

Filecoin

Can't find what you're looking for?

Contact Us
Refreshed On: Aug 15, 2022 19:32:06 UTC+00:00