¡Mi CASA es su CASA on the WWL!

This article is a high-level architecture outline for a CryptoAnarchy Social Aggregator immune to unilateral censorship while still supporting volunteer content curation/moderation.

Making transparency an inseparable aspect of the moderation system avoids the hazards of idelogically motivated content suppression that have subervted the authenticity of existing aggregators.

User Experience

The primary UX should be a web client that functions in major modern browsers with no installation requirement. Not all clients need to follow this model, but we should focus on this approach first as it will likely make up the bulk of network participation.

Yes I know Javascript Cryptography is considered harmful.  But I still think this is a worthwhile approach.  The main browsers we want to target will support the Web Crypto API.  More paranoid users can use more secure clients.  But the lurkers are critical to the success of an aggregator and a web client is essential for this demographic.

Which Blockchain?

This is beyond the scope of this article as I will be discussing things in very high level, generic terms. We will be using the blockchain to store voting/reputation data and index content.  The blockchain will track content metadata; not store the content.

I don’t think Bitcoin itself is appropriate due to transaction minimums and fee costs. My current thoughts are leaning towards reddcoin.

Core Data Structures

Thing

Every thing is identified by a unique pubkey/address.

Clients that contribute a thing are responsible for storing the privkey.

The data for a thing is an arbitrary JSON data blob signed by this key.

Instead of down voting there will be blockchain value burns against a deterministic address associated with the address of the thing.

The score of a thing is based on blockchain value minus burn value. In this way the blockchain manages tracking karma/reputation/internet points.  Yes this means voting/karma is a scarce resource.

Ideally both things and listing should also function with m-of-n keys/addresses in addition to standard pub/priv keys.

Listing

Listings are Things that track a collection of other things.

The client will facilitate the composition and sorting of listings based on age and blockchain value.

How these listings are stored will be determined by how we approach Content Propagation.  It may be possible to store listing data on the blockchain.

It should not be possible for anyone to remove a thing from a listing.

Extended Data Structures

These are Things and Listings given extra meaning by client convention.

Handle

A handle represents a less anonymous individual within the WWL.

It includes a human readable (nick)name and optional data about associated links, comments and collectives. Possibly some sort of profile/external contact data as well.

Comment

A comment has a body of text and an optional parent thing. It may be associated with a handle. Comments should support optional cryptographic signatures. The OP of a Thing could comment on that thread and prove their identity as the OP by signing comments with the Thing’s key.

Collective

A collective represents a collection of things within the WWL.

Collectives specify multiple listings and the set operations to combine them into a coherent curation.

For example consider a simple Collective which allows anyone to contribute and has two “moderators” Jack and Jill who remove off-topic content.

This is achievable using three Listings

  1. An open access (shared private key) Listing for submissions
  2. A listing owned by Jack that tracks content he deems off topic
  3. A listing owned by Jill that tracks content she deems off topic

The content curation of this community would be defined as:

L1 – (L2 + L3)

Each collective should be able to specify its own listing logic.  A collective does not have to be associated with any Handle.

The moderation listings are necessarily public, but there is no requirement that they be linked with any Handle. Jack and Jill may remain anonymous but their curation will always be transparent.

Additionally, clients may clone/fork the Collective to add/remove Listings to customize the viewing experience for themselves and others.

By labeling Listings and organizing flagged content into those labels it gives readers more control to dictate their own experience. The client should faciliatate this style of category based moderation as much as possible.

Collectives are intentionally generic structures that should be useable to implement many diverse community styles.

Network Topology

CASA requires at least two types of nodes. Rendezvous and Clients.

Rendezvous

Rendezvous are like supernodes in other P2P systems. They serve as a discovery hub for finding other Clients. They may also relay communications between clients via web sockets (until WebRTC support is more widespread).

All communications between clients should use end-to-end encryption making the Rendezvous incapable of determining the contents of messages they relay.

Clients

CASA Clients are the applications that users operate to participate in and observe content on the network. All clients should support storing and hosting content to others through WebRTC and/or a Rendezvous Web Socket.

Content Propagation

This aspect of the network is the biggest missing piece to the puzzle. I have some ideas for approaches here but nothing concrete yet.

While the content will be indexed on a blockchain, the actual Thing data will be stored and hosted by Clients. I see two possible strategies for approaching this.

One option is to make clients unable to identify what content they are hosting and let content that is not accessed fall out of a client’s data store. This is likely possible to achieve with clever cryptography.  This approach is similar to Freenode.

The alternate approach is to give clients control over what it is they host, perhaps choosing to host content (kind of like a retweet) could be a form of upvote that did not require blockchain tokens. We might even find a way to reward clients for hosting well received content.

I am less clear on how to approach this problem and I am collecting my thoughts on the more solid aspects in hope of sparking interest and discussion into how to solve it.

I will take a deeper dive into Content Propagation in a later post.