Virtual File System
Username registration is currently disabled on mainnet.
Introduction
The Virtual File System (VFS) is a part of the Andromeda Messaging System (AMP) which was heavily inspired by the linux file system. Users can register their address to a username. They can also register ADOs to paths. These paths can then be used and referenced in our ADO systems.
When an Andromeda App is made, it will register all paths for its child components and also register itself as a child of the instantiating address. Each component under the App is registered by its name, and the App itself is registered under its assigned name.
In addition to paths, symbolic links that point to a path can be created by users.
All paths and usernames are resolved by the VFS in lowercase. For example, the username "USER" and "user" are considered to be the same. Same applies for paths, "/home/USERNAME"
and "/home/username"
are the same.
Example:
A user does the following:
Registers their address as user1 by calling RegisterUser
The user then creates an App and calls it "app-1" which has 2 compnents named "comp-1" and "comp-2"
The App will automatically register its components under their assigned names
When you register a username, it will registered in the "home" directory.
The following paths are now registered:
/home/user1 will resolve the the user's address
/home/user1/app-1 is the path to get the address of the app contract
/home/user/app-1/comp-1 is the path to get the address of component 1 in the app
/home/user/app-1/comp-2 is the path to get the address of component 2 in the app
When Can we Use a VFS Path
When you go through our ADOs, you will notice an AndrAddr struct used very frequently for specifying addresses, whether be user addresses or ADO addresses. The use of this struct signifies that the address can be referenced by either the VFS path or the user/contract address. More on the AndrAddr struct can be found here.
VFS Paths in Apps
Local references can be used in case of Apps. These would include the component addresses and can be referenced using " ./<component-name>" as a valid path.
For example if I want to create an app with two components named "token" and "auction", and in the auction I want to reference the token address, I can use ./token to do so. Another example here would be a sending an NFT from a CW721 to an auction. Instead of specifying the auction contract address as the recipient, you can use the local reference ./auction to do so as long as the components belong to the same App.
Ado_type: vfs
InstantiateMsg
Name | Type | Description |
---|---|---|
| String | Address of the Kernel contract on chain. Can be found in our deployed contracts. |
| Option<String> | Optional address to specify as the owner of the ADO being created. Defaultes to the sender if not specified. |
ExecuteMsg
AddPath
Registers a component to the path.
Only accepts alphanumeric charaters.
If user1 registers ado1, then the path created would be /home/user1/ado1.
Registering a path that is already found will overwrite the old path.
Name | Type | Description |
---|---|---|
| String | The name of the component in the path. |
| Addr | The address of the component. |
| Option<AndrAddr> | Optional address to specify as the parent for the component. If not specified, then the sender will be the parent by default. |
AddSymlink
Creates a symbolic link that points to a specific path.
Name | Type | Description |
---|---|---|
| String | The name of the symlink. |
| AndrAddr | The path to point to. |
| Option<AndrAddr> | The address to register the symlink under. |
In the JSON example above, if the username of the sender (parent address) is user1, then the symlink "/home/user1/my-link" would resolve to the path "/home/user2/app1".
RegisterUser
Registers a username to an address.
You can only register a username for your address (sender).
Only accepts alphanumeric charaters.
Usernames are unique, meaning no two users can have the same username.
If
address
is provided sender must be Kernel.Username cannot exceed 40 characters.
This message is currently disabled on mainnet.
Name | Type | Description |
---|---|---|
| String | The username to register. |
| Option<Addr> | The address to register the username to (Only available to the kernel). |
RegisterUserCrossChain
Registers the username of the sender on another chain.
Registerning a username on another chain needs to be done through the Andromeda chain first. Once the username is registered on the second chain, it is possible to register it to a third chain through Andromeda or the second chain.
For example, if I want to register my username on Juno and then Terra, I would need to call RegisterUserCrossChain message from the Andromeda chain FIRST specifying the chain
field as juno. Once registered on Juno, I can call the message from either Andromeda or Juno to register it on Terra.
This message is currently disabled on mainnet.
Name | Type | Description |
---|---|---|
| String | The name of the chain you want to register the username on. |
| String | The address on the specified |
RegisterLibrary
Registers a library address under a library name. Libraries will be set up by Andromeda, and will contain a group of paths that resolve to addresses that can be used by users to create Apps. Users can use the SubDir query to get all the directories that are saved under the library name.
This message cannot be called by a user.
Name | Type | Description |
---|---|---|
| String | The name of the library. |
| Addr | The address of the library. |
AddChild
Registers the child's path relative to the parent.
Cannot be called by a user.
When Andromeda Apps are instantiated, it is automatically called, registering the App as a child to the sender's username and each of the components as children of the App itself similar to what we saw in the example above.
Name | Type | Description |
---|---|---|
| String | The name to assign. |
| The address of the parent ADO. |
Ownership
The set of ownerhsip messages. These messages are the same as the ones found in the ADO base section.
QueryMsg
ResolvePath
Gets the address of the specified path.
Name | Type | Description |
---|---|---|
| The path to get the address for. |
Returns the address of of the path. In the above JSON example, the address of ado2 would be returned.
SubDir
Gets all the paths under the specified directory. Min and max can be used for pagination.
Name | Type | Description |
---|---|---|
| The path to get all sub directories for. | |
| Option<SubDirBound> | The key to start from. Used for pagination. |
| Option<SubDirBound> | The maximum key to return. Used for pagination. |
| Option<u32> | The number of paths to be returned. Defaults to 50 if not set. Can be set to a maximum of 100. |
PathDetails
Returns the path name and corresponding address for each subdirectory path.
Paths
Gets all the paths that resolve to the specified address.
Name | Type | Description |
---|---|---|
| Addr | The address to get the paths for. |
GetUsername
Gets the registered username of the specified address.
Name | Type | Description |
---|---|---|
| Addr | The address to get the username for. |
GetLibrary
Gets the library name of the specified library address.
Name | Type | Description |
---|---|---|
| Addr | The address of the library to get the name for. |
ResolveSymlink
Returns the path that the specified symlink points to.
Name | Type | Description |
---|---|---|
| The path of the symlink to resolve. |
Version
Queries the version of the ADO.
VersionResponse
Name | Type | Descripton |
---|---|---|
| String | The version of the ADO. |
Owner
Queries the owner of the contract.
ContractOwnerResponse
Type
Queries the ADO type.
TypeResponse
Name | Type | Description |
---|---|---|
| String | The type of the ado. |
KernelAddress
Queries the kernel address of the chain the ADO is deployed on.
Returns a String containing the contract address of the Kernel.
Last updated