Communities and Lists
Background
A couple months ago Billy mentioned to me that smart contract auditors could be a good demographic to market my Hive Mind products to, especially considering the extension and Snaps can get Intuition claims in front of end-users as they browse normally. This got me thinking about how Hive Mind could be used by community leaders to protect their communities. The structure would look something like this:
- Community leaders recruit curators to make claims about web properties (smart contracts, social media accounts, and websites) their members are likely to visit while browsing.
- Curators make said claims
- Community leaders and curators then encourage their members to install Hive Mind to get those claims presented to them while browsing
As a network graph it’s already clear that Intuition activity bunches up into clusters that represent different communities. For example a DeFi trader will interact with many of the same web properties as another DeFi trader or analyst, but will likely have very different browsing activity from a Bitcoin enthusiast or someone with non-web3 interests like video games or music.
Why Create a Community on Intuition?
Experts have a general idea of which online entities to trust vs avoid, and are eager to convey this information to their community. Hive Mind is specifically targeting the following mediums to distribute these insights:
- Lists of EVM accounts worth following on Intuition
- Lists of social media accounts to follow
- List of webpages to bookmark
Note that 2 and 3 are much more useful when the curators from 1 have made claims about them, so having them in list form also gives curators a list of relevant items to make claims about.
Organizing Communities and Lists
This begs the question of exactly how a user would discern which community a list is for. There needs to be a way to query Intuition to get this information. Previously, I have expected community leaders and curators to tag relevant atoms with a topic atom like [some website] - has tag - DeFi but without a strong reason to browse a community there is little incentive to do this tagging.
Lists provide a structured, and fun, way to present opinions to a community and bootstrap it. Instead of needing to tag relevant atoms for a community we can let users make lists of relevant atoms, something they like doing naturally, and connect the community / topic to the atoms through the list with one tag like NFT Useful Links - has tag - NFT or Intuition Accounts to Follow - has tag - Intuition, etc. Since the list is relevant to the community the individual atoms on the list are also relevant to the community.
Communities
One distinguishing feature of communities is that they are typically held together by a concept: a project, religion, technology, or hobby. Since Intuition has gravitated towards JSON "@type": "Thing"-style atoms for concepts it makes sense to use this convention.
It is also worth mentioning that a community should be easy to find and shareable, which means there should be an easy URL slug for it. I recommend something like the following for a concept with "name": "Hive Mind":
https://explorer.hivemindhq.io/community/hive-mind-abcd1234 where Hive Mind is normalized (eg lowercase, replace spaces with dashes, no special characters, etc) and has the first 8 characters of its atom term ID appended to prevent name collisions with other atoms that have the same label / name.
This means that “community” is more about how a UI displays an atom and the things related to it, than any property on an atom. I am of the opinion that requiring ANY extra steps to creating a community (like creating a specific community atom separate from the concept atom itself) creates unnecessary friction. This also means that dapps can enforce their own criteria before designating any atom as a community. For example:
- Minimum number of lists tagged to the atom
- Minimum stake on the community atom
- Minimum number of atoms related with
[related atom] - has tag - [community atom]
… and so on.
Lists
For Hive Mind’s purposes we need lists that have the following characteristics:
- Easy for an author to organize, and easy to see that user’s version of the list
- Easy for other users to weigh-in (via Intuition claims) on the list
- Easy to share with other users via URL
Reminder: I am not implying that this is the correct way to implement lists, but rather the way we are leaning and a starting point for discussion
Although some lists can be identified by 2 of 3 atoms in a triple, allowing users to compare the third atoms, the lack of a shareable way of identifying these types of lists means they aren’t useful for our purposes.
Ultimately I decided to identify lists through dedicated JSON atoms like the following:
"@context": "https://schema.org",
"@type": "ItemList", // or "Thing"?
"name": "Hive Mind's Useful Links",
"description": "List of sites to bookmark, social media accounts, to follow, and EVM addresses to interact with",
I do not have a strong opinion on using ItemList vs Thing, and am inviting feedback on the pros and cons of each.
A list can be identified via URL much like communities: https://explorer.hivemindhq.io/list/hive-mind-useful-links-abcd1234 where a normalization process is applied to the list’s name and the first ~8 characters of the atom’s term ID is appended
Lists can be “attached” to a community via a predicate like [list] - has tag - [concept atom]. I am open to a dedicated predicate if the community thinks it makes sense.
For organizing the items the Intuition team has recommended using listed in as a predicate:
[list item atom] - listed in - [list atom]
List Functionality
Although we want users to be able to create their own lists, we also want other users to create their own “version” (lens) of the list. We are offering this functionality by letting users “fork” a list. The fork feature simply takes the version of the list the user is viewing and adds the user’s stake (Hive Mind uses minimum stake) to each triple that comprises the list. From this point the user can add, delete, or sort (typically by stake amount) the items on their version of the list. Versions of the list can be specified in a URL via query params like:
https://explorer.hivemindhq.io/list/hive-mind-useful-links-abcd1234?lens=0xcf87e05...
Where the lens parameter points to an EVM address, otherwise the list can default to a global lens or the lens of its creator
In the event that a user wants their VERSION (lens) of the list to be stakeable they can add a simple [address] - curates - [list atom]
Note: I am not covering how to order the list as there are numerous ways to do it and it is outside the scope of this post
Use Cases
Just off the top of my head here are some use cases for communities + lists:
- Lists of official resources for communities (eg Intuition team members’ lens of an “Intuition Resources” list) with users staking and debating which items should be on the list, and in what order. These lists provide curators with a list of highly-visible atoms to make claims about, helping to keep the community safe
- Lists of community members with useful skills
- By tying lists to communities we can display when two communities disagree strongly on a triple
- Community pages where users can see the latest claims, posts, and list movements
By adding communities and lists as primitives in Intuition a lot of features become much easier to implement. I believe that the social aspect of Intuition is a feature that we should be leaning heavily into and I am excited about the extra functionality our dapps will be capable of compared to traditional social media.
What do you guys think?