My first-ever submission to SSRN was a success! Recently, I’ve gotten an email every day telling me that A meta-proposal for Twitter’s bluesky project is on the top-ten downloads for a ton of journals.
Officially I’m a co-author in the top 10 downloads in a bunch of SSRN topics
Namely: CompSciRN Subject Matter eJournals, CompSciRN: Other Web Technology (Topic), Computer Science Research Network, InfoSciRN Subject Matter eJournals, InfoSciRN: Information Architecture (Topic), InfoSciRN: Web Design & Development (Sub-Topic), Information & Library Science Research Network, Libraries & Information Technology eJournal and Web Technology eJournal.
This is a little less impressive than it sounds. But I’m getting a little ahead of myself. Here’s the story:
How did this all happen?
As a Berkman fellow, the main thing one seems to do is go to recurring meetings for a range of working groups. Jad Esber, one of my esteemed colleagues, got the idea and invitation to give a proposal to Twitter on their Bluesky project. He rounded up a bunch of us, and together we spent 5-6 meetings going over parts of what he called a “meta-proposal” — our guide on how to review the other different proposals coming in.
Jad is a wonderful person, and I learned some project management tips just from being part of this process. Getting a fair-sized collection of people to agree on a document, quickly, is difficult! As far as I remember, he did it like so:
- The first meeting is to scope out different ideas people have about what they want to say.
- Jad then writes excellent notes and combines ideas into a manageable number of topics.
- Each meeting after this includes just the subset of the original crew who feel like they have something to contribute.
- Jad, who has taken good notes throughout these meetings, polishes them up a bit, then turns it into a paper.
It was easy! It was so nice. And I got to work with people I really enjoy, including but not limited to Crystal Lee or Tom Zick
What the paper argues
The paper contains a bunch of ideas and warnings for a hypothetical new, decentralized social network. There are three big pillars: discover & curation, moderation, and business model. It’s quite short, so I recommend you just read all of it — it is barely 5 pages long.
I do care quite a bit about integrity issues (people often call them issues of “moderation”, which is wrong! More on this in a different post later). So I wanted to highlight this a bit.
Sidenote — what is integrity? Shorthand it to “hate speech, harassment, misinformation and other harms”, or “the problems of social media that come from users doing bad things to other users”.
Regarding curation: The most subtle proposal in here is around identifying the “idea neighborhoods” that someone might be hanging out in. (The paper calls them echo chambers). Why? Because “neighborhoods” are an important building block in identifying and fighting targeted harassment. If you know which neighborhood someone normally spends time in, you can be appropriately skeptical of them in times of stress. You can see a basic version of this in action on Reddit: if a certain post in /r/TwoXChromosomes gets a spike in harassing comments, it was pretty easy to block people who recently posted or commented in /r/mensrights.
(This is also fleshed out a bit in the moderation section as well)
On moderation: I’m tempted to block quote the whole thing. It’s all so clear, important, and succinct. And the key ideas to me are in the “friction” section, which is only 3 paragraphs. Summarizing it would take just as long as quoting. Okay, I can’t help myself. Here’s the section on friction (and a little preamble).
The role of moderation isn’t just restricting bad words or racist content. In designing the protocol and reviewing proposals, the conversation around moderation should center around restricting harassment & harm.
In considering the topic, the conversation should be framed under macro norms which are universal to the protocol; meso norms that are shared across certain clients of the protocol; and micro norms that are specific to a specific client.
Friction
It is well documented that our current systems that rely on the virality of user-generated content end up amplifying harmful content – and there is only so much that moderation efforts we tack on can do to mitigate this. In reviewing BlueSky proposals, we must engage with the question of virality and amplification and whether the protocol design avoids this.
Among the beauties and challenges of free flowing online space is the lack of physical boundaries. Traversing “geographies” by jumping from one conversation to another presents no restrictions. However, from a bad actor perspective, this presents an opportunity to scale harassment efforts and disrupt many events at once. Bluesky is an opportunity to “bring in more physics”, designing in friction on the protocol-level as a proactive way to avoid downstream moderation issues. Without getting into the complex issue of identity, increasing the cost of creating a new account, including introducing a monetary cost to start a new account, might be effective.
Enabling users to see which “neighborhood” other users are coming from could help users identify a provocateur and take action themselves. In addition to helping avoid brigading, ways of visibly ‘tagging’ users could help identify “sock-puppet accounts” and make bots easily identifiable. However, visibly tagging users could present the risk of short-circuiting judgments, and so the system should also present opportunities to identify any cross-cutting cleavages – for example by highlighting shared interests between users.
I’d say I couldn’t put it better myself, but, uh, there’s a reason for that. (That is, I feel a lot of ownership of it).