Associating Assets with Social Interactions
Last updated
Last updated
By combining elements of social interaction with blockchain technology through the use of smart contracts and linked assets, we bring users a new frontier of social exchange where interactions are programmable, automated, and gain added value from linked assets.
Blockchain technology has shown great potential in recording transaction information and exchanging tokenized assets but is limited in its ability to incorporate social interactions. Core human needs behind social interactions, such as identity formation, a sense of belonging, personal reputation, and trust building, are difficult to capture on a transactional-focused platform.
To solve this issue, we present new protocols that bind social elements with interactive assets. This approach increases the value of tokenized assets and attaches a social aspect to an otherwise unsocial arena. As the majority of social interactions take place off-chain, we have developed Social Element Identifiers (SEIs), a method that builds upon Decentralized Identifiers (DIDs) to effectively connect off-chain social activities with on-chain processes.
When users participate in a social interaction that is bound to an interactable asset, they are not only deepening their social connections with the other party but also exchanging and building value. Binding tokenized assets to these social scenarios also gives added significance to the exchange of the assets themselves, opening new possibilities to build a richer and more multi-dimensional digital social ecosystem.
Social Elements
Social elements bound to assets consist mainly of various user-generated content represented by an For a specific definition, please refer to the section entitled .
The Application where a is hosted.
This is the platform where users interact with contracts.
The application can deploy smart contracts and is termed the "Source Platform" of the deployed contract.
A Business Contract "BizContract" (the use of "contracts" and "smart contracts" in this section refers to a BizContract unless otherwise specified) that is generally initiated by the user of an App. The App then deploys a contract that completes that specific logic.
The main content of this protocol describes the rules that a BizContract must abide by and the information that must be submitted by both parties when interacting within an application.
The , a smart contract that authenticates the Source Platform and is generally deployed by an authenticated third party. The Source Platform can use its own name and public key under its domain name. For more details, please refer to .
The Source Platform, which is the application deploying the smart contract.
The Witness Platform, which is the platform to which the social element initiating the social interaction belongs. This could be:
The Source Platform;
Other applications that support this protocol.
When a user interacts with a smart contract within an application, the related social element information needs to be submitted. The contract can choose among different element-asset binding methods according to the specific situation, including storing the social element information directly on the contract, linking to it through calldata, or through real-time event notifications.
The following outlines the key information needed in any interaction:
The contract's initiating party or user, for example, the account who initiates a vote or a donation drive;
The contract participants, for example, the voters or donors;
The social element carrying the contract, for example, a post or message;
When an application initiates a BizContract interaction, that application is responsible for signing the social element and authenticating that the interaction comes from itself.
The BizContract receives the interaction request and the SEI with attached signature, which can be submitted to the Certificate Validator. The contract implementer can decide whether or not to perform signature verification based on their own security needs.
Signature Information and Signature Fields:
SEI
string
Social element SEI Example: sei:clover.space:user:12312313
address
string
The address where the SEI initiates a contract
nonce
int64
Random number
Signature string format: "<SEI>|<address>|<nonce>"
The association of important social elements can be stored directly on the contract itself. Users, voters, or donors can then be linked directly to the contract calldata, which the smart contract can publish to relevant stakeholders when needed.
The following are the additional contract interaction fields that need to be provided by the contract in addition to any asset information:
SEI
string
Social element SEI
nonce
int64
Random number
signature
string
Signed social element Format: "<SEI>|<address>|<nonce>"
Whether the contract needs to undergo signature verification before further action is taken depends on the contract implementer determining if the signature needs to be verified in real-time. If it does not, the contract may instead simply attach the above social interaction information to allow future applications a method of verification.
Once social interactions are bound to assets, it is very important for platforms to create measures to protect user security. It is necessary for applications to provide users with information on these interaction-related contracts and disclose the information within. The following information needs to be provided to users in any social interaction:
Auditable Information
Before users of an application may interact with a contract, smart contracts must follow the smart contract audit protocols and disclose such auditable information. This must include:
The contract's title and description
The contract's auditable information and status
The Source Platform
The source platform is an important factor in ensuring credibility. When a contract is issued on a certain platform, the corresponding platform information must be included:
SEI
string
The social element initiating the interaction
nonce
int64
Random number
signature
string
Signature format:
"<sei>|nonce"
Example: "sei:clover.space:post:1231425|123145561"
This method of disclosure can be stored directly on the contract or with associated data called when deploying the contract.
Licenses
Licenses play a vital role in the exchange of digital content and software. A license sets clear rules and restrictions on the use, distribution, and authorized reproduction of the licensed content. This protects the rights of the original creator and provides necessary guidelines for use by the end user.
When a contract is issued, the license of the issuing platform may be displayed to prevent unauthorized use of the content.
Licenses can be stored on-chain
license
String
License name
allow
[]string
List of permissions:
If it does not exist, it means the contract is being initiated from the Source Platform
If unrestricted, use ["*"]
If restricted, allowed platform names can be listed
Information on User Reports
Methods of Reporting: On social platforms with a high level of user interaction, maintaining a safe and friendly environment is crucial. To maintain such an environment, contract publishers need to be proactive in providing an easy-to-use reporting mechanism that enables regular users to report inappropriate content, fraudulent behavior, or other activity that violates community guidelines. This not only protects the rights and interests of users but also lends credibility to the platform.
Disclosing Reported Information: Warning users that their content or behavior has been reported is a key factor in maintaining safety and transparency. This practice helps users reflect on their violations and modify behaviors that violate community guidelines, ensuring justice and fairness when it allows for appeals of specific violations.
Local Blacklist: The platform should maintain a local blacklist of reported users or publishers.
Global Blacklist: Reported information may be shared to a global blacklist, and problematic users or content can be checked against the global blacklist.
The disclosure method of reports can be provided by the platform through a contract, which can be updated in real-time. Any modifications should notify all parties.
flagged
boolean
Report Status
False: Not reported
True: Has been reported
hitLocalBlacklist
boolean
False: Not on list
True: On list
hitGlobalBlacklist
boolean
False: Not on list
True: On list
Web3 protocols unlock the ability to share assets across platforms, and the binding of social elements with tokenized assets brings about a need for cross-platform social element protocols. Not all implementations of our social digital asset protocols may be used by every application, nor may every possible social element be usable across platforms, so it is valuable to make some social elements, like interest tags, explicitly cross-platform compatible.
Interest tags play a crucial role in social interactions as they serve as a key descriptor of user preferences and personality and facilitate connections and interactions between users. Interest tags provide the platform with the opportunity to recommend content or other users that may be of interest to that user and give individual users the ability to discover content similar to their interests. However, the current tagging systems lack uniformity across different platforms, which hinders users' cross-platform interaction and the efficiency of content discovery.
Implementing a universal cross-platform interest tag protocol solves this problem. This protocol accelerates users' social activity based around these interests and improves the interoperability between platforms, enabling users to discover their interests without being restricted by platform boundaries and thus more quickly find content and communities that match their interests.
This universal tagging protocol also aids the platform or application. By adopting a common tagging system, each platform can organize, aggregate, and recommend content more effectively, promoting communication and interaction between users. This helps improve user satisfaction and engagement and gives the platform more precise advertising, brand positioning, or marketing strategies and opportunities.
To provide users with a complete view of the asset binding protocol, it is important to implement a service that integrates blockchain information and social element information.
Monitoring element-asset bound contract events and reading contract information.
Analyzing a platform's social interaction information and displaying it in a viewable medium.
Providing retrieval services to users and platforms, allowing the input of a contract address to output the contract's social information.
User Homepage Donation/Tipping Portal
User Homepage Membership / Paid Content Portal
Vote, Survey, Betting, Airdrop, Token Minting, etc. Within Posts
Competitions with Live Streams
Leaderboards
Staked Assets within a Chatroom (Friendship Levels, etc.)
Chatroom Games
Chat Message Voting
Paid Organization Memberships
Staked Assets in an Organization
On-chain Social Milestone Markers
All social elements are expressed through an SEI. To prevent malicious binding, the application where the social element is located needs to sign the contract during the interaction. The signer can be the platform where the contract is deployed (see "" for details) or a clearly specified, licensed platform at the time the contract is deployed. (See "" for details.)
For more details, please refer to
Please see for more details.
The main functions of are: