Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for subdomains for BNSv2 #6010

Open
314159265359879 opened this issue Dec 13, 2024 · 7 comments
Open

Add support for subdomains for BNSv2 #6010

314159265359879 opened this issue Dec 13, 2024 · 7 comments
Labels

Comments

@314159265359879
Copy link
Contributor

Phillip.xck.app is currently working on a draft to include (how to) in the Name system things like zonefiles, DID's and subdomains.

I will add it here when it is published.

Copy link

linear bot commented Dec 13, 2024

@314159265359879
Copy link
Contributor Author

Phillip is asking if BNSv1 subdomain support can be reinstated while they work on a solution with BNSv2.

This is affecting about 1500 users over 30 projects working/testing with UbID.

@markmhendrickson
Copy link
Collaborator

What kind of support does this entail exactly?

@paradigma-cl
Copy link

The wallet does not display the subdomain (BNS v1) name associated with the Stacks Address. We need it as an identifier.

Copy link
Collaborator

If we were to show the BNS v1 under collectibles, would that satisfied the need?

@paradigma-cl
Copy link

We studied the proposal, and having that information available as collectibles to the user is good.
Nevertheless, we need something similar to the name field we load from the profile. That name is used to check that the application user name and Stacks address matches the Wallet domain or subdomain name and Stacks address to execute some action. It prevents errors and ensures security.

We have realized that this functionality should be the same for the Subdomain BNSv1 as for the future Subdomain compatible with BNSv2. In the case of BNSv1 the Stacks Address one can get easily the domain or subdomain name using the API i.e. https://stacks-node-api.mainnet.stacks.co/v1/addresses/stacks/SP1XD6PXZZA05DZ0ATTQXK49RRC1HADJFV7AC766Z The registration of the subdomain was made on BNSv1 using a list associated to the domain name. In the BNSv2 the subdomain name was not integrated into the main smart contract, so we should have another Smartcontract service that should give a similar service of getting a name associated with the Stacks Address. In this case, we need to consider performance requirements in the case of a subdomain under a domain name. It could be thousands or millions of subdomain names with different owners under one domain name.

The challenge is that in BNSv2, each account has a list of domain names or namespaces associated with the Stacks Address. Now we are adding the possibility of having a subdomain name. We see we should only allow one subdomain name to a Stacks Address.

We doubt how the account should behave if it has a domain name defined as primary in the BNSv2, and also a subdomain name doesn't matter where it comes from v1 or v2. In this case, which one should be considered? Probably, we should say, that if there is a domain, it has priority.

But we should have at least the possibility to retrieve the subdomain name, and it is in this case, just one.

Our solution UbID.app uses domain and subdomain names as the identifiers to log the user into an application. We secure the identifier name using the BNS's identifiers. The same way when users use their email address to log into an application. The identifier is built based on the BNS, DIDs, Wallet, and Stacks ecosystem, and secured by the Bitcoin ecosystem.

For the same users, does not matter which identifier domain and subdomain names, they are all pointing to the same DID. The DID registers the identifiers associated with the Stacks Address.

@paradigma-cl
Copy link

If we were to show the BNS v1 under collectibles, would that satisfied the need?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants