In order to better understand use cases, produce more targeted partnership proposals and prioritize development we should categorize connectors.


Nexus standardizes (and as a result requires) all external systems to communicate using the

 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.


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.


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.


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 

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.


 (user) would likely use a specific gmail account to do so.


 (user) would likely use the organization's SendGrid account.


 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 

 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:


These solutions are best analyzed one by one.


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,…)


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 

And the most popular categories are clearly


On Connectors

grindery

Business

Welcome

Courses

Miscellaneous

Funding and Grants

Grindery Planning Sessions: August 2022

Onboarding

gWork

Developers

Review

Partners

Active Topics

On Token Allocation

On Community 

On Organization

On Tokenomics

On Brand

On Roadmap 

On Validation

Grindery Nexus Feedback 2.0

Grindery Nexus Feedback

Demo Day Priority

Nexus Review 3

Co-creation Slide

Co-creation

Marketing

Funding/Investing - Inbound/Outbound

Funding/Investing

Knowledge Management_Operations

Grindery DAO Sales Process