As part of implementation of our vision for Ethora social wallet & metaverse platform, we are proceeding with an important update.
This update means we will finally roll out the decentralized Rooms Contract – a smart contract / dApp allowing users to create their own Rooms and connect them among each other.
Further implementation details below.
This implements three important aspects finalizing the planned transition of Ethora into a web3 metaverse platform:
- Rooms (Spaces) can be created and managed by Users and entities in a decentralized way.
- Rooms can connect to each other so that Users can easily travel to neighbouring rooms. These connections are managed in a decentralized way.
- Users can travel between rooms. Users can be properly “Present” only in on Room at a time.
- contractOwners – contract owner ETH address
- contractAdmins – contract admins ETH addresses
- roomCreateFee – how many Coins required to create a Room
- linkFee – how many Coins required to update a link in a Room where you’re Owner or Admin
- address – a unique address (such as ETH public key or similar) to uniquely identify the room. Note: it will be beneficial if the room can have its own ETH wallet, or its wallet can be managed by the main dRooms contract.
- owners – (at least one) – ETH addresses who can manage all Room attributes including changing the Owners. They can also withdraw funds and assets from their Rooms.
- admins – (optional) – ETH addresses assigned by an Owner who can manage all Room attributes except changing the Owners or Admins and except withdrawing any funds or assets from the Room
- image – (static) – IPFS image for the room
- background – (static) – IPFS image for room background
- stream – link for audio or video stream for the room background
- links – connections to neighbouring rooms (see below)
Rooms may be able to receive or earn funds in Ethora Coin and ETH.
We should implement methods allowing to (1) transfer Ethora Coins and ETH to the room contract specifying a specific Room; (2) for Room Owners to withdraw such funds.
We also want to have methods allowing to store and withdraw other types of tokens / Items inside the Rooms, such as NFT Items.
Initially it is proposed simply to implement a way for any User who is present in the Room to drop an Item there and for any other User who is present in the room to collect any Item. In future this may be extended with advanced mechanics.
This is a User related attribute, not a Room attribute.
For each User our contract and our caching layer track where they currently are.
This is for:
- Remembering where user has left the system in case the client app cache is reset
- Various metaverse, gamification and business logic mechanics. For example, users located in certain room can enjoy certain benefits, Items drops, access to certain features or information. Bots and room can interact with Users who are present in a specific location.
proposed data structure:
This function should be called by a User (a client app on behalf of the User) and allows the User to change their Presence to another Room.
If successful, the act of travel should also emit a message for the Room that User has left and for the Room that User has joined
These messages are communicated via VM ‘emit’ by the smart contract and/or messaging protocol (XMPP) messages by the client app.
E.g. (as seen by other users):
User leaving room:
< user name > has left ->
the arrow here symbolizes the direction where User has gone. This allows other users to follow in case our User has travelled into a neighbouring (linked) Room. In case User has left via a portal (QR code) there will be no direction or link in the message to preserve confidentiality of any invite-only Rooms.
User entering room:
< user name > has entered.
Client implementation notes:
- Underscore the user name and allow to tap on it as a link opening the joined / left User’s profile.
- In case many users have left or joined the room simultaneously (within 15 seconds), group them to avoid overloading the chat. For example, “< user name 1>, < user name 2 >, <user name 3> and 45 other users have entered”.
LINKS (and “compass navigation”)
Links are essential for the crowd-sourced Metaverse building. Rooms are building blocks and Links connect them together.
Room owners / admins can set a limited number of links to other Rooms.
In the client application, Users can easily navigate to ‘nearby’ Rooms (for example, go West via swipe right action, go East via swipe left etc).
Links structure for current phase (stored as a mutable attribute for each room):
Links data structure:
originRoomAddress, linkType [‘W’, ‘E’, ’N’, ’S’]), destinationRoomAddress
E.g. array stored inside smart contract for connecting room1 to other rooms.
In future phases we may add Up / Down etc links.
Owners / admins can update Links for which they need to pay a Coin fee.
In case Link is empty, the Client app will lead to a default room in the navigation there.
Owner/admin of the originRoom should execute the following function along with sending a correct Fee in Coin:
linkUpdate(originRoomAddress, linkType [‘W’, ‘E’, ’N’, ’S’]), destinationRoomAddress)
- Rooms can link differently. This means if a User travels ‘East’ and then travels ‘West’ immediately, there is no guarantee they end up in the same room. This is fine. We may establish a mutually binding linking mechanism in future updates.
- Client app should retain the “Back” navigation allowing User to come back to the previous Room visited without using the “compass” navigation
- In case a room doesn’t have some link created yet, we navigate users to Default Room (“Agora”)