The registrar needs to update the transaction status for a large number of transactions during operation. However, it currently issues all of these calls to the Stacks Blockchain API in a foreach loop which quickly results in 429 status code responses (rate limits).

The registrar should stop sending requests to the API when a 429 is received and resume them later.

The registrar currently runs on node 12, which is outdated and no longer maintained. It should be upgraded to at least node 18 which is the current LTS version.

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No name for the package defined.

A name for the package must be created. Run through npm (npm run to use npm package name or define packageName in the plugin config or SEMANTIC_RELEASE_PACKAGE in the environment

Good luck with your project ✨

Your semantic-release bot 📦🚀

The current subdomain registrar is limited by relying on sqlite -- it makes concurrency pretty hard, and things like registrations and batch processing are currently stepping on each other's toes. Moving to postgresql opens up a lot of space to improve on this front (and makes cluster operation much easier).

The registrar still contains request logic that assumes the target nodes are from Blockstack v1, including custom load balancer logic that is no longer relevant.

It should be updated to reflect the newer Stacks v2 (or upcoming Nakamoto v3) logic.

https://discord.com/channels/621759717756370964/909867922971820102/936361070136795156

For example, for this username https://registrar.stacks.co/v1/names/testtesttest101.id.stx, there is an issue with the tx id "last_txid":"[object Object]".

The last_txid was empty for some time, and then after 30 mins it started to return "last_txid":"[object Object]".

Is the Stacks registrar having some issues? Sometimes it's working and sometimes not, it's also really slow, some requests are taking 20+ seconds to get an answer from the API.

We can support a "social proofs" requirement in the subdomain registrar fairly easily --- this could be configured via the config.json or the like.

The basic design would require that the profile URL in the given zonefile be signed by the requester's owner address, and contain n valid proofs, at the time of the register.

The subdomain registrar should be configurable to set a _resolver entry. This will be used by name resolvers to determine where to send name info queries for pending subdomains.

If the subdomain registrar runs out of Bitcoin when accepting a new registration request, it never replies to the client. This causes subdomain registration from both the CLI and from the Browser to freeze. Instead, the subdomain registrar should queue the request and reply to the client as normal (possibly with a hint that it's out of Bitcoin).

This repo is currently publishing to blockstack/subdomain-registrar on Docker hub.
We are in the process of migrating it to stacksnetwork/subdomain-registrar

ci.yml file needs to get modified to publish on both repositories.

This issue is intended to track configuration details for the Stacks Foundation, which will be hosting an instance of the registrar for the community.

• Estimate STX budget needed for allocation to registrar wallet for at least 1 year of operation
• Determine whether Hiro PBC needs to transfer ownership of .id.stx address to Foundation
• Determine what anti-spam measures are available out of the box (or if others are necessary)
• Determine if we can set up alerts for abnormal runtime behavior (e.g. increased registration rates indicating spam, percentage of % budget spent) to help Foundation monitor maintenance needs
• Determine if there are any other runtime parameters to configure

In support of leather-wallet/extension#946

The registrar needs modification by the release of Stacks v2 so that sponsored ID registration either during onboarding or subsequently do not break.

We should deploy a subdomain registrar, initially for internal usage, but then for public usage.

This will require:

• deciding on a domain to use
• funding a payment wallet
• deploying the service and pointing a DNS entry at it

Would also appreciate feedback on the ease of deploying the registrar.

Tagging @jackzampolin for an assist here!

When I'm trying to register a subdomain I get the following error:

2018-05-17T05:35:53.799Z - error: FetchError: request to http://localhost:16268/v1/names/leela.kitsana.id failed, reason: connect ECONNREFUSED 127.0.0.1:16268
at ClientRequest. (/Users/Kitsana.Dounglomchan/subdomain-registrar/node_modules/isomorphic-fetch/node_modules/node-fetch/index.js:133:11)
at emitOne (events.js:116:13)
at ClientRequest.emit (events.js:211:7)
at Socket.socketErrorListener (_http_client.js:387:9)
at emitOne (events.js:116:13)
at Socket.emit (events.js:211:7)
at emitErrorNT (internal/streams/destroy.js:64:8)
at _combinedTickCallback (internal/process/next_tick.js:138:11)
at process._tickCallback (internal/process/next_tick.js:180:9)

Description

It looks like the current subdomain registrar implementation does not allow users to transfer subdomains to other addresses.

example https://registrar.stacks.co/v1/names/alexandernacho.id.stx shows the linked address,
{"blockchain":"stacks","status":"submitted_subdomain","last_txid":"32ad1787fcaa6a8aaf6f29ff440fab63d098374af1549b08dff6d14db59d39cf","zonefile":"$ORIGIN alexandernacho.id.stx\n$TTL 3600\n_http._tcp\tIN\tURI\t10\t1\t\"https://gaia.blockstack.org/hub/1G6DVN2rCw4cWKpTE6yVaJQHMMpJXXfMfD/profile.json\"\n\n","address":"SP2JRCS2HC0WC5D29NC683RPXDVK9F41Y7W4EQS9V","zonefile_hash":"41c8cf0cea57becec455a6449e39f33059a9aa94"}
but calling its
stacks name or name history
can not confirm its state in the chain.

Could that come from orphaned TXs? How many orphaned BNS names are there?
And the wallet is able to get a second BNS name.

When trying to register a new username, the following error is thrown.

{
    "status": false,
    "message": "Failed to validate your registration request. Too much pending tasks"
}

The registrar uses a naive approach for getting the current nonce - which is just to call /v2/accounts and get the current nonce. This does not reflect any tx's in the mempool. If the registrar makes a name_update tx and then makes another one before the first was confirmed, the second tx will get rejected due to a conflicting nonce error.

This can be worked around with a longer "batch interval" configuration - but it's not ideal.

Two options to do a better job:

• Get all pending tx's for the registrar payer, and if there is a pending tx, use the highest nonce + 1
• Store tx nonce's in the database, and use the next highest one

cc @kantai

Much has been done to improve the onboarding experience for new Blockstack users. One of the remaining tasks is the ability to search for these users by name etc. instead of requiring their precise Blockstack ID before it is indexed and added to the search endpoint (/v1/search).

Consider an event, show, or conference where non Blockstack users are exposed to a social dApp and wish to try the experience. They sign in, creating a new Blockstack ID, and then search for each other by name (currently how I've seen Stealthy, Graphite, and Misthos operating if recollection serves me). Unfortunately they can't find each other. They need to exchange fully qualified Blockstack IDs and then search for them to connect and experience the social aspects of the dApps (which can be problematic as described in this issue: stacks-network/stacks-core#847). Or they will have to wait a number of hours before the search endpoint picks up and indexes their names/IDs. By this point, many of them will have forgotten about the dApp and their interest in trying it. If we can correct this, it goes a long way towards showcasing the performance equivalency to centralized experiences.

One short term fix might be a simple endpoint of pending names mapped to their Blockstack IDs--by providing this, dApps could include these names in their searches and then query the name endpoint for profile data, circumventing the wait for indexing.

We need a solution, even short term for September 3rd, 2018 if possible to address this situation.

@jcnelson @kantai @larrysalibra

Related:

• https://forum.blockstack.org/t/the-search-endpoint/6014/4
• stacks-network/stacks-core#847

We should add an admin endpoint for resetting a given IP's limit count.

There are newer request libraries such as undici that are much more easy to work with when it comes to JSON parsing, request/response schema validation, status code and headers handling, etc.

The registrar should be updated to use one of these librares so it can abstract away this logic when calling the Stacks API. Another option is to use the Stacks Blockchain API client to issue these calls.

The protocol supports transferring subdomains to new keys, but the registrar needs to be able to accept a signed transfer request to do so.

As first indicated on the devops issue for hosting the updated registrar, we need to modify the PR for the updated registrar to handle ENV variables in a more suitable way.

This is blocking for devops to host the registrar on testnet and mainnet, which is needed to subsequently restore username registration functionality for apps.

cc @andresgalante

If we want to implement #30 and other improvements, we'll need increased code coverage in our testing. We should aim to get to 90% here.

Currently ~78%

For example https://stacks-node-api.testnet.stacks.co/v1/names/justanotherfriedger.id.blockstack shows

{"address":"1Aj97PGvpHMpTK4r6QZYm7rttz23rRHrqf","blockchain":"stacks","last_txid":"0x","resolver":"https://registrar.blockstack.org","status":"registered_subdomain","zonefile":"$ORIGIN justanotherfriedger.id.blockstack\n$TTL 3600\n_http._tcp\tIN\tURI\t10\t1\t"https://gaia.blockstack.org/hub/1Aj97PGvpHMpTK4r6QZYm7rttz23rRHrqf/profile.json\"\n\n","zonefile_hash":"55b74ce8140711a86fb41a7ca4876144f9d27929"}

Is this an issue of the subdomain registrar?

Hey, it's me and @pradel .

We got a grant to improve the subdomain registrar performance, which is critical for Sigle and perhaps could be reused later on for other apps.

Here is a link to said grant : stacksgov/grants-program#282

M1 in the grant application contains several suggestions for tooling improvements such as:

• Migrating Flow to TypeScript
  • Do you want to keep using Babel or move to Typescript compiler similarly to how it's implemented with Stacks.js and stacks blockchain api?
• Setting up Prettier
  • Do you want us to add git Hooks with Husky?
• Setting up Eslint
• Setting up Jest
  • Do you want to keep using Tape or switch to Jest?

We are keen to hear what's your feedback regarding introducing the aforementioned tools to improve developer experience.

@asimm241 @CharlieC3

The registrar can receive 404 status codes from the Stacks Blockchain API if a transaction ID is not found for any reason (missing from mempool, etc.). It should try again later but also keep a log of how many times it has retried so it can discard these transactions as invalid.

Rather than using a hardcoded adminPassword in the config file like :

  adminPassword: 'NEEDS-A-PASSWORD',

It would be better to use an env if present: ADMIN_PASSWORD="my-fake-password".

This would prevent adding an admin password in plain-text, similar to how the payment & owner keys are handled.

https://github.com/blockstack/subdomain-registrar/blob/master/src/config.js#L53

In order to implement instantaneous sponsored name resolution, the registrar needs to be able to respond to GET /v1/names/{sponsored-name} and reply the same data that a Core node would reply.

My thinking is that we make core.blockstack.org reply with a 302 to the sponsored name registrar when it tries to (1) resolve a sponsored name that does not exist, and (2) detects that the sponsoring name (the on-chain name) has previously sent a zone file that lists a resolver endpoint.

Here's what I'm thinking for the implementation. In order to implement (2), the sponsoring name needs to send a zone file with the following resource record at some point:

_resolver IN URI 10 1 "https://sponsored-name-registrar.com/API/endpoint"

The Core node would send an HTTP 302 to the _resolver URI record. Specifically, it would choose the latest such record if there are multiple zone files with the _resolver record.

The client (e.g. blockstack.js, curl, etc.) would issue the GET /v1/names request to https://sponsored-name-registrar.com/API/endpoint in response to the HTTP 302.

I would implement the _resolver parsing and redirect logic in Core, and this program would implement GET /v1/names for sponsored names in the db. Do you think this is reasonable?

At bootup, if the registrar cannot reach an API instance at https://stacks-node-api.stacks.co/v2/info, it'll log an error and fail to complete startup. It will also fail to gracefully exit.

registrar

@promster/server started on port 9153.
{"message":"Error fetching block height. request to https://stacks-node-api.stacks.co/v2/info failed, reason: connect ETIMEDOUT 104.22.42.120:443","stack":"Error: Error fetching block height. request to https://stacks-node-api.stacks.co/v2/info failed, reason: connect ETIMEDOUT 104.22.42.120:443\n    at updateGlobalBlockHeight (/src/subdomain-registrar/lib/operations.js:2901:11)\n    at processTicksAndRejections (internal/process/task_queues.js:97:5)","level":"error","timestamp":"2022-08-27T00:36:53.151Z"}
{"level":"error","message":"Error: Error fetching block height. request to https://stacks-node-api.stacks.co/v2/info failed, reason: connect ETIMEDOUT 104.22.42.120:443\n    at updateGlobalBlockHeight (/src/subdomain-registrar/lib/operations.js:2901:11)\n    at processTicksAndRejections (internal/process/task_queues.js:97:5)","timestamp":"2022-08-27T00:36:53.152Z"}       (node:9) UnhandledPromiseRejectionWarning: Error: Error fetching block height. request to https://stacks-node-api.stacks.co/v2/info failed, reason: connect ETIMEDOUT 104.22.42.120:443        at updateGlobalBlockHeight (/src/subdomain-registrar/lib/operations.js:2901:11)                                                                                                            at processTicksAndRejections (internal/process/task_queues.js:97:5)                                                                                                                    (node:9) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)                                                                                                                                         (node:9) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

If this were to happen, ideally the registrar would retry indefinitely and finish the startup process.

Hello block stack team

I am facing an error in running the command as sudo npm i -g

This is what I am getting in output.

up to date in 30.648s
npm ERR! path /Users/yudiz/.npm-global/lib/node_modules/blockstack-subdomain-registrar/lib/index.js
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall chmod
npm ERR! enoent ENOENT: no such file or directory, chmod '/Users/yudiz/.npm-global/lib/node_modules/blockstack-subdomain-registrar/lib/index.js'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent 

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/yudiz/.npm/_logs/2019-05-23T08_45_08_702Z-debug.log

**can you please help me to solve this ? **

Thank you

This would prevent both PBC and non-PBC developers from getting blocked for a lifetime based on their IP addresses, forcing them to switch to another network as they invest more time developing and testing with new usernames.

We need to pick a URL for the deployed registrar.

I like:

subdomains.blockstack.org

Thoughts -- @yknl @larrysalibra ?

The following is a list of issues that must be tackled in order to bring the subdomain registrar to a much better operating condition than it has today.

The current version has been increasingly harder to deploy and maintain given that it is a 6-year old project that has not been worked on for a while, and which assumes the Stacks chain works differently than it does today. Once these issues are resolved, a new release should be published and an effort should be made to get other interested parties, applications and users in the Stacks ecosystem to contribute to its development.

Items are not necessarily in order of priority or severity.

• #103
• #104
• #102
• #101
• #100
• #90
• #77
• #64
• #49
• #30

Currently, the Dockerfile calls npm run start, which invokes the babel compiler before running the built node files. This is terrible -- see, for example,

facebook/create-react-app#8062

Currently, our subdomain registrar only handles registration requests. It should additionally handle updating those entries.

The resolver supports parsing and verifying these updates, but an endpoint needs to be added to the registrar (and verification code for the registrar, so that it doesn't add invalid entries to it's zonefiles, even if the resolvers will ultimately ignore them).