[Proposal] Design a JS SDK for Rarible protocol

TLDR: Design a JS SDK for Rarible protocol

This is a proposal to begin work on the architecture, design, and dev experience for a JS SDK of the entire Rarible Protocol Flow. This interface will be used by developers to quickly integrate the protocol into their apps, while abstracting most of the complex logic that can happen under the hood.

In one week we’ll throughly digest existing resources and documentation, work along side other ecosystem developers, prepare the interface for the protocol according to the feedback received, and specify all the endpoints that would be created on a subsequent engagement.

Problem / Opportunity

What problem or opportunity are you looking to solve?

The Rarible Protocol currently does not have an official SDK, so by having this dev tool ready it will be easier for dApp devs to interact with Rarible protocol.

dOrg DAO is specialized in building Web3 integrations and tooling, and various of our stake holders are interested in building on top of the Rarible. By creating this SDK, high-caliber projects will be able to tap into the protocol to develop their specific NFT usecases.

Funding Milestones and Payments

The following is an estimate based on the scope of work as currently understood and can change upon revision by mutual consent of the parties.

Estimated Timeframe: May 1 - May 7 (1 week)

Deliverables

  • May 7: Research & Interface Iterations (~50 hours)
    • Architecture: Initial interface for the protocol, covering the entire Rarible Protocol Flow.
    • Work with other ecosystem developers to best polish the end-user’s experience
    • Describe the development roadmap for a subsequent engagement to develop the SDK.

Payments

The team will allocate funding amongst its members retroactively in proportion to contributions made. Funds will be stored in a Gnosis multi-sig controlled by the team, which is to be funded by the Rarible treasury on the following dates:

  • May 1st - $3,000 (or equivalent in $RARI)
  • May 7th - $3,000 (or equivalent in $RARI)

dOrg LLC will be a service provider of the Rarible DAO and will report taxes accordingly. Legally compliant invoices will be issued accordingly before funds get distributed to our team.

  • Registered Legal Entity: dOrg LLC
  • Registered Address: 76 St. Paul St, PO Box 369, Burlington, VT 05402
  • Tax ID: 84-2930500

Use of funds

Funds will be used to pay experienced developers and builders from dOrg DAO (https://dorg.tech). RARI token will be used to pay builders directly involved with the project, and 10% of the total amount will be airdropped to dOrg DAO Reputation Holders.

Business Model

  • Ease of adoption: Create a user-friendly developer experience.
  • Opensource Bootstrapping: Build together, with composability in mind.
  • Massive adoption of NFTs: Epic Win.

Team Members

dOrg is a Web3 Developer DAO that has worked with top projects like Balancer, The Graph, Aragon, Badger, Gnosis, ParaSwap, and more.

The project will initially be executed by the following dOrg members. However, dOrg is designed to flexibly bring on the right expertise at the right time, so other developers will likely get involved over time.

  • Roberto Henríquez (Media#2944) - PM
  • Carlos Febres (carlosfebres#8099) - Full Stack
  • Ben Walker (benefacto19#4368) - Web3 Integrations

Accountability & Quality Assurance

dOrg utilizes the following processes to keep all parties accountable in the course of execution:

  • Project Manager is responsible for keeping the project on track and should be interfaced through for any issues regarding scope, roadmap, risk, payments, etc.
  • Weekly Syncs to share updates, discuss blockers, and realign priorities.
  • Discord Channel for ongoing updates and support
  • Github Project Board for continuous deliverable tracking
  • Feedback Threads to asynchronously collect community feedback as we build

In order to ensure that all deliverables satisfy project requirements without issue, dOrg:

  • Carefully assigns proven builders with the relevant expertise
  • Utilizes modern testing frameworks and testnet lifecycle simulation
  • Performs internal code reviews before handoff and other key milestones

Despite these efforts, dOrg is not able guarantee that all code will be perfect. Web3 is still an emerging field with a high level of risk and complexity. dOrg is not responsible for any bugs or technical failures that may result from its services. The Client is responsible for consulting with the relevant security experts before taking high risk systems live.

Why should Rarible DAO fund this?

What is the benefit to RARI token holders? How will this help grow the ecosystem, or bring value to them?

We believe that, in Web3, improvements to the developer experience drive ecosystem growth. With more teams able to build fast and prototype on top of the protocol, we’ll be able to see even wider adoption and innovation.

We need an SDK; By abstracting the complex logic of the protocol (ExchangeV2, IPFS pinning, API calls, Test environments, etc) devs will be able build on top of a simple, intuitive interface.

We will support ecosystem cross-polination and distribute protocol stakeholdership to a group of awesome Web3 Specialists by airdropping 10% of the RARI token received to the 50+ members of the dOrg DAO.

Code Examples

Here’s a quick 45-minute sketch of what the interface could look like for minting. The idea is to work with other active devs from the ecosystem to continue iterating and correctly design the interface.

Instantiation of the SDK
// Instantiation
import { Rarible, SubgraphProvider, EthereumProvider, APIProvider } from "@rari/sdk-js";

// Manual configuration; could  be mainnet or rinkeby, for example.
const rari = new Rarible({
    subgraph: new SubgraphProvider({
      provider: "url to the hosted service"
      // In the future, this class can be upgraded to support queries on The Graph Network
    }),
    ethereum: new EthereumProvider({
      provider, // "rpc" | jsProvider /*window.ethereum*/
      signer?: // address | accIndex | Signer (priv key)
    }),
    api: new APIProvider({
      provider: "url to the hosted service"
    }),
  });

// Default mainnet provider config
export const mainnet = (ethProvider: ExternalProvider) => new Rari({
    subgraph: new SubgraphProvider({
      provider: "url to the hosted service"
    }),
    ethereum: new EthereumProvider({
      provider: ethProvider
    }),
    api: new APIProvider({
      provider: "url to the hosted service"
    }),
  })

// Setup the SDK with a provider
import { mainnet } from "@rari/sdk-js";
const rariOnMainnet = mainnet(window.ethereum)

Minting ERC-721 Example

//Pseudocode NFT Metadata object
type Metadata = {
  name: string;
  description: string;
  image: Blob;
  external: string;
  animation: Blob;
  attributes!: {
    key: string;
    trait_type: string;
    value: string;
  }[];
};

import { Metadata } from "@rari/sdk-js";
 
/* 
 * Minting steps:
 * 1. Parse the Metadata object and ensure it matches the expected format
 * 2. Upload JSON and media files to IPFS (using Piñata, Fleek, or native IPFS)
 * 3. Request tokenID from Rarible API
 * /
 
// LazyMinting Approach:

/* 
 * 4. Store the signatures in the API
 * 5. Retrieve the signatures to make the mintAndTranfer contract call
 */ 
const minted = await rariOnMainnet.mint(to, metadata: Metadata, creators, royalties, signatures)
// lazy=true by default

// DirectMinting Approach:
/* 
 * 4. Make the mintAndTranfer contract call
 */
const minted = await rariOnMainnet.mint(to, metadata: Metadata, creators, royalties, signatures, lazy=false)
// lazy=false will mint and transfer the NFT

Useful Links & Media

Change Log

All changes to the proposal will be tracked below.

Date Description
28-Apr-2021 Change of scope to a JS DSK interface, with a shorter duration. Posted proposal to Discourse
3 Likes

A JS SDK is definitely a must for Rarible Protocol!

5 Likes

Awesome! We’d like to take a moment to more clearly illustrate the deliverables for this proposal :slightly_smiling_face: I’ll share this below since the original message cannot be edited anymore.

Estimated Timeframe: 1 week

Deliverables

Research & Interface (~50 hours)

  • Architecture: Initial interface for the protocol, covering the entire Rarible Protocol Flow, which covers the following:

    1. Creating ERC721/1155 Asset Metadata and Calling the Mint function
    2. Asset Discovery
    3. Creating a sell order
    4. Accepting a buyer/bid order
    5. Order Discovery
    6. Matching Order
    7. Updating/Canceling an order
    8. API Reference
  • Work with other ecosystem developers to best polish the end-user’s experience

  • Describe the development roadmap for a subsequent engagement to develop the SDK.

We can think of this interface as the set of specifications that describe the inputs, outputs, and behaviors of all the functional elements of the Protocol Flow. Therefore, the engagement involves architecture, conceptualization, and analysis so that the protocol can be abstracted into something robust that you can easily interact with.

For illustration purposes, if we were to design an interface for a microwave, we’d deliver the specification of each of the “buttons” to set cooking time, start, stop, set mode(heat, defrost), etc. Consequently, the details of how the microwave increases the temperature of your food, turns on the lightbulb when you start it, or rotates the microwave dish would not be part of the interface itself, and they’d be developed on future engagements considering the proposed roadmap.

Once the SDK fully built, its implementation will look like the two code snippets we’ve posted above on this thread.

The snippet code below is an accurate representation of what a part of the deliverable interface would look like.

type Metadata = {
  name: string;
  description: string;
  image: Blob;
  external: string;
  animation: Blob;
  attributes: {
    key: string;
    trait_type: string;
    value: string;
  }[];
};

type Address = string;

type AccountPercentage = {
  account: Address;
  value: number;
};

interface RaribleSDK {
  constructor(config: {
    ethereum: EthereumProvider;
    api: APIProvider;
    subgraph: SubgraphProvider;
  }): void;

  mint(
    to: Address,
    metadata: Metadata,
    creators: AccountPercentage[],
    royalties: AccountPercentage,
    signatures: string[]
  ): LazyMintResult;

  mint(
    to: Address,
    metadata: Metadata,
    creators: AccountPercentage[],
    royalties: AccountPercentage,
    signatures: string[],
    lazy: false
  ): MintResult;
}

Finally, for comparison of what to expect as a tangible interface deliverable for this first phase, here is OpenSea’s SDK Interface.

2 Likes

As an update for payment terms,

Regarding the suggestion of having a single payment in full after the deliverables are turned in (instead of half up-front and half upon completion) we’d like to propose using an Escrow service on an L2, like RaidGuild’s new SmartInvoice. This example would allow payment after-the-fact, and we can also specify a preferred arbitrator.

1 Like

Below are some updates on this proposal:

  1. Initially, the proposal was asking for 1.2K equivalent in RARI upon delivery, and 4.8K in xDAI upon delivery via escrow
  2. Because the proposal to convert RARI to xDAI failed (see https://snapshot.org/#/rarible/proposal/QmbdBw2xFcK4q1oQ5TeXumznhQXba1s8xcBPANjgGgfexm ), we can’t pay the 4.8K in xDAI
  3. The agreement I have come to terms with with @DaoAdvocate is to do the following: 100% of the funds will be paid upon delivery via an “escrow multisig” : basically a multisig with 5 signers that requires 3 signatures to distribute funds. Signers will include myself, Alex, Roberty, Isaac and Carlos.

The multisig address is here: https://gnosis-safe.io/app/#/safes/0xe63e4811e509B6CF5cbba26b010fD04B872781B6/balances