Ever since covid, a renewed interest in social networks has given rise to new applications with varying levels of decentralization aimed at providing updated or new primitives for social interactions. These designs revolve around the core social media actions: posting, liking, commenting, and following. The existence of these interactions at the protocol level introduce significant design constraints and pigeonhole app developers and users into accepting that all social interactions boil down to posting, liking or commenting. Furthermore, centralization has become public enemy number one for new social networks. Fed up with banning, de-platforming, and algorithm-silencing, many have attributed these actions to the centralization of platforms like Facebook, Twitter, and Instagram.

Surely one more layer of decentralization would fix all of our issues!

We argue that the hidden root cause of this centralization cannot be addressed merely by adding more nodes; instead, it requires focusing on developers, gatekeepers and issuers that inevitably arise on any P2P network. Designing with these parties in mind, as well as abstracting out social interactions from the protocol layer, we can move the social network space into the future, providing organizable, indexable, available, and stackable access to programmable social interactions.

tl;dr: tl;dr

Social Interactions

We should start by defining more expressively the social interactions that exist at today's protocol levels. Take the following well known open-sourced social network protocols. We can observe a pattern of protocol level design prioritizing, defining and developing social interaction standards. This design seems understandable given what we all do on social networks today, however, with the web3 space finally giving us new ways to express human-to-human interactions such as attestations (EAS Docs), SBTs, social financial applications and more. How then do these new primitives gain first-class citizenship in these protocols? What if we simply want to add a voice message option to networks that are treated the same as posts? A protocol that allows for programmable social interactions would encompass all of these use cases, and allow the protocol to be interaction agnostic.

Hidden Centralization

Bear with me; our mental model of programmable social interactions is almost complete but we must understand one more concept. There exists a hidden party in social networks, rarely talked about much less designed around. This party wears many hats, such as a content moderator, badge/accolade attester, NFT issuer, and points awarder. These roles are where the true form of social network centralization creeps into even the best-laid decentralization plans. By controlling off-chain interactions, embed centralization into core of social interactions.

a-ha! So centralization occurs some time during the lifecycle of a social interaction...

Exactly! The crux of a social network being decentralized and credibly neutral does not depend on how many nodes are run or if every message is publicly accessible, it's baked into the design, or lack thereof, social interactions! Recognizing the influence of these hidden parties allows us to redesign social networks by explicity identifying and decentralizing these parties within the core protocol.

Programmable Social Interactions

Let's codify this revelation and introduce a new definition of social interactions. We identify these parties on our network as the Client (some refer to them as an issuer), let us look at two examples of Developers.

In the two examples, we need to trust the project awarding points as well as the event host/doorman to accurately represent the accolade, after all that POAP/airdrop hunting may lead to a 100$ onchain airdrop! Now verifiability within these two examples exist on a wide spectrum, POAPs would require a neutral party to audit real time or even a DePin project attesting physical locations. The L2 example can more easily be recorded as transaction hashes exist, but then sybil attacks are a whole other issue.

Recognizing this large landscape of off-chain trust we cannot define a protocol to handle every edge case. Instead we propose two enhancements, (1) a expressive and stackable way for projects to define their programs, and (2) an optimistic path to onchain record keeping, with a dispute mechanism to ensure open and effective reputation managing.

What this looks like in the L2 example is a project lead would use an open standard (will touch more on this later) for points attesting and attest onchain a user actions and points value. If malfeasance is detected in this process, anyone can dispute the interaction. This dispute is recorded in the protocol, and allows for a resolution process to take place. Reputation can begin to take form and centralized actors now have accountability. Importantly, the protocol only keeps track of the open standards (Stackable) as well as the disputes (Disputable) and ensure the data is available, it makes no assumption of the individual projects/actors.

Stackable

To manage this wide landscape of off-chain trust we define a way for Developers to create what we call, Interaction Types. These sets can be thought of similar to Ethereum EIPs, such as ERC-721 on which other projects can reference and build on. These Interaction Types define in simple terms, how it should be used and what fields are specifically required or optional in a JSON structured object.

For example:

Let's say we have a Points Interaction defined as:

{
  "summary": "Issuers must have the below contents defined for each interaction to be correctly recorded.",
  "contents": {
    "to": "<recipient of points address>",
    "amount": "<numeric amount of points>",
    "reason": "<reason the points were given>"
  }
}

Now a new project wants to award points and would like other projects on the network to seamlessly pickup their points. They can reference this Points interaction types and even add their own flair.

{
  ...points interaction items
  "pudgyholder": "true",
  "passedKYC": "true"
}

Now the protocol becomes a set of open and buildable standards for defining complex social interactions. This presents a level up from posts/likes/comments, and balances off-chain and onchain ecosystems as projects can define their own interactions and users can make informed decisions while knowing the Client's interaction explicitly.

Disputable

Since this information is optimistically provided onchain, we are able to more clearly express what trust looks like in a social setting. The two expressions are (1) truth that the developer followed the interaction they defined and (2) truth that the data is accurately recorded. The first truth can be checked by off-chain verifiers for formatting but there is little incentive to use the incorrect format as the rest of the protocol would not be able to use the data points presented. The second truth is much more difficult to verifiably prove, which is why we allow for optimistic interactions while providing a dispute mechanism anyone can use to dispute claims made by a certain Client. We believe these two additions give the network enough data points to being to form a reputation layer, without burdening the protocol layer.

So wait, did you just define attestations? Maybe...yes, but for good reason! We must throw out our preconceived notations about what a social network is and work to marry social network design with the idea of attestations to achieve any level of forward progress past post/like/comments. If we abstract out social interactions from the core protocol, what then should the protocol do? We argue the protocol should be intrusted to ensure the interaction types, interactions themselves and disputes are organized, indexable and available.

Simply put, developers and users record interaction types, interactions and disputes to a smart contract registry (organized) residing on an EVM compatible blockchain indexed by their identity (indexable) and pinned on a decentralized network of nodes tasked with keeping the data available. We argue, this pattern is what should define value in a social network.

Conclusion

The stack outlined in this article, allows for minimal social consensus on the protocol layer by giving developers the flexibility to craft, design and build upon others social interactions. We turn the focus on the protocol team to ensure these interactions are organized, indexable and available. While we did not touch on this during the article, a direct line can be drawn from social interactions being organized and indexed onchain and participation in a vibrant EVM ecosystem unlocking new onchain social applications. Join us in crafting new social interactions!

tl;dr

stackable, disputable, typed off-chain attestations - made available onchain.

Ecosystem:

• Protocol: Concerned with organized, indexable and available data
• Developers: Concerned with creating and stacking Interaction Types
• Users: Interacting with Clients (liking, commenting, airdrop hunting, attending events etc.)
• Anyone: disputing developers