mikhaildobs

BringID – Technical Description

Initially, BringID started with zkTLS verifications and added Semaphore on top to achieve maximum onchain privacy. More details can be found in our whitepaper: https://github.com/BringID/whitepaper/blob/main/whitepaper.md

In the current version, we have added OAuth-based verifications as an alternative to zkTLS. OAuth is limited to the data that platforms explicitly share, but it does not require end-users to download any additional software.

---

Verification Flow

mikhaildobs

zkBring Indexer API

Get Drop

GET /drops/{drop_address}

Params

• drop_address: drop's contract address

Optional Query Parameter:

• fetch_as: user address fetching the data

mikhaildobs

I contributed to the Semaphore Trusted Setup Multi-Party Ceremony.
The following are my contribution signatures:
Circuit: semaphore16 
          Contributor # 231
          Hash: 9dca9935 613d832c 14f9f17f b7f5dac8
 84fdf16b a6df033a 63bd0842 8a5a0f14
 9fc5fc99 bf197eb9 4d6fc77b f443dfa6
 387afb77 4963f84c 6ec49f8e 20c26e44

mikhaildobs

{
  "JSON_RPC_URL": "https://mainnet.infura.io",
  "API_HOST": "http://localhost:5000",
  "CHAIN_ID": 1,
  "CHAIN": "mainnet",
  "SENDER_PRIVATE_KEY": "",
  "NATIVE_TOKENS_AMOUNT": "123456780",
  "TOKEN_ADDRESS": "0xa3b5fdeb5dbc592ffc5e222223376464b9c56fb8",
  "NFT_ADDRESS": "0x5f37ef03130f92925ea56579b891261118773aea",
  "TOKEN_IDS": "[1,5,7]",

mikhaildobs

// to phone number  
linkdrop.send({
  to:'+14158609050', 
  amount: '25',
  token: 'DAI',
  from: 'PoolTogether', 
  message: 'Hey, PoolTogether sent you 25 DAI 🤑'
})

mikhaildobs

Linkdrop V2 Spec

To unify all linkdrop types (campaigns, p2p, modules, on-ramps) we need common interface.
This will allow to utilize the same claim code (claim web apps, API, SDK, URI) for all kinds of the linkdrops,
reducing the need to repeat ourselves again and again.

The idea is to allow different ways to generate linkdrops (dashboard, sdk, wallets), but interoperable way to claim all kind of linkdrops.

Linkdrop Escrow Contract Interface:

mikhaildobs

Ens Login iFrame draft proposal

Abstract

• User enters his ENS (e.g. user.my-wallet.eth)
• Dapp queries the Ethereum blockchain with an ENS to get the provider source URL/IPFS hash and loads the wallet provider in a sandboxed iframe.
• Dapp interacts with the wallet provider via PostMessage interface - https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
• Messages between dapp and wallet provider should comply with EIP-1474 - https://eips.ethereum.org/EIPS/eip-1474

Iframe benefits

• Better security: wallet provider code is loaded in a sandbox environment, can't read dapp's localstorage/cookies and can't track dapp location
• Formalized specs: a wallet provider needs to provide a js code that can respond to the eip-1474 messages

mikhaildobs

This post links my 3Box profile to my Github account! Web3 social profiles by 3Box.
    
  ✅ did:muport:QmPuajdHfqJogCcyFbh64qk4jfoG6SvB8EcrweYG4WuWFt ✅
    
    Create your profile today to start building social connection and trust online at https://3Box.io/

mikhaildobs

  /**
    * @dev Internal function to deploy a proxy contract for linkdrop master
    * @param _linkdropMaster Address of linkdrop master
    * @return Proxy contract address
    */
    function _deployProxy(address payable _linkdropMaster)
    internal
    returns (address payable)
    {
        require(!isDeployed(_linkdropMaster), "Deployed");

mikhaildobs

Keybase proof

I hereby claim:

• I am dobrokhvalov on github.
• I am dobrokhvalov (https://keybase.io/dobrokhvalov) on keybase.
• I have a public key ASDbE6ghjqoeenuBYcVS_YN-mH-KYzYxHIpI5y5qLNLOago

To claim this, I am signing this object: