Managing Domains, Storage, and App Access from a Wallet

An application needs a storage space. A website needs a domain. Another app asks for a Passport before allowing access. Across ArcBlock products, these tasks share a recognizable interaction: the application makes a request, the user selects the relevant object in DID Wallet, and the user confirms how it will be used.

This makes the wallet an entry point for working with resources. What the user carries is a verifiable relationship to a resource. Storage, domains, and access credentials retain their own service rules, but people can identify, present, and use those relationships through a familiar interface.

Connecting a DID Space is a useful place to see how this works.

Choosing the space an application will use

A Blocklet application that supports DID Spaces can initiate a connection through DID Wallet. The wallet displays the relevant NFTs, and the user selects the target space. Once the connection succeeds, the application receives information identifying that space, including its name, DID, and service address.

The DID Space components article shows this flow. It also documents a more targeted route: enter the space's gateway address first, then use the wallet to present the corresponding NFT. The gateway is the service entry point an application uses to connect to the space. Specifying it first narrows the choice when a user has several spaces.

The practical question being answered is simple: which space should this application use?

A space can be connected for application backups or business data, and the product also supports connections at the session level. These purposes can involve different patterns of data access. Selecting the resource brings the user's intent into the connection process.

There is a boundary here that the interface needs to preserve. Connecting establishes which space the application will work with and completes the relevant connection flow. Which data the application can read, where it can write, and which operations it can perform remain matters for the service's authorization rules. A connection should never be interpreted as permission to access everything stored in a space.

The object in the wallet leads to a running service

The user sees a selectable object in the wallet. DID Space stores the actual files, and applications reach those files through the space's service interface. The NFT helps identify the resource and the relevant relationship to it. The wallet presents that object and handles proofs and signatures. The resource service performs the work.

Keeping these responsibilities distinct makes the product easier to understand when something goes wrong.

Suppose a user has selected a space, but a later write fails. The space might have reached its usage limit. Its subscription might have expired, its version might be incompatible, or the network might be unavailable. Each condition calls for a different response. Presenting the NFT again does not add storage capacity, and reconnecting does not fix a version mismatch.

The DID Space connection components therefore expose connection status and distinguish conditions such as usage limits, subscription expiry, version incompatibility, and network errors. These messages are part of resource management. A user needs to know both what they are entitled to use and whether the service can do the requested work now.

An NFT can remain in a wallet while the associated service is unavailable. Holding the object, having permission for an operation, and reaching a functioning service are separate facts. An interface that shows the distinction gives people a useful next step instead of another unexplained failure.

A domain follows the same pattern

Domains connect this model to a familiar part of the internet.

To configure an existing DID Domain for a Blocklet, a user enters the domain and presents its NFT through DID Wallet. The domain guide describes this both during application launch and from the Blocklet dashboard. The user's intention is to use a particular domain with a particular application. The wallet brings proof of the relevant right to the place where it is needed.

This also works with existing domain infrastructure. DID Names supports hosting domains registered with other registrars. After completing the relevant hosting setup, the user receives an NFT that allows the domain to be used on the Blocklet platform. That connects the domain, its DNS service, and the application configuration.

The relationships involved still need precise names. Holding a domain registration, using DID Names for hosting, and configuring the domain for an application are different things. Presenting an NFT proves the usage qualification required by the platform. It does not automatically transfer ownership of the domain at a third-party registrar.

This is a useful property of the resource model: existing services can retain their jobs. Domains continue to work through DNS, and applications still need valid configuration. The wallet supplies an entry point for proving the relevant rights and requesting that configuration.

Presenting a Passport

Storage and domains connect the wallet to service resources. A Passport uses a similar interaction to establish eligibility for application access.

Through DID Connect, an application can request an NFT or verifiable credential that meets its conditions. The user reviews the request in the wallet. If several objects qualify, the user chooses which one to present. The application receives the proof and applies its own rules to decide whether the user may continue.

The DID Wallet presentation guide makes an essential point explicit: presenting an NFT does not send the NFT to the application.

Proving that you hold a qualification does not require handing it over. The user makes a presentation; the application verifies it. A transfer changes a different relationship and must be handled according to the resource's rules. The two actions should never be hidden behind the same ambiguous confirmation.

The scope of a qualification matters too. A Passport may satisfy one application's entry requirement without granting administrative rights over that application or access to other resources. DID Connect's request mechanism lets an application specify object types and trusted issuers, giving the verification a defined purpose.

From the user's perspective, the request should be concrete: which application is asking, which qualification will be presented, and what the confirmation is intended to accomplish. The proof underneath can be complex. The decision the person makes should be understandable.

From displaying a resource to acting on it

If a wallet only displays resources, users still have to locate a separate management interface for each one. NFT Actions brings resource-related operations alongside the object, allowing users to inspect its state and initiate the corresponding requests from the wallet.

Those operations follow the resource and its permissions. A storage space has storage operations. A domain has domain operations. An access qualification follows the rules of the application that recognizes it. The wallet can show what the user has selected and which requests are available without treating all resources as interchangeable.

The service still executes the request. The wallet handles the user's confirmation and the relevant signatures; the service checks permissions and current conditions before carrying out the permitted operation. That division lets the wallet serve as a common entry point while each service retains the capabilities needed to do its job.

For resources that support transfer or delegation, the interface also needs to explain what changes afterward. Presenting a proof, allowing an application to use a resource, and transferring a transferable right to another holder have different consequences. Their shared starting point in a wallet does not make them the same action.

Bringing a resource relationship into an application

DID Spaces, domains, and Passports repeat a practical pattern. A user selects the object relevant to the task, presents a verifiable relationship to the application, and lets the service perform the work that relationship permits.

This changes how resources enter an application. An app can ask for a resource or qualification the user already holds, and the user can choose which one to use at the moment of the request. Storage, DNS, and access control continue to perform their respective jobs.

That is the purpose of DID Wallet as a resource interface. The wallet helps the user answer, “What can I use, and which application do I want to use it with?” The service answers, “Can this request be performed now?” When both sides do their jobs, an NFT in the wallet becomes a resource relationship that the user can put to work.