Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 29 14:27

    github-actions[bot] on gh-pages

    deploy: 0c2958c7e1196d3bba1790f… (compare)

  • Jun 29 14:12
    folex closed #1284
  • Jun 29 14:11

    folex on aws_ci

    (compare)

  • Jun 29 14:11

    folex on master

    Move from CircleCI to AWS (#128… (compare)

  • Jun 29 11:18
    folex synchronize #1284
  • Jun 29 11:18

    folex on aws_ci

    remove circleci config (compare)

  • Jun 29 11:13
    folex synchronize #1284
  • Jun 29 11:13

    folex on aws_ci

    back to serious: no azaza (compare)

  • Jun 29 11:12
    folex ready_for_review #1284
  • Jun 29 11:12
    folex edited #1284
  • Jun 29 11:11
    folex review_requested #1284
  • Jun 29 11:11
    folex review_requested #1284
  • Jun 29 10:58
    folex synchronize #1284
  • Jun 29 10:58

    folex on aws_ci

    :facepalm: trigger container pu… (compare)

  • Jun 29 10:47
    folex synchronize #1284
  • Jun 29 10:47

    folex on aws_ci

    remove container_version (compare)

  • Jun 29 10:40
    folex synchronize #1284
  • Jun 29 10:40

    folex on aws_ci

    my next PhD: getting an element… (compare)

  • Jun 29 10:30
    folex synchronize #1284
  • Jun 29 10:30

    folex on aws_ci

    try to upload fluence binary (compare)

Olivier Sarrouy
@osarrouy
So basically we would need Fluence to listen for events on the Ethereum blockchain, then rebuild the IPLD data tree and index it to make it easily searchable and traversable.
Exactly
Dmitry Kurinskiy
@alari
yeah, that's the use case we're digging in right now: listening for Ethereum events and updating Fluence index based on them
Olivier Sarrouy
@osarrouy
That would be really cool for us. Because basically that would allow people to deploy their own repository smart contract without being indexed - if they don't want to. And to opt-in to our network to gain indexability.
Would there be any constraints or requirements about the IPLD data structure ?
(if there is so, would like to conform our data structures ASAP to avoid refactoring all the code once we integrate with Fluence :)
Dmitry Kurinskiy
@alari
let us study it a little? we'll discuss the use case internally and ping you back on the beginning of next week, wdyt?
Olivier Sarrouy
@osarrouy
That would be perfect.
Dmitry Kurinskiy
@alari
great :)
Olivier Sarrouy
@osarrouy
We're still at the early stage of the development so there's also some space on our side to adapt to Fluence requirements.
Also; here is our deck: http://slides.com/osarrouy/deck-3#/
Dmitry Kurinskiy
@alari
thanks!
Olivier Sarrouy
@osarrouy
We still have a few thing to finish but it can give you a good idea of what we're trying to build :)
Dmitry Kurinskiy
@alari

Hey @osarrouy
So, for Pando Protocol case.

The main idea that Fluence is going to update index from Ethereum (not only, but it's an important feature we're working on), and then you can implement logic to organize your data with any Webassembly-supported language. Then do whatever you want with it :)

The workflow with Fluence might be the following:

  • As I understand, on the first step a contract is created on Ethereum blockchain, and some files are added to IPFS. Once files are added, there's a commit transaction to that Ethereum contract
  • We're planning to listen for Ethereum events, fetch a part of Ethereum state on event, and build a verifiable write transaction to Fluence based on it
  • That transaction will come to Webassembly code you write, launched with Fluence, having access to persistent mutable state. On this step, you may organize links between data and get ready to output ipld
  • A client will be able to read data from Webassembly via some API
  • We are not planning to implement external writes, so Fluence is not going to be able to modify ipld data. But you may implement some service that, for example, launches a periodical query to Fluence and updates ipld accordingly. Or you may query Fluence directly from client's browser

So there's no special constrainst on ipld structure :)

Olivier Sarrouy
@osarrouy
Hey @alari . That's really cool. Just two questions: 1. to make it clear, it's gonna be possible to fetch the whole IPLD tree with the webassembly code to index it just with the hash of the root of the tree ? 2. When will it be possible to start writing the working on that feature and play with Fluence :D
Really exciting to start working with fluence anyhow :)
And also: thanks a lot for the update.
Dmitry Kurinskiy
@alari
@osarrouy , for point 1: probably yes. depends on the size of the tree, and on ipld hashing logic -- you'll need to implement the same hashing to get addresses from the webassembly; and for 2: I hope, we will have something to play with in September or October -- yet you'll need to launch your own Fluence nodes to do it
Florian Lenz
@florianlenz
Hi. Which query language will you support?
I read the last comments in the channel, will fluence "only" support building indices or will it take care of data storage and replication as well?
Dmitry Kurinskiy
@alari
Hi @florianlenz ! For the query language: it depends on your actual needs. Fluence is a bottom layer for launching data-local computations, and you may express them the way you like with use of Webassembly. We're preparing a demo with a subset of SQL
About "only" building indices. Fluence builds, store, and replicate data in a small cluster
Florian Lenz
@florianlenz
Cool. What is the definition of a small cluster?
Dmitry Kurinskiy
@alari
It's a subset of Fluence network, approx. 4-25 nodes that replicate the data and operate with it in near real-time
Florian Lenz
@florianlenz
It's possible to build indices across cluster, right? What is the status of the project? I think fluence is the solution for a lot of problems we are facing in our applications. IPFS and there DHT is too low level. Will there be a technical specification?
Dmitry Kurinskiy
@alari
We are working on a new tech paper now, should be available this fall. Indices are to be built in each cluster, meaning that index is an efficient persistent data structure, optimized for particular access patterns
If you could describe us the problems you think Fluence is a good fit for, it would be very helpful :)
About status of the project, it's under active research and development, first demos should arrive soon, and we're aiming to release an alpha in Q1 2019 or maybe earlier
Florian Lenz
@florianlenz
Nice! Can't wait to read it. I can imagine when e.g. building a DEX this would be quite useful to build up a searchable orderbook. Were you can e.g. query for Where can select all offers with less than 3234 coins and were one coin costs less than 10ct (just an example).
What happens if the index gets too huge?
So that the nodes can't store them anymore.
Dmitry Kurinskiy
@alari
We are considering some kind of sharding but yet haven't found a way to guarantee performance in this case. So the memory limit is going to have a hard upper bound for now. The app developer should find a way to split the index into several parts according to application logic
Olivier Sarrouy
@osarrouy
Hey @alari Do you know if there’s anyone of your team at ethberlin ? That could be really cool to talk forward about the integration of fluence into ryhope / pando :h
Dmitry Kurinskiy
@alari
Hey @osarrouy ! I'm so sorry I've missed the notification :( we all were on ethberlin
Dmitry Kurinskiy
@alari
BTW, our team is on Web3Summit today, and we're going to DevCon next week!
jfrag
@jfrag
hi
anybody here ?
Anna Lekanova
@lekanova
@jfrag hi! yes :) we're (Fluence Labs) planning to switch to discord very soon. I will post the link to it here.
folex
@folex
Fluence Discord is live and running! You can join it by the link https://discord.gg/mt86peA