We have been hard at work the past few weeks piecing together the dSocial smart contract. While in its infancy, it showcases the database schemas and actions that dSocial’s frontend data handlers and services will interface with when adding, modifying, deleting, and querying data on ARISEN. There will be many changes to this contract, but it should be easy for any C++ developer to understand. I wanted to breakdown the contract, as well as a few important details regarding the ARISEN blockchain and ARISEN-based smart contracts.
NOTE: You can check out the contract for yourself at https://github.com/getdsocial/dsocial-contracts
<h2>ARISEN Basics</h2>
- Actions require authentication, so you will notice that actions within this contract require the content’s creator to identify themselves and sign for the execution of any action within this contract. This ensures that only the users themselves control their data and that only the data’s author can modify or remove their data from the blockchain. The contract uses ARISEN’s built in require auth() method to handle this.
- Actions that are adding new data to the database utilize the emplace() constructor, data that is being modified uses the modify() constructor and data that is being erased uses the erase() constructor. You will see these constructors frequently in our contract, depending on whether the action is being used to create, modify or delete data. Each of these constructors can be used within your contracts, by simply including the standard ARISEN library (arisen/arisen.hpp).
<h2>Database Schemas</h2>
The following database schemas are utilized by actions across the contract itself.
<h3>postx</h3>
The “postx” schema, is the schema used by the “post” action. Action-related data is ultimately stored in the “posttbl” on-chain database table. The following data is found within the schema:
- uuid — Unique UUID for the post itself, which is generated by the contract.
- poster — The PeepsID of the poster.
- data — Post data, which is limited to 140 characters.
- drive — A dWeb network address of the dDrive that contains the post media (photos, videos and audio).
- timestamp — A timestamp of when the post is created or modified. Generated by the contract.
<h4>postx Indices</h4>
- The primary key for the table is “uuid”
- You can also retrieve posts, by user, using the get post by user indice.
<h3>commentx</h3>
The “commentx” schema, is the schema used by the “comment”, “modcomment” and “uncomment” actions. Action-related data is ultimately stored in the “commenttbl” on-chain database table. The following data is found within the schema:
- comment_uuid — Unique UUID for the comment itself, which is generated by the contract.
- commenter — The PeepsID of the commenter.
- post_uuid — Post UUID the comment belongs to (from posttbl).
- data — Comment data, which is limited to 140 characters.
- drive — A dWeb network address of the dDrive that contains the comment media (photos, videos and audio).
- timestamp — A timestamp of when the post is created or modified. Generated by the contract.
<h4>commentx Indices</h4>
- The primary key for the table is “comment_uuid”
- Other indices include “post_uuid” and “commenter”, so that comments can be retrieved by a comment’s UUID or by commenter.
<h3>lovex</h3>
The “lovex” schema, is the schema used by the “love” and “unlove” actions. Action-related data is ultimately stored in the “lovetbl” on-chain database table. The following data is found within the schema:
- lover — The PeepsID of the lover.
- uuid_pointer — Reference to the post or the comment being loved.
- is_post — A boolean of whether or not this love is related to a post (true if it’s a post).
<h4>lovex Indices</h4>
- The primary key for the table is “lover”
- You can also retrieve posts and comments by post or comment UUID using “uuid_pointer”.
<h3>userx</h3>
The “userx” schema, is the schema used by the “pdata”, “updatename”, “updatebio”, “updatelocation” and “updateurl” actions and is also used by other actions to verify whether or not a user is active on the network. Action-related data is ultimately stored in the “usertbl” on-chain database table. The following data is found within the schema:
- user — The PeepsID of the user.
- display_name — The displayed name on the user’s profile.
- url — The displayed URL on the user’s profile.
- bio — The displayed bio on the user’s profile.
- location — The displayed location on the user’s profile.
<h4>userx Indices</h4>
- The primary key for the table is “user”
- You can also search the user table by bio or location data (“bio” and “location”).
<h3>repostx</h3>
The “repostx” schema, is the schema used by the “repost” and “unrepost” actions. Action-related data is ultimately stored in the “reposttbl” on-chain database table. The following data is found within the schema:
- reposter — The PeepsID of the user reposting.
- post_uuid — The UUID of the post being reposted.
- timestamp — The timestamp of the repost. Generated by the contract.
<h4>repostx Indices</h4>
- The primary key for the table is “post_uuid”
- You can also search the repost table by “reposter”.
<h3>favoritex</h3>
The “favoritex” schema, is the schema used by the “favorite” and “unfavorite” actions. Action-related data is ultimately stored in the “favoritetbl” on-chain database table. The following data is found within the schema:
- uuid — The UUID of the favorite.
- post_uuid — The UUID of the post being favored.
- timestamp — The timestamp of the favorite. Generated by the contract.
<h4>favoritex Indices</h4>
- The primary key for the table is “uuid”.
- You can also search the favorites table by “post_uuid”.
<h3>upvotex</h3>
The “upvotex” schema is the schema used by the “upvote” action. Action-related data is ultimately stored in the “upvotetbl” on-chain database table. The following data is found within the schema:
- uuid — The UUID of the upvote itself.
- content_uuid — The content_uuid (post or comment) the upvote is for.
- from — The PeepsID the upvote is from.
- to — The PeepsID the upvote is for.
- payment_total — The total upvote amount in RIX. Payment is handled by the contract.
- timestamp — The timestamp of the upvote. Generated by the contract.
<h4>upvotex Indices</h4>
- The primary key for the table is “uuid”
- You can also search the upvotes table by “from” (upvoter) and “to” (receiver).
<h3>pinx</h3>
The “pinx” schema is the schema used by the “pin” and “unpin” actions. Action-related data is ultimately stored in the “pintbl” on-chain database table. The following data is found within the schema:
- pinner — The PeepsID of the user creating the pin
- content_uuid — The UUID of the post being pinned
- timestamp — The timestamp of the pin. Generated by the contract.
<h4>pinx Indices</h4>
- The primary key for the table is “pinner”.
<h3>hiddenx</h3>
The “hiddenx” schema is the schema used by the “hide” and “unhide” actions. Action-related data is ultimately stored in the “hidetbl” on-chain database table. The following data is found within the schema:
- hider — The PeepsID of the user hiding the post or comment.
- content_uuid — The post or comment UUID, related to the post or comment being hidden.
- timestamp — The timestamp of when the post or comment was hidden. Generated by the contract.
<h4>hiddenx Indices</h4>
- The primary key for the table is “content_uuid”.
<h3>followx</h3>
The “followx” schema is the schema used by the “follow” and “unfollow” actions. Action-related data is ultimately stored in the “followtbl” on-chain database table. The table is scoped to each “follower”, so that a user can only follow a single user once, since the user they’re following is used as the primary key in the scoped table. The following data is found within the schema:
- follower — The PeepsID of the user initiating the follow action.
- following — The PeepsID of the user being followed.
<h4>followx Indices</h4>
- The primary key for the table is “following”
- You can also search the follow table by a user’s followers (“follower”).
<h3>blockx</h3>
The “blockx” schema is the schema used by the “block” and “unblock” actions. Action-related data is ultimately stored in the “blocktbl” on-chain database table. The table is scoped to the “blocker” and uses the blocked users as the primary keys within the scoped table, so that a blocker can only block another user once. The following data is found within the schema:
- blocker — The PeepsID of the user initiating the block action
- blocked — The PeepsID of the user being blocked by the blocker
<h4>blockx Indices</h4>
- The primary key for the table is “blocked”.
- You can also search the block table by blocker (“blocked”).
<h3>pimagex</h3>
The “pimagex” schema is the schema used by the “pimage” action, which is used to add a profile image to a user’s profile. Action-related data is ultimately stored in the “pimagetbl” on-chain database table. The following data is found within the schema:
- uploader — The PeepsID of the user uploading the profile image (the user the profile image belongs to).
- drive — The dWeb network address of the dDrive containing the profile image.
- filename — The filename of the profile image in the dDrive.
<h4>pimagex Indices</h4>
- The primary key for the table is “uploader”.
<h3>statusx</h3>
The “statusx” schema is the schema used by the “activate” and “deactivate” actions, which are used to activate and deactivate profiles on the network. Only the users themselves can initiate these actions on behalf of their own accounts. The following data is found within the schema:
- name — The PeepsID of the user activating their account. When deactivating, this record is removed.
<h4>statusx Indices</h4>
- The primary key for the table is “user”
<h2>Contract-Based Actions</h2>
The following actions are included within the contract and will be utilized by dSocial’s frontend:
- post — Action used to create a post
- modpost — Action used to modify an already existent post
- unpost — Action used to remove an already existent post
- comment — Action used to create a comment
- modcomment — Action used to modify an already existent comment
- uncomment — Action used to remove an already existent comment
- love — Action used to love a post or comment
- unlove — Action used to remove love from a post or comment
- repost — Action used to repost a post
- unrepost — Action used to remove a repost
- favorite — Action used to favorite a post
- unfavorite — Action used to unfavorite a post
- pin — Action used to pin a post to the top of your profile
- unpin — Action used to unpin a post
- follow — Action used to follow another user
- unfollow — Action used to unfollow a user
- block — Action used to block a user
- unblock — Action used to unblock a user
- hide — Action used to hide a post or comment from public view
- unhide — Action used to unhide a post or comment (make it public again)
- pdata — Action used to add user data to the network (display name, bio, url, location, etc.)
- pimage — Action used to add or modify a user’s profile image
- himage — Action used to add or modify a user’s profile header image
- updatename — Action used to update a user’s profile display name
- updatebio — Action used to update a user’s profile bio
- updateurl — Action used to update a user’s profile URL
- updatebio — Action used to update a user’s profile bio
- updatelocation — Action used to update a user’s profile location
- activate — Action used to activate a user’s account on dSocial
- deactivate — Action used to deactivate a user’s account on dSocial
This is just the beginning of course. In the coming days, we will be posting new updates to the contract which will allow upvotes from non-ARISEN currencies like Bitcoin, Ethereum, TRON and EOS. It’s an exciting time!
In the next few days, we are going to debut a few other systems surrounding dSocial’s backend, including contracts for dSocial’s LIKE token (which is distributed freely).
Remember, you can follow along with development on GitHub @getdsocial. While there isn’t much posted yet, there is much more going on behind the scenes than you might think. In the coming days we will debut this contract on ARISEN and will make the first post to dSocial. While there will be no frontend to view it with — it’s a monumental step in our journey.
Stay tuned for more in the coming days, including an update on the development of dSocial’s frontend. I have an important update about the launch of dWeb 3.0 tomorrow as well!
- Jared Rice Sr.
