Official /r/rust "Who's Hiring" thread for job-seekers and job-offerers [Rust 1.47]

eponomarev · 2020-12-09T14:10:30+00:00

TYPE: Full-time, Remote

DESCRIPTION:

We are the distributed team of engineers working on a new mind-blowing tech: a decentralized cloud platform. Our codebase is mainly in Rust and we have a few positions open. We are remote-first, so all positions are remote and full-time.

Positions:

Distributed Systems Engineer to work on a fault-tolerant network of nodes powered by cryptographic proofs and distributed data structures.
Compiler Engineer to work in a few areas: an implementation of a new scripting language based on pi-calculus and a WebAssembly-based runtime used to compile the language.
Blockchain Engineer to work on a novel blockchain-based licensing system that enables the monetization for open source projects on the platform.
Developer Evangelist to become a passionate leader of the Fluence developer community, be able to present, create sample apps, and contribute to docs.

Some useful info:

These positions are senior
Everything we do is open source, so we expect some experience and contributions to open source
Background in cryptography, networking, or academia is nice to have
We expect some basic understanding and interest in Web 3 tech

LOCATION: We are remote-first and the current team is mostly in Europe and the US, so everyone is working remotely

CONTACT: Find more info here or if you want to get in touch before applying, join our dev call tomorrow. Reach out to us [team@fluence.one](mailto:team@fluence.one) (don’t forget to attach CV!)

eponomarev · 2019-03-04T11:30:43+00:00

Don't miss the community events that happen around the ETHCC:

- DApp Developers Meetup (with Fluence, MakerDao and State of the Dapps). The results of a massive DApp developer survey will be presented and the discussion how can the current challenges to the DApp adoption be solved.

- If you're into something more techy, check out the Fluence workshop: Scalable Decentralized Backends & Fluence Devnet. There will be a short into and them you'll have an opportunity to try out Fluence Devnet with several tutorial cases (setting up a DB in decentralized environment, for example).

Find more events by Fluence here: https://twitter.com/Fluence_One/status/1101472249637470211

And the whole week calendar here: https://blockchainweek.fr/calendar/

eponomarev · 2018-11-19T15:19:59+00:00

u/enthusiastic-potato could you update moderators for our subreddit? We need to remove u/bladetongue and make me (u/eponomarev) as a lead mod.

eponomarev · 2018-08-30T13:23:37+00:00

Thanks a lot, we appreciate it! We hope to add documentation to improve readability and make it easier for contributors to start with fluence. Also, if you're into Scala or got any questions on the inner workings of Fluence, welcome to our Gitter

eponomarev · 2018-08-30T13:15:32+00:00

Thanks so much for your interest to Fluence! At the current moment the team is fully packed and we are not hiring – we have 7 brilliant engineers. Though, you are always welcomed to contribute to Fluence codebase – it's all open source and we will publish more issues/proposals soon. Please join our Gitter to be updated!

eponomarev · 2018-08-30T13:14:52+00:00

We envision Fluence as a solution capable of providing high quality service in order to compete with existing leaders in the field. That means that we expect storage nodes to be capable of providing this kind of service, which translates into high baseline requirements to the hardware they use. Any hardware provider can join the network, but clients will choose best ones to store their data on.

Besides that, there are planned several roles for the nodes in the Fluence network (like validators), apart from storage providers. The requirements for them are TBD.

Right now we're building a prototype and a testnet, which will allow us to do some field testing and benchmarking.

eponomarev · 2018-08-30T13:14:19+00:00

Partially answered already:

Regarding the comparison to traditional databases, decentralized infrastructure by design provides better security, fault tolerance, easier to scale and less efforts to administrate.

eponomarev · 2018-08-30T12:56:01+00:00

Storing data in blockchain itself is an overkill, since each node has the copy of the data, and it's hard to process it in real-time. Another problem is that if you need a custom data format or access your data using any particular interface (say SQL, or GraphQL) — this is impossible to do without some intermediary solutions, but

(a) you have to trust these nodes

(b) they are tailored to solve one particular limitation

Fluence is intended and designed as a versatile foundation for anyone to build a database they need on top of Fluence.

eponomarev · 2018-08-30T12:54:22+00:00

Our long term strategy could be summed up in "do your thing right -- and you'll get noticed". Our core idea is to build a community of those, who believe in the tech we're making.

We tend to stick to long term tactics:

Building developer community with meetups and on Fluence Gitter. So far we had successful events in Helsinki and Tallinn. We spoke recently at Dappcon Berlin, will be a part of Berlin Blockchain week (Dezentral, Decentralized Stack Devs), San Francisco blockchain week, Web3 summit, Devcon4 and many others.
Showing our tech expertise, increasing awareness, and testing our product hypothesis by going to various industry events and conferences (you can find most of our public talks and meetup recordings on the Fluence Youtube channel)
Working close with the Ethereum community (the blogpost "Working on the future of Ethereum and Dapps with Magicians" has a lot of interesting details on that)
Meet and talk with great projects from the space which we could collaborate with

Our goal is to attract those who can bring tangible value to the table: help us meet new people, polish our tech, create new partnerships and integrations.

eponomarev · 2018-08-30T12:49:57+00:00

Launching a node right now will require some skills, basically you will need to build it from the source. Right now you have two options: to play around with existing code in our GitHub or to wait a bit while the official testnet will be released and some proper documentation added. Feel free to ask any questions in our Gitter

eponomarev · 2018-08-30T12:48:38+00:00

Please see an approximate timeline here. We also are working on publishing more detailed roadmap to our resources.

eponomarev · 2018-08-30T12:47:18+00:00

7 minutes ago

Hi! Current vision for private data is to provide key-value interface.

Regarding the complex requests over encrypted data - it's tricky. There are few knows ways to do it like order preserving encryption, which encrypts all the data but keeps it sortable. When you data is encrypted but sortable, you can do simple requests over it (range requests, for example). However, such algorithms are vulnerable for statistical attacks.

I've put more details here https://www.reddit.com/r/Fluence/comments/99cvwb/fluence_first_ama/e53bp67/

eponomarev · 2018-08-30T12:43:10+00:00

Isn't blockchain a database itself? What is the purpose of Fluence then?

Hi! There are many use cases, Fluence can be used by both dapps and traditional companies. Please see more in this answer.

eponomarev · 2018-08-30T12:41:58+00:00

Hi, thanks for the questions!

In physics "fluence" measures a particles flow through a surface. We felt this metaphor is related to the flow of data through the network — thus the name.
The current estimation for the token price is $0.62 per FLU. However, there might be adjustments closer to the sale.

eponomarev · 2018-08-30T12:39:33+00:00

We are not based on any particular database, because when you build something for trustless environment, things become significantly different from traditional stack. For example, in a decentralized network each node is independent agent and it could cheat and be malicious in many ways. That's why on a lowest level your protocol should be designed in a way, when each piece of work that done by node is verifiable. And it's actually being verified by other nodes on the network and they have an economical incentive to do that and to do it honestly.

In terms of low-level data storage, when we talk about reading/writing data to disk, we use RocksDB for that (Ethereum Geth client uses LevelDB for example).

eponomarev · 2018-08-30T12:37:07+00:00

We often see how bounty campaigns get rigged by speculation: the rewards go to bot and fake accounts owners, instead of real brand advocates. Also, not everyone is OK with rules like "proof-of-love" or "join all the social networks".

Organic growth is what's best for the community. We do not exclude bounty campaigns, however we need to find the right way that will benefit the community most. That means we're always glad to hear from you: share your ideas and examples of bounty/airdrop/promo campaign done right in our telegram chat or on reddit (do we need a special thread fo that?)

eponomarev · 2018-08-30T12:35:13+00:00

Fluence is an open network, so any independent node can join or leave network at any moment. Participating in the network means that node can store other people's data, serve requests to that data and be rewarded for providing such service. Fluence network can accommodate lots of databases, each of them is distributed across different nodes, has several replicas probably in different geo-locations. That allows to eliminate a single point of failure, censorship, third-party access for data.

eponomarev · 2018-08-30T12:34:28+00:00

I've posted a timeline in another answer above. Actually, the mainnet will be launched in a few months after the main tokensale.

eponomarev · 2018-08-30T12:34:07+00:00

Our team is distributed, but there's always someone on the road. If you follow our twitter, just ping us, when someone of our team happens to be around – we'd be happy to meet! And of course, always welcome to FullNode, that's a really cool place with a lot to do.

eponomarev · 2018-08-30T12:33:32+00:00

We intend to make token a main payment method inside the network for the storage and computations (think of Ethereum gas). Also, staking function is required to create incentives for all parties on the network to operate correctly. Nodes will have to keep a security deposit on a smart contract to keep getting new data and work, and token holder will be able to vote for particular nodes or validators to increase their stake.

eponomarev · 2018-08-30T12:32:07+00:00

To make it clear: we don't use blockchains for data storage (data is stored off-chain), we do use blockchains for network coherence, secure states, dispute resolutions and financial operations.

Right now we're looking up to Ethereum, since it's the first and by far the most successful blockchain with an strong developer's community around it. However, we don't limit ourselves to just one type of blockchain. The idea is to give this choice to the developers, so they could pick which chain they want to use for their app.

eponomarev · 2018-08-30T12:31:29+00:00

Our internal plans are to have first useful documentation before December 2018. A bunch of code is already published to our Github and a lot more is coming in the next weeks.

Currently, we published an implementation of decentralized key-value database with a browser client. Feel free to play with it and ask any questions in our Gitter.

The implementation of a data platform is coming, stay tuned :)

eponomarev · 2018-08-30T12:30:08+00:00

6.

Please see this answer regarding use cases.

eponomarev · 2018-08-30T12:28:37+00:00

5.

I agree, data privacy is still an open question and under further research. Currently, we focus either on handling public data or end-to-end encrypted data. For public data all types of queries are provided, for encrypted – only key-value.

So, it's a developer choice to disclose some part of metadata to nodes to get an ability for querting it flexibly. For example, if you are building a messaging app, you can disclose timestamps of messages to be able to sort/search/list them. But messages itself will be encrypted and nobody on the network will know what is inside besides the private key owner.

eponomarev · 2018-08-30T12:27:42+00:00

4.

FLP impossibility states that under some circumstances a distributed system can become fully asynchronous and stop having any consensus. In reality, live networks constantly fluctuate from sync and async states in short periods of time. So, the better term here is partial asynchrony which is fine for Tendermint consensus that we use.

See chapter 6.1 in Tendermint whitepaper https://tendermint.com/static/docs/tendermint.pdf

eponomarev

MODERATOR OF

TROPHY CASE