district0x / d0x-infra Goto Github PK

View Code? Open in Web Editor NEW

39.0 39.0 4.0 24 KB

Tutorials and explanations of d0x-INFRA

d0x-infra's People

Contributors

Stargazers

Watchers

Forkers

ul jpmonettas alvarlaigna yudevan

d0x-infra's Issues

Create cljs-ipfs-api library

Create wrapper library for easier working with js-ipfs-api, similar to cljs-web3.
Let's call it cljs-ipfs-api.

This lib should mainly do:

Split library into namespaces: For example ipfs.files.add function, will be in the lib as cljs-ipfs.files/add
Do clj->js on arguments passed into a functions
Do js->clj on objects returned from functions callbacks. Same as cljs-web3 does it.

In order to this lib to work, you'll likely need to create cljsjs/js-ipfs library. Alternative option would be to try to use new :npm-deps. It would be better, because of dead code elimination, but not sure if it's gonna work. You can give it a try.

Library should be usable in both, nodejs and browser.

As for documentation, you don't need to document every single function, since it's just a wrapper, just write something similar to cljs-web3 readme.

As for tests, no need to test every single function, just a few random, so we know cljs<->js conversions work.

Create re-frame IPFS effects library

After #2 is done, create re-frame effects for working with js-ipfs-api, similar to re-frame-web3-fx.
Let's call it re-frame-ipfs-fx.

We'll need effects only for files part of the library.

For example effect for ipfs.files.add might look like:

(reg-event-fx
    ::my-event
    (fn []
      {:ipfs.files/add {:files files
                        :options options
                        :on-success [::on-success]
                        :on-error [::on-error]}}))

This lib should be fully documented in repo's README.
This lib should be fully tested, with tests runnable with travis.

Create wrapper for 0xConnect library

Create wrapper library for easier working with 0xConnect, similar to cljs-web3.
Let's call it cljs-0x-connect.

This lib should mainly do:

Split library into namespaces: cljs-0x-connect.http-client and cljs-0x-connect.ws-orderbook
Do clj->js + camelCase on arguments passed into a functions. Same way as cljs-web3.
Do js->clj + kebab-case on responses returned from functions. Same way as cljs-web3. Note, function should still return native JS promise as it originally is, just value passed to that promise should be converted.
Contain convenience fns: cljs-0x-connect.http-client/create-http-client and cljs-0x-connect.ws-orderbook/create-ws-orderbook-channel which are equivalents to new HttpClient and new WebSocketOrderbookChannel.

For invoking functions js-invoke should be used instead of using JS interop, so we avoid eternal problems with externs.

In order to this lib to work, you'll likely need to create cljsjs/0x-connect library. Alternative option would be to try to use new :npm-deps. It would be better, because of dead code elimination, but not sure if it's gonna work. You can give it a try.

Library should be usable in both, nodejs and browser.

As for documentation, you don't need to document every single function, since it's just a wrapper, just write something similar to cljs-web3 readme.

As for tests, no need to test every single function, just a few random, so we know cljs<->js conversions work. You'll need to somehow mock responses from server. If you want to try out this lib on live server, try RadarRelay, their API should be compliant with 0xConnect.

Create cljs wrapper for OrbitDB

Create CLJS wrapper (cljs-orbit-db) for https://github.com/orbitdb/orbit-db
API is here https://github.com/orbitdb/orbit-db/blob/master/API.md
Probably you'll need to create cljsjs of the library first.
Primarily we wanna use https://github.com/orbitdb/orbit-db-eventstore but looks like all db types are included in the main library, so we can make API for all, at least it'll allow us to try different approaches quickly.
We wanna be able to pass and retrieve cljs data structures without having to do clj->js js->clj, including data from callbacks, when using this library. It's possible that there will be some problems with this, depending how it stores js objects in ipfs files, you'll see. Orbitdb uses primarily promises, the wrapper don't need to change that, since we can use https://clojurescript.org/guides/promise-interop#using-promises-with-core-async.

Also we'll need to use https://github.com/orbitdb/orbit-db-access-controllers, which exists as a separate library, but maybe we can include it in our wrapper if it's possible. Just the tricky part there is that it uses javascript class extending, which seems to be bit tricky to do in cljs (https://stackoverflow.com/questions/61040644/clojurscript-extend-a-javascript-class). Maybe there's some other way, I just searched briefly. Ideally we wanna give it clojure idiomatic API, just a function call(s).

Library can have similar structure as our web3 lib. No macros, unless necessary. Also include simple tests in the repo.

Update Parity on the server before the fork

2.2.5+

Create form components lib

Create library for most common form components called district-ui-component-form, where each component will have namespace such as:
district.ui.component.form.input
district.ui.component.form.select
...

Blend in code we already have at:
https://github.com/district0x/district-ui-component-input

Create input component

Make https://github.com/district0x/name-bazaar/blob/master/src/district0x/ui/components/input.cljs into district.ui.component.input and district.ui.component.token-input (both can be in same repo).

Updating d0x libraries to shadow-cljs and/or Web3.js 1.7(cljs-web3-next)

Indirect dependents

district0x/district-ui-component-active-account
district0x/district-ui-web3-account-balances (madis)
district0x/district-ui-component-active-account-balance (madis)
district0x/district-ui-component-tx-button (madis)
district0x/district-ui-web3-tx-log-core (madis)
district0x/district-ui-web3-tx-log (madis)

district0x/cljs-ipfs-http-client (madis)
district0x/re-frame-ipfs-fx (madis)

UI module for mounting root component

So all this tiny module would do is what we usually copy-paste into every app:

(defn mount-root []
  (clear-subscription-cache!)
  (r/render [main-panel] (.getElementById js/document "app")))

Let's call this district-ui-reagent-render.
So you'll need to create re-frame effect reg-fx for r/render side effect.
In module configuration we'll pass ID of the DOM element (usually "app") and component function that should be rendered (usually main-panel).
This module should also provide function rerender in its main ns that can be actually passed into figwheel config for remounting.

:figwheel {:on-jsload "district.ui.reagent-render/rerender"}

Possible trouble:
So render should happen at mount start, but at the same time it should happen after all modules have run their dispatch-sync. So this module in its dispatch-sync should probably just do :dispatch to some event that does r/render. This should ensure render is run after all modules are set up. Not 100% sure this will actually work as expected, you should try it out somehow.

Not sure if tests for this module can be done in any simple way. If you know some simple way that'd be great. If it's too complicated don't bother.

Research web3.js vs ethers.js

Consider pros and cons of 2 Ethereum libraries:
https://github.com/ethers-io/ethers.js
https://github.com/ethereum/web3.js

Present points to all other devs and we'll make decision which one to use for https://github.com/district0x/cljs-web3

Create add-to-calendar component

Make your add-to-calendar from NameBazaar into district.ui.component.add-to-calendar.

https://github.com/district0x/name-bazaar/blob/master/src/district0x/ui/components/add_to_calendar.cljs

Create re-frame effects for 0xConnect library

After #5 is done, create re-frame effects for working with 0xConnect, using previously created wrapper cljs-0x-connect similar to re-frame-web3-fx.
Let's call it re-frame-0x-connect-fx.

Library effects should have following pattern:

(reg-event-fx
    ::my-event
    (fn []
      {:0x-connect [{:http-client http-client
                     :fn :get-fees
                     :args [{:exchange-token-address "0x123"}]
                     :on-success [::on-success]
                     :on-error [::on-error]}
                    {:ws-orderbook-channel ws-chan
                     :fn :subscribe
                     :args [{:base-token-address "0x123"}]
                     :on-close [::on-close]
                     :on-error [::on-error]
                     :on-snapshot [::on-snapshot]
                     :on-update [::on-update]}
                    {:ws-orderbook-channel ws-chan
                     :fn :close}]}))

This lib should be fully documented in repo's README.
This lib should be fully tested, with tests runnable with travis.

Create lein-plugin for solidity compilation

I don't know how complicated or possible is this to make, since I never created lein plugin, but I hope it is not that complex.

So we don't have to copy-paste compile-solidity.sh file to every project, would be nice if we had lein plugin where we can define files for compilation.

Plugin can rely on solc being installed on local machine.

In project.clj we would define:

path for solidity source code folder
path for build folder
files to compile
Whether to ignore warnings in compilation output (see solc-err-only)

So following commands:
lein solc auto - would be autocompiling on changes
lein solc once - would compile once

Create district-ui-web3-sync-now module

After implementing district0x/district-ui-now#1, create simple module district-ui-web3-sync-now module, that fetches current time from blockchain after event :district.ui.web3.events/web3-created and sets it as now to district-ui-now module.

To get current time use this:
This is node.js snippet, you should use it in form of re-frame effects of course

(district-web3-utils/web3-time->date-time (:timestamp (web3-eth/get-block @web3 (web3-eth/block-number @web3))))

It's not ideal, since it's last block's time, not current time, but I think it will serve the purpose. I don't know of other way to get current time except having contract that returns Solidity's now.

This module should also provide event ::inc-now, that increments both: ganache's time using web3-evm/increment-time and :district-ui-now/inc-now for convenient incrementing via REPL during runtime.

No config options need to be passed into this module.

Create notification UI module & component

Create 2 repositories for notification functionality:
(notification is previously known as "snackbar" in namebazaar's code)

district-ui-notification with main ns `district.ui.notification`:

This would be standard mount + re-frame district-ui-module, that contains core logic for a notifications. Similar case where functionality is split between 2 repos for logic and UI component can be seen at district-ui-web3-tx-log-core and district-ui-web3-tx-log, although notification will be bit simpler. Splitting is useful, because UI components are usually much more opinionated than core logic, therefore logic can be reused many times for different notification components.

As for mount module configuration options, only 1 option comes to my mind atm:

:default-show-duration Default duration in ms for a notification to be shown.

district.ui.notification.events should contain event (besides others) ::show to show notification.
Should be able to pass it map of any keys to be stored in a state, so UI component can make use of other props such as :action-href in case of NB. To ::show you should also be able to pass duration, that overrides default duration. When passed just string into ::show, should be considered as sugar for {:message "abc"}.

Advanced feature request: It would be great if notifications were queued instead of overridden. Normally if notifications come too closely after each other, the first one would be overridden by second one, which gives user no time to read it. Notifications should be internally queued, and when new notif comes too soon, it'll wait until old one is supposed to close.
For this, I'd add new configuration option to mount module like :min-delay-between-notifications, where we can define min. delay between when old notif closes and new one opens, so there is some time for UI show/hide animations.

district-ui-component-notification with ns `district.ui.component.notification`

Should contain reagent component for notification. For now, you can use the one from namebazaar. Should not contain styling.

To create these module & component please follow pattern you see across all district-ui-modules & district-ui-components. Right now we have no tutorials, but I'm sure you'll be able to pick up pattern just by inspecting existing modules, since it's not too complicated. Repositories should contain documentation in readme as well as tests runnable by travis. district-ui-component-notification actually doesn't need tests, we don't do tests for reagent components at the moment.

meta-tags ui component

Create simple repo for district.ui.component.meta-tags, which is using same underlying cljsjs lib as NameBazaar.

API should be like:

[meta-tags {:title "Page Title" :description "Page Desc"}]

These props will add [:title {:id "title"} title] and [:meta {:id "description" :name "description" :content description}]

Optionally you can pass children for more meta tags

[meta-tags {:title "Page Title" :description "Page Desc"}
  [:meta {:id "some-other-meta" :name "some-other-meta" :content blah}]]

Create tx-button component

Make https://github.com/district0x/name-bazaar/blob/master/src/district0x/ui/components/transaction_button.cljs into district.ui.component.tx-button.
Instead of :district0x/can-make-transaction? use :district-ui-web3-accounts/active-account.

Streamtide

Streamtide is a Web3 based Crowdfunding and Grants app utilizing Quadratic funding to support artists globally. Initial version of the Streamtide offers following features:

Users can sign up, fill out profile, link social media and web3 address with their Streamtide account.
Users can link photos and videos of their work on their profile page, where each one can be marked to be shown only after a donation.
Users are able to specify one arbitrary url (Perks Button URL), which will be shown only after a donation.
Users are able to Apply for a Grant, where, if approved by an admin, they can start receiving donations from other users and matched donations from Matching Rounds.
Users can send donations to each other in ETH or DAI.
Admin approves or denies grant applications from users.
Admin can blacklist malicious user profiles, preventing them from receiving donations and hiding them from the UI.
Admin is able to push announcements, primarily informing users about upcoming Matching Rounds.
During a Matching Round, all donations from users are matched according to Quadratic Funding formula, from the Grant Pool.

Architecture

Streamtide smart-contracts are fork of clr.fund. The stripped down version of the smart-contracts includes Matching Round Factory contract, which creates Matching Round contract for each round. Contracts allow users to contribute funds to other users. Each contribution is egligible for further matching from Streamtide Grants Pool. At the end of each Matching Round, the admin initiates transaction to match all users' donations from the round according to Quadratic funding formula. Production version runs on EVM-compatible L2 solution, such as xDai, to optimise gas costs.

Pages

Landing Page

Contains static text and youtube video iframe.
At the top of the page, current admin announcement is shown.
Go To App button takes to the Grants page.
Email subscription button integrates with 3rd party email service, such as Sendgrid
Page is accessible to everyone, including logged out users

Grants Page

Shows all users who were approved after applying for the grant and are not blacklisted.
Allows searching by user names.
Allows sorting by:
- Newcomers - newly registered users first (default option)
- Early Adopters - First registered users first
- Recently Updated - Updated profiles first
It features infinite scroll to scroll down users
Page is accessible to everyone, including logged out users

Leaderboard Page

Shows list of users sorted accoding to their received funds.
Allows searching by user names.
Allows sorting by:
- Total Received - Users with the largest amount received from donations and matching rounds combined, first. (default option)
- Largest Matching - Users with the largest amount received from matching rounds, first.
- Largest Donations - Users with the largest amount received from donations, first.
Table columns:
- User Names
- Registered - Date when user was registered
- Donations Received - Amount user has received from other users
- Matching Received - Amount user has received from matching rounds
- Total Received - Donations Received and Matching Received combined together.
Page is accessible to everyone, including logged out users.

Profile Page

Shows user's profile data
Page is accessible to everyone, including logged out users.
If logged in users click Donate button, it takes them to the Cart Page, with selected user added for a donation.
If logged out users click Donate button, it takes them to the Edit Profile page to fill out the their profile first.
Users who already donated any amount to the user are shown Perks button, which redirects to a URL defined by user at Perks Button URL.
Content which is marked as For Supporters Only is shown only to users who donated any amount to this user.
Content which is marked as Pinned, is shown at the top of content section.
Biography section is rendering markdown text.
It features infinite scroll to scroll down user's content.

Edit Profile Page

Allows users to manage their profile information.
It features following inputs:
- Banner Image - 1500x500px
- Profile Image - 400x400px
- Name - Basic user name
- Handle - Users will be accessible by this, e.g http://streamtide.io/someuser
- Tagline - Arbitrary text limited to 100 characters.
- URL - Arbitrary URL limited to 100 characters.
- Biography - Arbitrary markdown text limited to 5000 characters.
- Social Links - By clicking Verify button, user should get 3rd party popup window for connecting social media account. Once connected, it starts showing URL to user's social account. Remove button removes this connection. Following social links should be implemented for the initial version of Streamtide: Facebook, Twitter, Instagram, Pinterest.
- Apply for Grant button - After user applies for grant, the admin will approve or deny his profile. Once approved, the user will be able to receive donations indefinitely.
- Add Content - Users can link their work in form of image URL or youtube video URL. Each URL can be marked as For Supporters Only, where it's shown only after donation. Pinned content is shown at the top. Initial version of Streamtide will not store content onsite, content is referenced from other sites.

Cart Page

Allows users to send donations to multiple users.
User selects amount and currency to send for each user in the cart.
Clicking checkout button will initiate a blockchain transaction.

Admin Page - Grant Approval Feed

Shows list of users, who applied for grant and still haven't been approved or denied.
Page is accessible only by admin's web3 address.
It features infinite scroll to scroll down.

Admin Page - Blacklisting

Shows searchable list of all users with option to blacklist them.
Blacklisted user is never displayed anywhere in UI except the blacklisting page.
Admin can search either by name or web3 address.
Page is accessible only by admin's web3 address.
It features infinite scroll to scroll down.

Admin Page - Announcements

Allows admin to publish an annoncement. The announcement is shown at the top of each page.
It allows markdown as an input for the announcement.
It shows list of all previous announcements.
Page is accessible only by admin's web3 address.
It features infinite scroll to scroll down.

Create lein plugin for releasing

on every PR merged to master the plugin should bump the version and release to Clojars

Update README.md regarding makefile use

The development environment within ethlance (newlance branch) and a few of the recently updated district components make use of a Makefile to combine common commandline operations for development.

The documentation should reflect this addition, along with providing certain conventions to follow when creating new districts.