Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    yiannakpavy
    @yiannakpavy
    @mirceanis Sorry to bother, but I had a few follow-up questions. When you say a transaction is required to update the identity, is this analogous to updating the DID doc of the identity with attestations/attributes? Does uPort still support updating a uPort-specific decentralized registry (e.g., via the Registry Contract) that maps a uPortID to off-chain, disclosed data (e.g., via IPFS)? I'm trying to better understand the use cases supported here, e.g., on- vs. off-chain transactions, and how/when the blockchain is used.
    yiannakpavy
    @yiannakpavy
    To supplement the discussion above, it looks like the current uPort application still implements the Proxy Contract. See https://github.com/uport-project/specs. Is that correct?
    yiannakpavy
    @yiannakpavy
    And one last series of questions (sorry about not just creating a thread), how is key recovery implemented without the Proxy Contract and Controller Contract? Is everything backed into ethr-did-registry contract methods now? Also, is Serto now that overarching platform (that was uPort) that leverages the Veramo project?
    Mircea Nistor
    @mirceanis
    ok.. I will try to answer as much as I can.
    • an ethereum address is computed by hashing a secp256k1 public key and taking the last 20 bytes of it. No interaction with the chain is necessary. You can create a keypair on your computer, hash the public key, take the last bytes and there you have it.
      The address can be queried on chain but nothing will come up. If you go to etherscan and look for it, it will just show up as any other address that has no transactions associated.
    • the ethr-did-registry, when queried for a non-existent address will just return back the address.
    • the old uPort version is no longer used, nor available.. You may try to build it from source but you will run into many many issues that nobody can fix.
    • in the more recent model (the only one that still matters) updating the identity means updating the DID document with attributes that later get interpreted as public keys or service endpoints in the did document. Attributes on-chain are a big no-no.
      Please take time to go through the links I have posted about ethr-did, as there are many more details about how did documents are built.
    • the current uPort application does not still implement the Proxy model. I'm not sure where you find that mentioned without a deprecation message.
    yiannakpavy
    @yiannakpavy
    Thanks, man. That's helpful. Is this concept of a central registry (for off-chain look up) still alive? As a general user, why would I ever need the central registry?
    E.g., why would I ever need to do anything on-chain that is related to identity (and/or attributes)?
    (that's likely a stupid question, but again, I'm a total noob)
    Mircea Nistor
    @mirceanis
    again, on-chain attestations are not recommended.
    on-chain identity management, in the ethr-did model means posting public keys that can be used to sign on behalf of an identity
    yiannakpavy
    @yiannakpavy
    but can't that be achieved off-chain, as well? E.g., isn't that how I would disclose an attestation to a private party?
    Mircea Nistor
    @mirceanis

    Of course, most things can be achieved off-chain. The chain is only used to update public key information (that can be used to verify those off-chain attestations).
    To update those keys on behalf of an identity, you have to have control of the identity, and that is what the ethr-did-registry smart-contract ensures.

    If you have more questions about these things, please post them on https://github.com/uport-project/veramo/discussions
    There are more people there that can answer.

    yiannakpavy
    @yiannakpavy
    OK, will do. Thanks again for the help!
    Mircea Nistor
    @mirceanis
    you're welcome!
    please understand. uPort is no longer maintained :(
    yiannakpavy
    @yiannakpavy
    Right on. Thanks for the clarification. There's so much academic/technical literature out there (from as recent as last year) that provides technical analysis of the old version, so that's why I was getting confused. For what it's worth, I'm trying to gain understanding from both a developer AND user standpoint, hence some of my questions are from an identity holder's perspective.
    Mircea Nistor
    @mirceanis
    got it. I'm curious, where this literature is :)
    yiannakpavy
    @yiannakpavy
    Also, just a point of clarification, is Serto now the overarching SSI platform, and it implements Veramo?
    Mircea Nistor
    @mirceanis
    oh.. I was editing one previous answer to answer that and it got lost (I'm a noob at gitter).
    Serto uses veramo to do most operations but I'm not sure if it has all the properties of an SSI platform.
    yiannakpavy
    @yiannakpavy
    OK, cool. The https://www.serto.id/ site implies ownership of Veramo, so I was just curious. Also the headline on the top of the website seems to imply as much, "uPort is now Serto".
    Mircea Nistor
    @mirceanis
    We're close collaborators, different teams formed from a mix of older members of uPort. Used to be under one umbrella, hence the listing of all the open source libraries and veramo. "uPort is now Serto" refers to the brand.
    Veramo focuses on the lower level tech, multi-platform, keeping close to standards, modular framework.
    Serto provides services that leverage Veramo, in a nicer package than the raw framework.
    yiannakpavy
    @yiannakpavy
    Ah, that's makes sense. Man, I can't thank you enough for the discussion. I really appreciate you taking the time to help!
    Mircea Nistor
    @mirceanis
    You're welcome!
    See you on GitHub :)
    Muhammad Yahya
    @m-yahya

    Hello everyone, I'm trying to lookup for DID owner (while connected with the local Ganache network).
    The sample code is:

    const providerConfig = {
      rpcUrl: "http://127.0.0.1:8545",
      chainNameOrId: "5777",
    };
    
    const { EthrDID } = require("ethr-did");
    
    let createDid = async () => {
      const keypair = EthrDID.createKeyPair();
      const ethrDid = new EthrDID({ ...keypair, ...providerConfig });
      const owner = await ethrDid.lookupOwner();
    
      console.log(owner);
    };
    
    createDid();

    However, I'm getting the following error:

    node_modules/@ethersproject/logger/lib/index.js:187
            var error = new Error(message);
                        ^
    
    Error: call revert exception (method="identityOwner(address)", errorArgs=null, errorName=null, errorSignature=null, reason=null, code=CALL_EXCEPTION, version=abi/5.3.0)
    ..... // remove for brevity
    reason: null,
      code: 'CALL_EXCEPTION',
      method: 'identityOwner(address)',
      errorArgs: null,
      errorName: null,
      errorSignature: null,
      address: '0xdca7ef03e98e0dc2b855be647c39abe984fcf21b',
      args: [ '0xAE007a5da29A546064D0CD52d61209f00da25585' ],
      transaction: {
        data: '0x8733d4e8000000000000000000000000ae007a5da29a546064d0cd52d61209f00da25585',
        to: '0xdCa7EF03e98e0DC2B855bE647C39ABe984fcF21B'
      }
    }

    any help what I'm missing here? thanks

    Muhammad Yahya
    @m-yahya
    I could solve it using a custom registry address.