• Development
  • StellarExpert - New features and public Directory API

Fresh StellarExpert release is deployed, and I'd like to share some info about new features implemented since previous major release.

  • XLM supply chart shows the circulating amount and its changes over time.
  • Open Directory API for developers. Use a curated list of well-known account addresses in your application.
  • New Directory explorer interface.
    StellarExpert Directory
  • All dates displayed in UTC format, no more problems with local browser timezone conversions.
  • Multiple minor bugs fixed, performance improved. The explorer and ingestion engine are now stable.

Special thanks to @irisli, who maintained the original Stellar directory. Sorry to see that StellarTerm is shutting down.

How does the directory get updated? I was thinking of publishing a community-maintained list of known accounts and then creating simple clients to consume it for the popular programming languages.

    OrbitLens Sorry I meant by what process does the contents of the directory get updated?

    Is there a way to submit new addresses for inclusion?

      StellarGuard For now, I administer the list of addresses manually. All records are stored in the DB.
      If you find any inaccuracies or want to request new address listing, please drop me a note at orbit.lens@gmail.com.

      In a week or two I'm going to design a simple listing request form with standard fields to make the process as simple as possible for users.

      My first thought was to use Stellar data entries + muli-sig and request at least two confirmations from the well-known community members, but at this point it looks over-complicated. Managing the list manually requires much less efforts than the deployment and maintenance of the special service.

      StellarGuard

      Not a bad idea, but the thing with these are always the same -- they contain way more information than you need.

      E.g., I was using stellar-dictionary previously, but the only thing I actually care about is if an account requires a memo or not. 99% of stellar-dictionary is about other things.

        dzham I can add the fields query parameter to the API to force endpoints return only specific fields, the same way Google and other data providers do this.

        For example,

        /directory?fields=accepts,name

        will return something like

        {
          "_links": {...},
          "_embedded": {
            "records": [
              { 
                "address" : "GA6HCMBLTZS5VYYBCATRBRZ3BZJMAFUDKYYF6AH6MVCMGWMRDNSWJPIH",
                "paging_token": "GA6HCMBLTZS5VYYBCATRBRZ3BZJMAFUDKYYF6AH6MVCMGWMRDNSWJPIH", 
                "name" : "Changelly", 
                "accepts" : {
                  "memo" : "MEMO_ID"
                }
              },
              { 
                "address" : "GBR3RS2Z277FER476OFHFXQJRKYSQX4Z7XNWO65AN3QPRUANUASANG3L", 
                "paging_token" : "GBR3RS2Z277FER476OFHFXQJRKYSQX4Z7XNWO65AN3QPRUANUASANG3L", 
                "name" : "PapayaBot", 
                "accepts" : {
                  "memo" : "MEMO_TEXT", 
                  "merge" : true, 
                  "pathPayment" : true
                }
              }
            ]
          }
        }

        What do you think?

        Hey guys,

        I regularly parse this directory data to update my aliases. Of course I use it to avoid displaying cryptic keys:

        https://cosmic.link/?changeTrust&asset=ETH:GBDEVU63Y6NTHJQQZIKVTC23NWLQVP3WJ2RI2OTSJTNYOIGICST6DUXR

        (Click on ETH to see the issuer)

        Now there's another way to achieve the same result that I prefer: federated addresses:

        https://cosmic.link/?changeTrust&asset=CNY:admin*ripplefox.com

        Not only the link becomes understandable, but you can actually remember asset references. Also, it leaves no doubt about which domain control the adresses, and there's no need for a third party to build a collection of adresses, with the security flaws & authority issue that may come with it. Users can also use it as input which is very convenient.

        Now, I'm conscious of the drawback, that is if federated server got corrupted it may be a big deal. But I guess that's why we got DKIF.

        Don't get me wrong: I appreciate this directory and would be happy to contribute to it with a PR someday. Anyway I recommend relying more on federated addresses for the purpose of non cryptic address display. It's a great tool and it does scale. Not sure why it's not used more.

        Actually I was surprised I couldn't find federated adresses for apay.io (@umbrel), naobtc or StellarGuard (master*stellarguard.me Paul?)

          MisterTicot I started using directory for exchanges and primary use case is preventing user errors with memo to reduce number of support queries. Federation is good, but it requires action from the entity itself, while Directory is our community effort to make things easier.
          Big thanks and respect to @OrbitLens for taking initiative on that one.

          MisterTicot Completely agree with you, Federation Protocol is awesome, and is widely supported in the ecosystem. However, the Directory contains a list of well-known addresses and advanced properties (like accepted memo type), regardless of the Federation support.

          For example, even if most of the addresses from the list do support federation, you have to query them all in order to retrieve a friendly name for each of them. In some cases, it just won't work. For example, on the StellarExpert Assets page more than 20 asset issuers are displayed at a time. That's 20 requests to Horizon and 20 more to the corresponding stellar.toml files.

          Again, the Directory contains extended metadata for each anchor. Papayabot supports not only PAYMENT but also MERGE_ACCOUNT and PATH_PAYMENT operations; it also requires MEMO_TEXT to be set.
          That's why the record looks like

          { 
              "address" : "GBR3RS2Z277FER476OFHFXQJRKYSQX4Z7XNWO65AN3QPRUANUASANG3L", 
              "name" : "PapayaBot", 
              "domain" : "papayabot.com", 
              "accepts" : {
                  "memo" : "MEMO_TEXT", 
                  "merge" : true, 
                  "pathPayment" : true
              }, 
              "tags" : [
                  "anchor", 
                  "issuer"
              ]
          }

          Ho. I guess I totally missed that point ?