BNSWG Meeting Notes

Notes from BNS Working group meetings are available on github and will be posted in this thread.

2 Likes

BNSWG 2021-10-07 1300-1330 UTC

Attendees: Marvin, Mark, Thomas, Larry

Summary

There is general interest in improving BNS so that it can be more widely used in the ecosystem and enable new business models. We want to involve in more stakeholders.

Agenda

  1. Intro: How you plan to use BNS, your interest in this working group
  2. BNS’s position in the stacks ecosystem: traditionally it has been part of the blockchain. Should this continue or should it be separate project built on top of it?
  3. When/How should we engage more community members?
    1. Should this be done via the Stacks foundation or separate org?
  4. Ideas for near-term improvements to BNS
    1. Reverting previous hard fork changes to BNS:
      1. Solving issue 37 (1 principal can own multiple names) for Stacks 2.1
      2. paying namespace creators instead of burning funds
    2. Updating BNS to support SIP-009 NFT Standard
    3. Marvin’s BNSv3
  5. Other business

Action items

  • mark will reach out to additional interested parties
  • marvin will look at the next steps we need to take with the foundation
1 Like

BNSWG 2021-10-14 1400-1430 UTC

Attendees: Gina, Larry, Mark, Thomas

Summary

We discussed next steps and came up with a list of action items.

Action items

  1. larry will post forum post after call posted
  2. larry will reach out to aaron about multiple names per address
  3. thomas will reach out to ludo about his thoughts
  4. gina will ask btc.us team to write up the problems they had with 1 name per address limitation
  5. larry ping marvin about written version of BNSv3 ideas
  6. larry will ask ken if he’s interested in joining
1 Like

BNSWG 2021-11-04 1400-1430 UTC

Attendees: Gina, Larry, Thomas, Mark, Ken, Alex Gaebe, Eshwari, Ludo, Kyran

Summary

Given the large number of new people on the call, each person explained why they are interested in BNS and the creation of a BNS working group.

We discussed a few of the potential improvements, the creation of a roadmap for BNS and the benefits and drawbacks of tying BNS tightly to the Stacks node software and upgrade process.

We quickly ran out of time and a suggestion was made that we outline the issues and discuss in writing and come back on a longer call in the future to discuss solutions. This was agreed and Larry and Mark volunteered to take the lead on logistics.

Action items

  • Larry and Mark will work out logistics on 2021-11-05.

BNSWG 2021-11-05 1330-1430 UTC

Attendees: Mark, Larry

Summary

In order to encourage contribution, each person in the BNSWG needs to own an initiative. These initiatives will be tracked and discussed on Github.

Members will be responsible for promoting/selling their initiatives to the wider community through content they produce.

We’ll plan to have at least one monthly recurring call, the appropriate length of which will be determined in the future.

Action items

  • Mark will write up a README document proposal outlining logistics and how the group will operate.
  • Larry will create initiatives to kick off discussion around the current potentials initiatives raised by members of the group.
2 Likes

BNSWG 2022-05-05 1400-1500 UTC

Attendees: Mark Hendrickson, Larry Salibra, Louise Ivan, Abdou, Yukan Liao, werner.btc, Hero G

We failed to take notes, but we did create a telegram group for the BNSWG. Available here: Telegram: Join Group Chat

BNSWG 2022-06-02 1400-1500 UTC

Attendees: Larry Salibra, Phillip, Yukan Liao, Werner, Hero G, Marvin Janssen

Agenda

  • Upgrade path for BNS
  • Creation of a SIP proposal to fix existing bugs
  • Other business

Upgrade path for BNS

We discussed the options: hark-forking the existing contract with Stacks 2.1 vs deploying a new contract and getting other people to use it. As a lot of things are hardcoded to the current contract address, the general consensus seemed to be hardforking was the better method.

Proposing a SIP to fix problems with existing BNS contract

Larry proposed these items to be included in a proposed:

Discussion:

  • Multiple names per contract is allowed already if you include subdomains
  • One participant is launching a service that gives the subdomain on bns to the owner of the same ICANN subdomain
  • Pricing of namespaces is too rigid: it prevents use cases like Chile’s NIC buying .cl and selling names with their ICANN names.
  • Why don’t we have a voting contract for BNS? We have this for stacks. (Discussed in relationship to the inflexibility of name/namespace pricing)
  • The intent of proposing these bug fixes / non-controversial changes is to start a discussion about what we want for BNS in the future.

Other business

Xverse wants to make it so that you can send bitcoin to a BNS name.

  • Discussed proposing a SIP vs unilaterally coming up with their own format.

  • We talked about how hypothetically in the future it might make sense for standards that only relate to BNS to go through BNSIP process separate from the SIP process.

  • Larry mentioned that we previously had support for adding a bitcoin (or other addresses) to profiles. This is from larry.id’s profile and how it was previously done:

{
  "identifier": "1EyuZ8qxdhHjcnTChwQLyQaN3cmdK55DkH",
  "role": "payment",
  "@type": "Account",
  "service": "bitcoin",
  "placeholder": false
}

Discussed about using BNS via bitcoin.

  • Prior to Stacks 2.0 you could registered some names with only BTC
  • We agree that BNS should be more tightly tied to bitcoin
  • We liked the idea of making BNS the best name system it can be for bitcoin.
  • It’s unclear if we still register .ids with only bitcoin
  • Discussed the possibility of two approaches to tying BNS more closely to bitcoin
    1. Making it so that certain namespaces require you to send/burn some BTC to register a name in that namespace
    2. Make it possible to register names only through bitcoin without having to interact with stacks nodes at all - using something similar to the Stacks 1.0 OP_RETURN format. These names would exist in stacks nodes as well. It’s unclear if stacks would be able to read them with current functionality today

Action items:

  • Separate controversial items in a separate SIP: multiple names per account was the only controversial item we found
  • ask Friedger:
    • if he’s encountered any other bugs in the BNS smart contract
    • using BNS with bitcoin, ask about SIP process
  • ask Jude about ability to register .id names with bitcoin
1 Like