I see the value proposition for territory founders to have tools they may wish to use and to use them as they see fit but I don't see the value proposition for SN broadly. The benefit of territories besides the revenue is breadth of content hopefully leading to more activity on the site and more users on the site. The drawback at least currently as we are in the early days (wild west phase) of territories is a more siloed user experience. I think giving founders tools to restrict engagement (I am not talking about bots or zap farming posts) further silos SN. I think it is a delicate balance you have to strike between growing SN and the feature set and maintaining the magic that got SN to this point.

In my opinion, the territories are like "franchises" of SN. There should be some tools and autonomy for territory founders to manage their territories as they see fit but ultimately those should align with the broader SN experience, value proposition, user loyalty ethos.

I've been working on a project to build a decentralized DNS, using Bitcoin and Nostr for the base layers. It's starting to come together, and I wanted to get some feedback on the general approach to the protocol.

The idea is this: Bitcoin serves as the timestamp provider. Publish a hash on the blockchain. Built into the hash are the root-level name, the public key and a merkle root for children (more on that in a moment). This is published to the timechain as a proof of ownership (names are first come/first serve).

After publishing a claim of ownership on chain, you can then publish a Nostr event, which contains the data necessary to recreate the on-chain hash. After that link is forged, we can use additional nostr events to publish record changes (like DNS records), always linked back to an on chain proof of ownership.

As you can see, the idea is that the blockchain is used to basically timestamp a claim to a name, and nostr is the actual transport protocol for the name data. It uses the same cryptographic primitives as bitcoin and nostr, so it all dovetails very nicely together.

It is intended to be highly scalable, because root-level names published on chain are actually entire namespaces on their own, containing potentially infinite descendants in a tree. Think of it like: com is the root name, amazon is a child, www is a grandchild, etc. The only thing that ever needs to be published on chain again are ownership changes (transferring ownership of a name to a new private key, or adding new descendants).

It's also intended to be self sovereign and censorship resistant. The descendants are aggregated into a merkle tree and published as part of the ownership proof hash on chain, and each name is associated with its own cryptographic key. Which means that, even in the distant future when you may not be able to afford an on chain transaction yourself, but if you get a descendant name from some business offering the service, once you are given it, it belongs to your private key and cannot be revoked.

I'm building an indexer right now, which is just software to look for transactions on chain and the correct nostr events on relays, then link then and provide an API to query for name records. Once that is ready, in a few weeks or a month, I will publish it along with a more formal-ish spec.

The intention is for this to be a very simple protocol, easy for devs to implement and understand. If nostr has taught me anything, it's that simple protocols inspire a lot of enthusiasm.

Any thoughts on this approach?