Implement pallet_content

Full proposal: https://acuity.network/proposals/1/

Track: SmallSpender
Value: 256 KSM (~4000 USD)

Background

So far Web3 has failed to replace any major Web 2.0 platforms. They continue to become more consolidated, enshittified and homogeneous.

For anyone deeply involved in blockchain technology it is obvious that YouTube, X, Reddit, Wikipedia, GitHub, web forums (like Discourse), RSS and software package managers could all be out-innovated by on-chain alternatives.

They would have the following important properties:

Semantic data as a first class citizen

The Semantic Web has largely failed in its mission. The dream of composability has not happened. I would argue that this is because the semantic data is not a first class citizen on the web. The data is locked away in private databases, only accessible visually via apps, added as an afterthought to HTML, or hidden behind a paywall.

On-chain content publication brings the opportunity for the data itself to be the first class citizen. Instead of every website being a CMS on the periphery of the system, the Web could be replaced by an on-chain CMS.

Unstoppable APIs

Part of the venture capital scam is to start with an open API to build a strong community and then switch it off or put it behind a paywall once the platform is successful. Reddit and X both did this in 2023. You used to be able to choose your app for these platforms. Now you can only use the official apps.

With on-chain publication no one has the authority to disable the API. Anyone can sync the chain from scratch, query the state and index the events. This creates a market incentive to provide easy access to the chain and an index of it.

Permissionless innovation

Every developer is extremely frustrated by the major platforms because they can't improve them. The YouTube dislike count was taken away from us. With on-chain platforms this wouldn't be possible. Developers could innovate both on-chain and off-chain without restriction.

Timestamping

In the age of AI where anything can be faked it is becoming increasingly important to know exactly when something was published. On-chain content is irrevocably timestamped. It is proof of who said what when.

Extremely reliable

Centralized Web 2.0 platforms routinely go offline, both by accident and by design. With on-chain publishing this problem can largely be eliminated.

Choose your own algorithm

These days, everyone is criticising The Algorithm. But what if developers could develop many algorithms and end-users could choose which one they want to use?

Permanent Content

A major problem with the Web is that content is being lost. It is being left up to the Internet Archive to ensure that content remains available, but this is not always successful. Content durability should be built in to the design of the Web, not added as an afterthought. With on-chain publishing and IPFS, anyone can help keep content alive in its original location.

DAOs

Platforms can make decisions through on-chain governance. For example, if every open source software project had its own token, token holders could vote on many issues including when to make a new release.

Content moderation could happen via an on-chain court enforcing the rules in a consistent manner.

Original Implementation

Acuity is an on-chain publishing platform being developed on Polkadot. In its previous incarnation it was called MIX and built on an EVM chain with all of the on-chain logic implemented as Solidity smart contracts. These have been archived into a monorepo. Content was published to IPFS and the content hashes stored in contract state.

Demonstration videos from the original platform:

• overview of the original MIX browser dapp
• publishing images in a feed and commenting
• publishing a video

The purpose of this proposal is to fund the porting of functionality from the MIX smart contracts into a Substrate pallet called pallet_content. This pallet would be available for any Substrate chain to add to their runtime. Later pallet_content could be added to Polkadot SDK.

Content Encoding

It is necessary to have a standardized data format for content stored via the pallet_content. The original MIX implementation used a system of content mixins encoded using Protobuf and compressed with Brotli (2015 blog post explaining why Brotli was chosen).

pallet_content will use a similar system, except it will be compressed with Zstandard as this has now become the de facto industry standard for compressing small files.

Examples of mixins are title, body, date, image, video.

Indexing

Because the IPFS hashes are output as events instead of state to save transaction costs, it is necessary for the dapp to have access to an indexer. This can either be in the form of a centralized backend or federated event indexer like Acuity Index.

Power users can always run their own indexer, but most people will not do this. This creates a market for indexer backends. An indexer can either be hardcoded to work with a specific app, or with standardized indexing, dapps will be able to choose which index to use.

Index providers (being centralised) will be pressured via moral and political means to censor certain results. They will also be pressured to compete with other indexes and self-indexers. This creates a good balance of power.

For example, a university could maintain their own index and block access to "bad" indexes.

Deliverables

The primary deliverable is the porting of the AcuityItemStoreIpfsSha256 Solidity contract to a Substrate pallet called pallet_content.

pallet_content will have the the following features:

Configurable content storage

Each instance of the pallet_content can be configured to store content in a different way. For example, one instance could emit the content directly in the event as a string. Another instance could emit content as an IPFS hash.

Global item_id

When a content item is created a nonce needs to be supplied. The item_id is created by hashing a chain identifier, a pallet instance identifier, address of the content owner, and the nonce. For example, the nonce could be created with BIP32. This means the item_id can be known before the item is created. The pallet ensures that an item_id cannot be reused.

The item_id should generally not be visible to the user.

Configurable items

Content items can have configuration flags set at creation time and optionally changed later by the owner of the item.

Items can be:

• revisionable - new revisions can be published
• retractable - the item can be marked as retracted. Of course, revision history emitted as events cannot be removed.
• parent - items created later can be children of this item
• parent only owner - only the owner of the parent item can create a child item

Revisionable

Each revision of a content item is emitted as an event. A backend or standardised indexer can collate the content revisions for each item.

Composable

A problem with the existing "remark" functionality in Polkadot SDK is that it relies on only storing the content in the source extrinsic. This reduces composability because the indexer has to be maintained to be able to find the extrinsic if it has been generated in a new way, for example as part of another extrinsic.

By emitting an IPFS hash as an event, content can be indexed regardless of how it is generated.

Hierarchical

When an item is created it can be attached to parent items if it has permission. This functionality will be ported from the AcuityItemDag contracts.

This could be used for:

• commenting on another content item
• publishing content in feeds

Only the list of parents is stored on chain. Obtaining a list of children must be done by event indexing. This is because an item can be spammed with children and the indexer can use other criteria to filter the results.

Unit tests

pallet_content will have complete test coverage.

Example dapp

A dapp will be created to demonstrate how content_pallet can be used be build a fully decentralized social media platform.

Additionally, a screencast will be recorded to demonstrate the dapp.

Future Deliverables

Outside the scope of this proposal the goal is for pallet_content to become part of Polkadot SDK and integrate with other pallets such as Referendum.

Currently Polkadot governance portals such as Polkassembly and Subsquare have centralized referendum discussion functionality beyond what is provided on-chain. This leads to issues such as the need for comment synchronization between these two platforms.

This functionality really needs to be on-chain. This is what pallet_content can provide.

Benefit to Kusama Ecosystem

How will pallet_content benefit Kusama?

Every chain needs to publish content of one kind or another. For example, a prediction market chain needs to be able to publish what it is that is being predicted.

Once pallet_content exists it will be possible to create dedicated "content parachains" that use Kusama as their relay chain. For example:

• Feeds parachain - replace X, YouTube, RSS
• Topics parachain - replace Reddit
• Forums parachain - replace Discourse
• Wiki parachain - replace Wikipedia

Point of Contact

• name: Jonathan Brown (author of the original MIX contracts and frontend)
• email: jbrown@acuity.network
• Telegram: ethernomad
• GitHub: ethernomad
• X: bluedroplet

Jonathan has been previously funded by two (1, 2) Web3 Foundation grants and a Kusama Treasury referenda.

Timeline

The deliverables will be completed by the end of October 2025.