Water Works | An "event chaining" pipeline to facilitate cross functionality of districts

[Bradymck]

Purpose:

To build links between district functions through an event based pipeline.

Description:

This would basically be an “event chaining” template market. An event chain template is an additional post/list function that allows one district to trigger any number of functions within another district, upon reaching a ‘network trigger’. A ‘network trigger’ is any of the following network functions: post is closed, post is completed, a post is listed, a vote is completed, etc.

Core functions of the “Water Works”:

• A district “Chain Profile” creation function that propagates across all districts participating in the Water Works market, to facilitate the cross district posting.
• Example: A “water works” employer profile is pushed to every other district so the chained payments can flow to it’s created tasks when a trigger is registered
• Chain template curation market
• Payment routing for job/task sponsorship
• Chain templates proposals need to be built to move past the chicken and egg problem.
• Sponsorship feature from Ethlance to build payment split “landing points” for the templates
• Template selection UI within participating districts to enable triggers and links to different district functions
• A kill switch and expiration date option to disable the events chains
• An Aragon vote or Carbovote proposal corresponding to a chained task posted to another district so community can accept job proposals on non sponsored listings.

Example of possible chain functionality:

In this example, the 1Hive campaign is set to release funds to the campaign owner as well as Water Works template tasks and jobs.

In the case of 1Hive as the root of the chain template, a campaign that reaches a funding milestone could have an automatic payment sent to a predefined sponsorship on Ethlance as well a set of bounties on Bountie.io or task post on influencer.io. When those tasks are marked complete, a milestone trigger could be sent to the 1Hive campaign to signal for a second phase in the funding structure or even signal to the campaign manager that they need to take an action of some sort.

Example of network logic:

If [1Hive milestone reached] then [Post Bounty.io listing] & [Post Influencer.io task] If [Bounty.io listing] & [Influencer.io task] then [release funds] as a sponsorship for the listings. If [Bounty.io listing] & [Influencer.io task] is [complete] trigger [milestone or notification or contract state change].

I would love the community's feedback. This was my first attempt at addressing district interoperability. I feel like Simon de la Rouviere did a nice job at summing up his colleague’s work with his ‘curation clubs’ post. I think it fits nicely in the 1Hive funding model as well as the Water Works template market. If a campaign pledged a small amount toward a curation club, the pooled funds could be utilized in any number of ways. Would love to hear everyone’s thoughts.

[AngeloAdam]

Awesome idea. This would be very useful. Would this be programmed through various API like ifttt?

[Bradymck]

@angeloadam I'm not sure honestly. That is about as far as my development skills go. I would imagine there are other ways to do it.

[Bradymck]

@AngeloAdam Pulling conversation with @madvas from Slack:

As for a technical side of things: Smart contracts can’t listen to any blockchain events.. Only off-chain listeners can listen to blockchain events.

But still, what you propose can be accomplished 2 ways:

1. Smart contract Action1 from dapp1, will be responsible for calling directly Action2 from dapp2 within Action1 function.

2. There will be off-chain server listening for particular actions on blockchain and creating reaction transactions accordingly. Paying gas from own pocket.

Both options have different pros cons. 1. can be cumbersome, gas heavy, not too scalable with many reactions. 2. is not entirely on blockchain, therefore not entirely trustless, tho might not be too important in this case

[lkngtn]

@mckmuze

I really like the idea of facilitating actions between districts, but I think I like the general idea of a marketplace for IFTTT style service providers even more. As @madvas pointed out, one of the ways to provide this service is to use an off-chain server that runs a node waits for specific "triggers" and then send another transaction. Triggers could be on-chain events or off-chain events, but in either case an offchain service could listen for an event, and respond in some way, including submitting an onchain transaction.

This could be useful as you suggest for inter-district communication, but would also generalize well for many other use cases where you need a listener, or a timer, or some computation. For example, one usecase might be a push-notification providers for Status.im -- something that they suggested in their whitepaper.

I could see the district being a set of services and each service having a number of service providers that have reviews/reputations and users could opt to use whichever service provider they want and easily switch between them.

On a side note, I think another way to look at this proposal is not as a market for IFTTT type services, but instead as a framework for how d0xInfra components should modularly interact. Which I think is also really important. As we build additional districts, the specific components should fit together a bit like lego pieces so that eventually when we get to the district-creator interface there is a library of components that can be mixed and matched to form novel interaction patterns.

[Bradymck]

Thanks for the feedback! I think you articulated my idea better and corrected my line of thinking all in one comment. lol

Thanks so much, this comment actually helped me while I was trying to do a mock up. Much easier to mock up a service provider market than a template market. Will do more work on this and do a follow up proposal change and mock up.

[puttersworth]

I really like this idea as district interoperability is going to be key to the growth of the D0X ecosystem. We are going to have to address this one way or another, so the sooner the better.

[quantumdwayne]

I think this is a fantastic idea and something I think needs to eventually be built into d0xINFRA. For example, let's say a buyer/seller agree on a transaction on Ethtrade. A signal from the transaction could be sent from Water Works to trigger an escrow/bond service from Escargot automatically without the users having to do anything. Since this feature would be so vital to both of those districts working properly (and any other districts where financial transactions are occuring) I would think this "event chaining" functionality needs to be a feature built into d0xINFRA. Otherwise the users would have to manually set this all up which can be a bit confusing and/or time consuming.

[Bradymck]

This needs to be rewritten to ensure it would function as a marketplace rather than an overall feature request for D0xinfra. Closing for now.