[review] MD-30: Movement Name Service

MD/md-30/README.md

@@ -0,0 +1,175 @@
+# MD-30: Movement Name Service
+
+- **Description**: Define the structure for the Movement Name Service (MNS) on the Movement blockchain, providing a user-friendly way for users to interact with names and rooms through bonding curve-based access keys.
+- **Authors**: [Primata](mailto:primata@movementlabs.xyz)
+- **Collaborators**: Community contributions welcome
+
+## Overview
+
+The Move Name Service (MNS) is a system that allows users to register human-readable names on the Movement blockchain. It is designed to facilitate user-friendly interactions, registrations, and transactions on-chain. Expanding beyond traditional name services, MNS introduces the concept of access keys tied to a bonding curve, which determines the minting and burning prices of these keys. The MNS also provides revenue generation mechanisms for both the protocol and name owners.
+
+MNS falls under the SoFi category, offering a decentralized, permissionless framework that encourages community participation to build and iterate on infrastructure and services centered on Names and Rooms.
+
+## Definitions
+
+- **Names**: Human-readable identifiers registered on-chain. Should be freely tradeable. Room ownership is tied to Name. Names domain is `.move`. E.g. `[owned_name].move`.
+- **Rooms**: Digital spaces associated with a registered Name, accessible by the Name's owner or key holders.
+- **Keys**: Access key to Name's rooms. Mintable and burnable according to a bonding curve.
+- **Bonding Curve**: A mathematical model used to determine minting and burning prices for access keys.
+
+## Desiderata
+
+### D1: Decentralized and Permissionless Name System
+
+**User Journey**: Users can register human-readable names on the blockchain and access related services.
+
+**Justification**: A decentralized name system is essential for empowering users with on-chain identities and ensuring they can interact with the blockchain without technical friction.
+
+**Guidance and suggestions**:
+
+- Names should be fully decentralized and governed by the community, adhering to the principles of openness and transparency.
+
+### D2: Bonding Curve for Key Minting and Burning
+
+**User Journey**: Users or services can mint or burn access keys based on a bonding curve.
+
+**Justification**: A bonding curve ensures that access keys' prices are dynamically adjusted, preventing speculation and enabling fair access to Names and Rooms.
+
+### D3: Community-Driven Revenue Models
+
+**User Journey**: The community can implement their own revenue models via Rooms and Keys. Movement drives the first implementation with Ductus, a backend serving the name service and rooms, and Domus, the frontend that allows minting, trading, viewing of names and keys, and using chat rooms.
+
+**Justification**: Allowing the community to drive revenue through their traffic contributions promotes incentivized participation, enabling them to earn protocol-generated funds.
+
+**Guidance and suggestions**:
+
+- For Rooms and Keys, community members should be able to pass their address as `application_fee_recipient` to receive funds generated by the traffic they drive to the protocol.
+
+### D4: Expandable Name and Room Ecosystem
+
+**User Journey**: Developers can build custom applications and infrastructure using the Name and Room system.
+
+**Justification**: A flexible framework encourages innovation, enabling third-party developers to create services, tools, or applications that enhance the user experience within the MNS ecosystem.
+
+**Guidance and suggestions**:
+
+- Name and Room ownership should be tied to flexible access key resources, allowing for extensibility through third-party integrations and custom services.
+
+### D5: Each Movement Name should grant access to its own Domain for .move TLD
+
+**User Journey**: Users acquire a `.move` domain. This allows the user to host an application running on http/https.
+
+**Justification**: Domains are yet to be fully implemented for any web3 name service and `.move` is an elegant TLD with intrinsic value for a global market.
+
+## Design
+
+### Protocol Units
+
+- **NameRegistry**: Manages the registration and ownership of Names on the Movement blockchain, similar to the Aptos Name Service.
+- **NameKeys**: Manages the minting and burning of access keys tied to Rooms and Names using the bonding curve mechanism.
+- **Ductus** (temporary name): A server responsible for generating and serving Rooms' content off-chain.
+- **Domus** (temporary name): A frontend interface where users can access, message, and manage their Rooms, including features like messaging, timeline integration, and third-party service integration (such as Parthenon).
+- **Community Integrations**: The community can generate revenue on existing infrastructure by driving Keys trading on their own interface by utilizing the `application_fee` feature. This allows them to find new revenue models that either compete with or improve the Ductus and Domus ecosystem.
+
+The community can modify these temporary names or replace them with their own infrastructure and branding.
+
+## Background & Motivation
+
+Name services are integral to establishing on-chain identities, creating a user-friendly interface for interaction. Move-based name services have historically been owned by the network. The MNS maintains this model while also allowing the community to contribute content and services. The goal is to create a more innovative, community-driven Name Service on the Movement blockchain.
+
+### Expanded
+
+The Movement Name Service (MNS) goes beyond simply assigning human-readable names by introducing the concept of access keys tied to a bonding curve. This mechanism provides users with more than just an identifier—it adds a layer of value through the potential for ownership, community-building, and monetization. Access keys allow users to unlock private Rooms associated with Names, creating a user-driven ecosystem where participation and engagement with specific names hold tangible economic and social value.
+
+#### Keys and Bonding Curve
+
+Keys are pivotal to this system. By tying the issuance of keys to a bonding curve, the cost of minting and burning keys dynamically adjusts based on demand, ensuring a fair and transparent market for entry into exclusive rooms. Users who acquire these keys not only gain access to specific digital spaces but also gain a stake in the name's ecosystem. For example, as more users mint keys to access a popular room, the minting price rises, reflecting the increased demand for that space.
+
+This incentivizes early participation in popular rooms and encourages users to build brands around their names. When these names and associated rooms grow in value and demand, users can sell the keys on secondary markets, benefiting from increased key prices and potential residual earnings tied to those trades.
+
+#### Integrating SoFi into MNS
+
+The integration of SoFi (Social Finance) into the MNS framework amplifies the value of the name service. Rather than tying a name's worth to external platforms like Twitter or Discord, SoFi enables names to exist as self-contained ecosystems where the owner can control not only their brand but also the flow of interactions and transactions within their domain.
+
+By allowing people to trade well-established names, MNS unlocks additional value—when acquiring a prominent name, users can also gain access to that name’s followers and established community. This creates opportunities for individuals or brands to sell and transfer their influence on the blockchain in a decentralized manner. For developers and entrepreneurs, the introduction of an application fee tied to keys incentivizes the creation of third-party applications that route trades and interactions through their platforms, driving a thriving secondary market for names and keys.
+
+In this model, the name service and key market extend far beyond the initial design, encouraging continual growth and evolution as users build their own applications on top of the MNS framework.
+
+#### User/Developer Experience
+
+For users, the experience of interacting with MNS is streamlined and intuitive. Registering a name or purchasing access keys involves interacting with simple on-chain functions, all while benefiting from the bonding curve’s dynamic pricing. As users participate in these interactions, they become integral parts of the MNS ecosystem, with the potential to trade, mint, or burn keys as demand shifts. This flexibility provides users with agency over their digital spaces and monetization paths.
+
+For developers, MNS presents a unique opportunity to create value-added services. By integrating with the bonding curve for keys, developers can create custom frontends or applications where users manage their names and keys, while collecting application fees on trades. This creates a lucrative ecosystem where developers benefit from user engagement and traffic on their platforms.
+
+## Goals and Non-Goals
+
+### Goals
+
+- Establish a framework for the MNS system that is open and permissionless.
+- Provide the minimum viable feature set for registering and managing Names and Rooms.
+- Enable the community to iterate on the system and create content, infrastructure, and services based on Names and Rooms.
+
+### Non-Goals
+
+- Define the full scope of the MNS system beyond its initial implementation.
+- Prescribe how the Community Movement will build upon or extend the system.
+
+## Timeline
+
+- **Q4 2024**:
+  - Finalize module designs and implementation.
+  - Deploy modules to testnet.
+  - Design and build the Domus frontend interface and Ductus server.
+- **Q1 2025**:
+  - Launch the NameRegistry and key management modules on mainnet.
+  - Community-driven integrations incentives.
+
+## Operations
+
+The protocol should utilize a bonding curve model for minting and burning access keys, with funds flowing through the following structure:
+
+```move
+struct Settings {
+    protocol_fee_destination: address,
+    application_fee_percent: u64,
+    protocol_fee_percent: u64,
+    subject_fee_percent: u64,
+}
+
+#[event]
+struct Trade {
+    trader: address,
+    domain: address,
+    application: address,
+    is_buy: bool,
+    key_amount: u64,
+    move_amount: u64,
+    protocol_amount: u64,
+    domain_amount: u64,
+    application_amount: u64,
+    new_supply: u64,
+}
+```
+
+[preliminary sketch of the implementation on GitHub](https://github.com/0xPrimata/movement-names-contracts)
+
+## Security/Privacy/Compliance
+
+As this system is decentralized and permissionless, Movement Labs is not responsible for third-party content or services built by the Community Movement. The community may establish their own privacy and security mechanisms.
+
+## Risks
+
+Community-driven services may introduce unforeseen vulnerabilities or suboptimal practices if not properly vetted.
+
+## Disclaimers
+
+- This initiative is a potential continuation of the "Building the Parthenon" project.
+- The MNS system is open and permissionless, meaning Movement Labs is not responsible for content or services built by the Community Movement.
+
+## Appendix
+
+- Revisions:
+  - Initial RFC Creation: 02232024
+  - Update: Moved timeline to Q4 2024 to include community contributions. Final design and implementation shifted accordingly.
+  - There is a [preliminary sketch of the implementation on GitHub](https://github.com/0xPrimata/movement-names-contracts). If accepted, this should be moved to the official Movement Labs GitHub repository for further development and refinement.
+  - First reference to Movement Name Service is available as an [RFC](https://github.com/movementlabsxyz/rfcs/blob/move-name-service/draft-move-name-service/rfc-move-name-service.md).