BlueSky RFC 2 — Architecture: technical and organizational

On December 11, 2019, @jack of Twitter posted a commitment to fund an open source team to decentralize social media. Lots of folks have already been working towards this: @arcalinea wrote an excellent review of the state of the decentralized web in January 2020. I also wrote a backgrounder RFC 1 with sample user stories, outlining the major challenges and my initial evaluation of the existing efforts. Now, I’d like to make an initial proposal how to tackle the problem. Critical comments welcome!

Let’s start with some abstractions.

First off, let’s recognize that some problems require scale to solve well, and some do not. A service to provide a list of the most interesting posts that occurred anywhere in the world in the past five minutes, probably requires a massively connected large data store to solve well. Creating a blacklist of bad actors to exclude, is best done at scale. But an interface to cleverly organize and search only my own personal likes, messages and posts, may actually be better implemented locally. And the ability to send a message from person A to person B anywhere in the world, can be done effectively with decentralized routing.

So here is our first set of abstractions: centralized services, localized applications, and routable hubs. A network with these types of nodes might look like the following:

Several points to note here — we cannot assume that all users of a decentralized social media universe will consume data in the same way. Some may share their data with the providers, others may wish to consume feeds anonymously in the way that DuckDuckGo provides anonymous search. Decentralized protocols should be able to support the use cases of users who wish to consume anonymously, provide their data to the multiverse in exchange for better results, or only directly message/follow trusted individuals.

The key is to efficiently encode the user’s intention.

In the above diagram, the hub-to-hub communication might be over ActivityPub/ActivityStreams; the user-to-user communication might be over SSB (Secure Scuttlebutt); the blacklist/greylist provider might be Matrix. Monetization will likely require a ledger/cryptocurrency system with contracts between the nodes, and additional nodes for advertising and micropayments providers. However, the purpose of this document is to stay at a high level of architecture and process abstraction.

It is likely that extensions to existing usage will be desired, such as the ability to make assertions about an entity for risk/trust purposes (user A asserts that user B is a human, for instance). How to design such assertions will require some experimentation in the real world.

Example extension: Truth, Trust and Back-Propagation

Ideally, we would like to be able to digitally represent connections such as the following:

Having a language in which one can assert, ‘I saw this’, ‘I know this person in the real world’, ‘I trust this person’ (which from a UI perspective might be buttons or checkboxes) offers a much richer signal that models and algorithms can work with.

This brings us to a high-level requirement of a possible protocol — the ability to encapsulate a variety of subprotocols, that may evolve over time; ie it must be extensible. (which both ActivityStreams 2.0 and SSB are). Ideally, the protocol will be able to behave as a living language where a specific usage starts locally and is picked up more widely if it is useful.

In addition, scalability may require that the protocols be compressible, or adaptable to an efficient transport layer; and for broad adoption, may be required to interface with other existing systems. In particular the identity of the poster may be asserted a variety of ways, so one of the extensions may need to address how the message was verified. Further requirements collection is clearly the first step the team will need to perform.

Ability to Deliver

Collecting requirements, while essential, is the easy part.

How will a small team of five people, deliver on a complex, challenging task?

Two possible approaches come to mind:

Option one: define the task in a clearly limited way, of only delivering a set of protocols without attempting to implement the variety of nodes in the ecosystem;

Option two: collaborate broadly with other entities and leverage resources in the open source community to generate momentum for a deeper involvement in the project. Find incentives that motivate involvement.

I am in favor of option two, simply because it is not really possible to know that a set of protocols is sufficient without deep involvement in the ecosystem using them.

Note in the above diagram, that one of the five allocated engineering resources is placed in the ‘newcomers’ cloud. I would propose that this role be designated as a “FrankenRole” with the money distributed via contract work, gitcoin, hackathon prizes and other smaller payments among a larger number of individuals. This will enable a large number of more junior developers who might not qualify for a main role, to participate meaningfully and with compensation. It also will open roles for developers in countries with unreliable internet, or other issues that preclude full time participation.

The hope is that developers will participate for a number of reasons:

• dedication to the concept of a decentralized social network
• for experience and to be part of an exciting project
• for compensation
• for academic credit or publication
• to integrate their existing projects with the decentralized web (partners)

To build momentum, two key factors are required:

Near Term Deliverables

Early wins are critical to building momentum. This is an area where Twitter’s support can be crucial. If Twitter chooses to allow uses of their API that are compatible with one of the components of the architecture, powerful early demonstrations of creative user interfaces or algorithms will be achievable.

Alternatively, simply building on the existing success of Mastodon or manyver.se and filling in some integration gaps may help build momentum. However it will be important not to ‘fall down a rabbit hole’ looking for an early win and fail to generate an extensible, general solution.

Overall Credibility

Credibility of the Bluesky team will be fundamental to its success. Why should existing projects collaborate with this team, and why should users adopt its ideas if it is just another small group vying to be the center of the multiverse?

The work will be Open Source, of course, which is an important step in establishing that the Bluesky team serves the rest of the world and not the other way around. However, a protocol requires adoption and agreement in the way a useful library snippet does not. In particular, the decision making process should be open and inclusive, but recognize work and technical ability; and should have a way to not be bogged down in discussions for too long.

At some level, the problem is a giant prisoner’s dilemma, and the core question is how to structure the ecology so that the cooperators win…

Organizational Structure

Tentatively, I am recommending that the BlueSky team be organized as a Benefit Corporation with a democratic work-weighted vote of confidence in leadership decisions, with veto power by a board of directors (that would presumably include significant Twitter representation). This structure would have some advantages over either a nonprofit or traditional C corporation:

• those working without paid compensation would have some genuine ownership (in the entity, if not the open source code; a la SlicingPie.com)
• the mission could explicitly require a commitment to openness, transparency, that all code produced be open source, or other legally binding priorities
• a benefit corporation structure could allow the bluesky team to fully dogfood the protocol, by also acting as one or more nodes in the decentralized web; and if successful could enable the team to continue after no longer receiving seed funding.
• a democratic vote-of-confidence system allows any of the original team to be removed in an open process, rather than by an appointed board of directors. This provides accountability to the larger community.
• the checks and balances of a voting system + veto power would inhibit gaming the system to take over, and having a sort of human proof-of-work (ie approved PRs) in order to have weight in the system will also help. Tokenized user voting could also be part, but not all, of the process.

Here is a sample Benefit Corp articles of incorporation and bylaws draft, that has been successful in generating long term commitments among a medium size development team that are all working for equity.

Bootstrapping and Timeline

In order to start immediately, it likely would be necessary to contract the initial role or roles while the organizational structure is put in place. Thus, a timeline for moving forward might look something like

Frequent public posts, github updates and progress reports will be key to maintaining credibility, as well as having an open slack for all developers and a positive, remote-friendly environment with pairing, updated docs, and generally following best practices. That, at a minimum, is the table stakes.

Back to the Core Problems:

According to Ian Lee, Parag noted these three issues as strong motivators for Bluesky:

1. Central policy enforcement is not meeting the needs of people or users

While messier, testing out community governance processes that are inclusive and emergent, may be more robust in the long run than central enforcement. Wikipedia, for example, has a successful model of an editor community.

Experimenting with governance models is a huge opportunity, to find something that is efficient and robust against attackers. Tokenized voting systems, consensus building software such as pol.is, volunteer moderators, and other systems can be experimented with by the hubs or nodes, as long as the protocol supports a way for the hubs to enforce their policies locally. Specialized policy providers should also be supported.

2) Controversy and outrage gets the most attention

Algorithms based on click behavior are intrinsically driven by short term factors. Making it easy to express intention and explicitly choose one’s feed algorithm, or having features such as context switching and relationship propagation (friends of friends, a la LinkedIn), may help address this.

Having a sense of building something rather than collecting views may also be valuable. Creating an interface to easily pin and bookmark posts, localized software that allows people to easily organize and curate to add value to the stream, could increase the desirability of long-term value over short-term attention.

In addition, real world truth does not currently have an adequate representation. Popularity of an item does not generally equate to truthfulness; ‘likes’ and ‘follows’ or even some tokenized ‘value’ have little to do with real world correspondence. It is necessary to have some kind of representation of statements, sources, and source chains; a bit more detail on this here: Towards Trust Networks and a Bullshit Meter

3) Fragmentation of public conversation is limiting the full potential of public conversation

Assuming this is the ‘Bubble’ problem, a few approaches come to mind:

— Perspective-switching. If users could choose to simply see the feed “as-if” they were a different user, it would enable them not only to broaden their own perspective but to engage in threads outside their normal bubble. (This should be possible with existing APIs given the correct permissions?)

— Metrics. Measure something and you can change it — Simply showing a user how skewed their bubble is, might incentivize them to exit it. If an optimized feed showed some sort of measure of what percentage of the multiverse was being traversed, a user might be curious how to get different slices.

Again these ideas require the ability to iterate rapidly, even with a small user base, and are likely easier to try as a local, small player than a large one.

Experimental Framework for Society

People are excited about BlueSky for many reasons, but I believe the fundamental one is that it promises to provide a sort of experimental framework for trying out different ecologies for a healthier online society, and different forms of communal governance until we find some that are both efficient and inclusive. We need a path for rapid experimentation that is not only growth or profit focused, that somehow reflects users’ long term values in evaluating the outcomes.

Beyond the table stakes, involving all stakeholders in intensive, collaborative experimentation has to be part of the path forward. And leveraging the energy Twitter is adding to the process ought to improve our odds of success.