Meeting - Pipeline, 19 Dec 2018, Ethereum Foundation office Berlin

--- tags: pipeline --- # Meeting - Pipeline, 19 Dec 2018, Ethereum Foundation office Berlin Participants: @loredanacirstea, @chriseth, @leonardoalt, @bit-shift Useful links: - https://github.com/pipeos-one - https://gitter.im/pipeos-one/pipeline - https://www.youtube.com/watch?v=sC7Hd6Sr1SI&list=PL323JufuD9JAyaYCEvrnQ5yOAc3ukuNyF ## Scope (from @loredanacirstea's perspective): - Share some of the plans that we have in mind for Pipeline - Get feedback on what plans could be more useful for the Ethereum ecosystem, in order to prioritize them - Maybe get a new perspective that we have not thought about ## Summary - short explanation about the idea around Pipeline, with some usecase examples - demoed some of the core Pipeline features - talked about some future Pipeline plans - received feedback & some ideas regarding the presentation ## Pipeline Idea Summary - users can create an autonomous Dapp + smart contract with Pipeline, that can act on his behalf when triggered by blockchain events or various sensors (e.g. mobile GPS location), and do on chain transactions or call REST APIs - sample usecases: - bridge between projects: batch & connect transactions; e.g. make a decision based on a registry (TCR etc.) -> swap some tokens (DEX) -> use the tokens to vote in a governance project. (either fully on chain, or transactions triggered by events handled by the Pipeline agent) - based on mobile GPS sensors -> send transactions to some blockchain based services that are enabled by location - user wants to set up a Pipeline agent that will trigger off-chain payments with Raiden at a specific point in time (pay bills, pay other people); Some notes: - we are using a GABI (generalized ABI; for lack of a better name), that extends the ABI schema, for all graph components (even for REST APIs or JS components) - current flow: GABI -> graph JSON -> Solidity (+ JS) output ## Pipeline Demo Showed some of the core Pipeline features: - mainly how to use functions from already deployed contracts from different services, connect outputs->inputs, in order to build a wrapper Pipeline contract that batches the transactions - database of contracts with tags Some demo hiccups around Pipeline contracts compilation & search based on tags that I need to now address. ## @loredanacirstea - Planned Features for Pipeline 1. integration with swarm/ipfs & ethpm - the contracts database that Pipeline has now should be decentralized and at the moment either swarm (supported by Remix) or ipfs (supported by ethpm) are valid options; swarm is preferred - because we use https://github.com/strongloop/loopback-next on the backend, we are thinking of building a swarm datasource connector; this would also make a swarm-enterprise apps bridge - we need very good tags for contracts & contract functions (we have ~300 hierarchically structured tags, but the tagging work is not yet done); we would like to make the tags & the semantic links available as a swarm file (probably YAML format); we think this would be very useful also for ethpm users & devs 2. support for REST APIs - drag & drop APIs (OpenApi standard https://www.openapis.org/) from projects that you want to integrate in your Pipeline agent, to be used in the Dapp component (JS/Python) - unlocks integration of off-chain projects (e.g. Raiden, generalized state channels, other normal web services, controlling IoT devices) 3. YUL support 4. database of specialized UI components for ABIs - targeted to special input/output types; because we also have a metadebugger (function level debugger) - e.g. geopoint type inputs, with user input validation - what I did not say: we are using Vuetify for a form generator, that can receive a JSON schema; we can save these schemas on swarm -> anyone can use them with Vuetify. 5. Pipeline tutorials for welcoming beginners into the ecosystem 6. Support a `map` function (looping over arrays of elements) - a first stab at a visual functional language. Some things I was wondering about: - contract verification service - will ethpm also provide the certainty that the uploaded packages have consistent data? E.g. source code matches compiled data, which is matched by the bytecode at the deployed addresses? - maybe Remix can have a server API that allows other parties to use a specific compiler version in order to verify contracts, or provide this service itself ## Feedback Christian R: - current UI maybe hard for beginners (agree, beginners need a nice and straight forward UI) - instead of deploying a smart contract per graph, maybe have a general smart contract that knows how to ingest the graph JSON and make the transactions. - would like a visual language for Solidity built on state machines with guarded transitions. (this indeed is way lower level for what Pipeline is intended to do, but we are at least thinking about code patterns as components)