originprotocol / origin-js Goto Github PK

Currently we have many different javascript formatting styles. To avoid chaos and arguments, we want to use a standard tool to automatically format our javascript source.

We've chosen the prettier tool.

We'll be using the NPM style (no unnecessary semicolons, 2 spaces)

• Add prettier to dependencies
• Put prettier config in platform package.jsons
• Add a npm command to format our documents
• Update contributing document
• Format our existing javascript

Anything I'm missing @wanderingstan?

Updates will need to be made on the docs repo, but want to track in this release.

https://github.com/OriginProtocol/docs

Changes reflected on docs.originprotocol.com

• Fix really outdated stuff
• Add instructions on workings on local docs
• Add basic Listing api use with examples
• Explain how photos work
• Schema details
• IPFS Service

Actual implementation of the smart contract vs. just architectural decisions (which is currently marked as done).

• Update docs.originprotocol.com with latest from docs repo
• Update docs repo README with info on how to refresh live

Mocks are still pending

Placeholder issue for now - will create new issue in other repo

Lots of tradeoffs to think through

• When we have new purchasing contract, we want to capture the state of the listing that I am buying (at that time)
• If the listing contract is immutable, then we just need to reference the contract
• If the listing contract can be updated, then we need to actually snapshot the contract at that time
• People will want to update listings - that’s definitely the way that users will want to interact
• New price, images, metadata
• Need to build pros and cons of both approaches

When a Purchase is in a BUYER_PENDING stage, after 21 days it automatically moves over.

We'll need to show where this countdown is in the UI when it is active, probably on the purchase detail page and My Listings page.

Do we want to show this only to the buyer and seller?

• Add a Purchase.get method to origin.js, which includes timeout
• Add UI element to purchase detail
• Add UI element to my listings

We currently have 2 npm packages in this repo: one for the contracts and one for origin.js. .

This caused my npm build in origin.js to fail, as I hadn't yet done an npm install for the contracts. I suspect this would be a nightmare for new developers, and seems to over complicate things.

@aiham , I recall you saying it was strange to have dependencies outside the directory of the package.json. What would you think would be a better layout?

Our original idea was to mimic the layout of RequestNetwork, who do indeed have two packages. They seem to solve it by having the .js package include the smartcontract package as a dependency. This could work, but feels strange to have the contracts as an npm package.

@DanielVF : any thoughts on this?
@Gzing : You were following requestNetwork; have you heard any discussion on their side about this?

Figure out what user registry looks like on the blockchain

We need a script track the gas cost of each individual origin.js action.

If we automatically extract this data from our tests, we won't have to do any work for it to stay up to date as the project grows.

Presumably using codeship, though of course we could have discussion around other options since we haven't started using it.

@Gzing - I've added you to our team on codeship, let me know if you need anything else on that front.

• Is it worth creating similar issues for website, demo-dapp?
• identity-playground does have tests defined. Shall we create an issue there as well?

With a mapping we can look up a user by indexing off their wallet address.

In current form, you'd have to walk the array to find a particular user.

@tyleryasaka : any reason why this would be a bad idea?

In some cases the seller may require additional deposit over the face value of the transaction. For example vrbo rental of a mansion.

We've updated the contracts so that you now call buyListing() on the Listing contract, and not on the ListingsRegistry contract.

We're still doing it the old way here:Current code for buying a listing: https://github.com/OriginProtocol/platform/blob/develop/packages/origin.js/src/contract-service.js#L109-L126

Should probably time out earlier than this and reject the promise.

Rinkeyby + Ropsten

Network utility to post/fetch from smart contract & IPFS

• Always add/verify signature
• Every IPFS blob must be signed with private ETH key
• Optionally, do this as an extension of web3

Note that this is not the general browse use case. This is referring to an active transaction between buyer and seller where both sides are required to take steps to complete the transaction.

https://zpl.io/bJNdWqr
https://zpl.io/blNoLpG
https://zpl.io/V0ZNwyO
https://zpl.io/bAGwWq8

EDIT: Finished! URL is: https://code.originprotocol.com/origin-js/origin-v0.5.10.js

Now that we have a plain javascript origin.js (not the npm version) we should make it available from our website, which ideally just points to a IPFS blob.

So a site should be able to do something like:

<script src="https://www.originprotocol.com/code/v0.0.2/origin.js"></script>

This could in turn be a redirect to an IPFS blob:
https://gateway.originprotocol.com/ipfs/QmU85WSZMtdMaf7kuyTZpztSKQuVdVY7cXpMCeKa3y1vW5
Such an approach has the advantage that clients don't have to trust our website not to change the code. The IPFS hash will only and always point to an exact version.

This also would make for a cool demo in that one could start using origin.js in the raw browser console, loading it with only this code:

document.head.innerHTML += '<script src="https://www.originprotocol.com/code/v0.0.2/origin.js"></script>';

Currently this code lives only in our releases here:
https://github.com/OriginProtocol/platform/releases

@joshfraser What do you think?

https://zpl.io/amBQ8YK

It would be a nice feature/video where there is a walk-through of basic installation and usage of origin.js.

Maybe building a series of videos where each major milestone is shared in a video for both beginners and others working on other parts of origin.js to get a full summary of what is new.

Currently each instance of Listing contains a complete set of code for listing methods. This means higher gas costs all around. The "correct" way to do this is to split the logic (ie all the methods) into a library contract, so that the actual Listing contact contains only data, and a new ListingLibrary contract contains the logic.

@DanielVF has started work on this direction in his handling of Purchase contracts, here:
c4afd42

Once this is done, we'll want to do the same thing for all our contracts.

Current thinking is a master listing registry, individual contracts for each listing, then child contracts for booking instances

Perform research on uPort, Civic, Keybase.

Come up with "glue" to support future identity integrations.

Needed for better support of

• Other wallet-browsers
• Alternate payment methods, e.g. myetherwallet
• Testing of js. See: #30

Let's estimate how much it costs each time someone launches a new listing or booking. We expect this to go down over time, but for now, it is a big user experience impediment.

The steps to get started with origin.js are currently long and tedious.

See: https://github.com/OriginProtocol/platform/tree/develop/packages/origin.js#local

We need a friendlier intro for new contributors, and a system that is less error-prone.

Ideas are:

• Drop truffle develop and use ganache-cli to run local blockchain. (Using build scripts by @nick as inspiration)
• Use env and/or command line args to switch between local chain and network chains. (E.g. Rinkeby, mainnet)
• bash script(s) for doing npm link work

Other ideas?

@joshfraser @DanielVF @tyleryasaka

https://zpl.io/anrw6Zr
https://zpl.io/aXW0KnX

Placeholder issue for now - will create new issue in other repo

https://zpl.io/VOB6kAL

Reach feature parity with previous implementation:

• listing.buy
• listing.getByIndex
• listing.create
• listing.getAllListingIds

Dependent on #35
The 0.2 release only has original demo-dapp contracts

Listings expire 60 days after creation.

We'll need to show on the listing details page and the my listings page how much time is remaining. This probably doesn't need to be very prominent unless we are in the last day.

• Add expiration information method to listings.get in origin.js
• Hide expired (and sold) listings from search results
• Add UI element to listing detail
• Add UI element to my purchases

High-priority, as other features in this sprint are gated on this being done

We need claim fields in the user schema to represent profile attributes.

• First name
• Last name
• Description
• Avatar

Our services should just return the class. Singleton can be done in origin.js.

This will enable better testing.

Hat tip: @aiham for suggestion.

Solidity has been updated and now events are required to be prefaced with emit keyword.

See: http://solidity.readthedocs.io/en/v0.4.21/contracts.html#events

See: ethereum/solidity#2877

• Purchase timeout from Buyer Pending to Seller Pending
• Listing timeout to closed

We need to figure out how to capture solidity events in our tests. In first case, we need to get the address of the created Purchase contract.

See notes and initial research links here:
https://github.com/OriginProtocol/platform/blob/develop/packages/contracts/test/TestListing.js#L45-L49

https://zpl.io/aBOX1DA