Packet

A web3-enabled content distribution ecosystem built to replace email.

Comment

Link to LitePaper

Note on the deployed Vercel app: The public signalling servers can be very slow to connect peers! Although this is available, I recommend trying out the app with a local signalling server, as described in the Github Repo

Motivation

What has email become?

Email was meant to be a way of peer-to-peer communication, but it has become a dumping ground for marketing content, random distractions, and a few (actually important) messages. We don’t check email to do a specific task. Instead, our minds have to constantly context switch between work, personal, and marketing-related emails. There have been numerous attempts to introduce clarity and focus into email, but these services are all attempting to build upon a broken system.

Email is a suitable platform for long-form asynchronous communication, but it's not built to distribute content such as newsletters and marketing material.

What has content publication become?

Each platform, whether it be Reddit, Medium, or CNN, has its own private repository of user data and its own recommendation engine. Content publishing has largely become centralized to a few dominant entities, each with their own private biases and political agendas.

With the budding popularity of independent journalism and the growth of more “decentralized” platforms such as Substack, content publication is a field poised for change.

Email is for peer-to-peer communication. ??? is for content delivery.

Let’s leverage web 3.0 to fill in the blank.

The Ecosystem

Packet: The Open Content Protocol

Packet is the open-source protocol for the future of content publishing and subscription. The protocol is based on the decentralized nature of IPFS:

  • Content creators publish content to a feed identified by a public address. In our use-case, this feed is an OrbitDB address hash
  • Subscribers maintain a list of feed addresses, and can pull updated data through IPFS
  • The protocol would define schemas for each content feed, as well as the expected storage of content feed metadata (for example, the use of a OrbitDB key-value store).

Packet Registry: The Publication Platform

Registry is a suite of tools to help content publishers create content and manage their own feed, this can include:

  • Tools to maintain access control to their unique feed (for example, authentication using a Ethereum account)
  • Tools to manage metadata for their feed
  • Tools to create and distribute content according to the Packet schema

Packet Intake: The Email Packet Client

Intake is the client “reader app” that enables users to:

  • Easily subscribe to content feeds
  • Customize and maintain the categorization (ex. Marketing vs informational) and polling frequency (ex. Constant polling vs. on-request) of different feeds
  • Browse and discover feeds relevant to their preferences

The Demo App

The demo application is a fully-decentralized implementation of Packet. We leverage OrbitDB, a distributed P2P database built on IPFS, for the storage and distribution of content. The demo application has implementations for both Packet Registry (the publishing dashboard) and Packet Intake (the web reader app). We experimented with an initial version of the Packet protocol, whereby the schema for a single Feed is as follows:

The Feed “Metadata” Key Value Store - This contains metadata on the feed itself

{
  "name": "Name of the feed",
  "iconUri": "Optional URI to an icon asset",
  "postsDbAddress": "Full OrbitDB address of the posts databases"
}

The Posts FeedStore - This contains a feed-log of all the published posts, each having:

{
  "title": "Title of the post",
  "content": "String content of the post",
  "createdAt": "ISO date of creation"
}

In the future, we can extend support for different content types by allowing an object value for the content field:

{
  "type": "Type of the content - likely an enum, such as TEXT/URI/MARKDOWN - similar to mime types
  "value": "The appropriate value given type - for example, if type: URI, then value: some_url_or_cid"
}

To enable access control on feeds, such as only the publisher has write access, we utilize OrbitDB identities and access control with Ethereum accounts. Currently, a web3 wallet (ex. Metamask) is required to grant publisher-only write access to created feeds. This is so that we can use Ethereum-based authentication to prevent public writes. In the future, we can extend this functionality by enabling support for decentralized identifiers (DID) and other identification methods.

The OrbitDB instance is backed by a browser-based IPFS node. For browser-to-browser communication to occur, we leverage a signalling server enabled by libp2p-webrtc-star (a libp2p package) either hosted locally or by Protocol Labs. We also needed to enable pubsub for IPFS to work across browsers. The web-app itself is a Next.js project, though the client-only nature of a distributed app means that we do not need to leverage much of the server-side functionality that Next.js offers.

Opportunities for Further Implementation

We have a few additional opportunities to leverage the power of IPFS and OrbitDB. Namely:

  • Pinning data on persistent nodes as opposed to relying on brower-to-browser replication, which can be slow
  • Additional integration with identity providers
  • Enabling automatic backups & pinning of OrbitDB data

What’s Next?

As mentioned in the Litepaper, fully-decentralized solutions have significant shortcomings that impact Most relevant to the Packet use-case is the lack of mobile support and the significant lag between replication times (though this can be mitigated by persistent nodes that store and serve published content). Our next steps are to identify areas where we can leverage more centralized solutions to enable a user experience on par with current products. After this exploration, we hope to begin implementing our first production-ready version of Packet Registry and Intake. Registry will initially be only available as a web-app, but Intake will have a focus on a mobile-friendly user experience (including support for native mobile apps). Our plan for marketing and user acquisition is introduced in more detail within the Litepaper.

Built With

  • ipfs
  • next.js
  • orbitdb
Share this project:

Updates