Tech BlogShowcase
Twitter Clone Owned by Users

Twitter Clone Owned by Users

Twitter Clone Owned by Users

Build a user-owned Twitter where you control your own feed.

Overview

It might be much easier than you would first guess

  1. Build an app where a user’s identity is their .eth domain (or pub address if lacking). See withBackdrop for example.
  2. When a user logs into the app, it would look into a dapp table (e.g. the developer table for the dapp) for that users address and link to the user owned table. i.e. rows in dev table look like pub address: owned tweets table, owned following table
  3. Owned table conforms to my schema. e.g. id, text, reply_to, etc, etc.
  4. They also must own a table that conforms to a schema for following. e.g. follow_addr, name, follow owned tweet table. name could just be an optional nickname that you self assign people you follow if you like
  5. When you load the app, it loads up all the followers from table in 3, it loads up all those owner's tables from 2 and compiles a tweet feed.

If said owner now wants to tweet their own, they just write to their own table.

Not the most elegant thing compared to a centralized DB, but pretty sweet you could build it so simply as a starting point. We wouldn’t recommend taking the exact configuration above to a production example, but it’s a great starting point to learn!

Result

You’d see the world from your own small view. also cool is you could load the world from other people’s pov (for example, I could embed my view of the twitter clone world into my homepage)

Technical details

  1. Signup
    1. Create a dApp that prompts users to log in using Metamask.
    2. When the user logs in, create two tables that will be owned by the user.
      • Table 1 with schema: `post:text, parent_id:text`.
      • Table 2 with schema: `following_addr: text, posts_table: text`
    3. The dapp should keep a developer owned (backend controlled) table for tracking: user_addr, user_table1_id, user_table2_id
      1. A user doesn’t have to be in this table to use the app ^. they may be able to store similar index information, for example, in their ens domain entry.
  2. Give the user a landing page that displays their Table 1 content as a feed of posts. e.g. `localhost/users-eth-addr...`
  3. Add a `follow` button on the landing page for any user when the page doesn't match the id of the currently logged-in user. The dapp will need to know the Table 1 and Table 2 addrs of users-eth-addr... owner in 1.
  4. When a user hits, follow, prompt them to insert into their own Table 2 the page's user addr plus the page's user addr's table 1 id.
  5. When a user goes to their own landing page on 1, do a query for the posts in Table 1, plus lookup each table in the second column of Table 2 and give an ordered list of all posts. This is their feed.

Resources

← Previous

Use Cases