Designing an open Facebook alternative

Found at: jfm.carcosa.net:70/blog/computing/facebook-alternative-outline.txt

# Designing an open Facebook alternative (outline)

June 14, 2017 ยท 8 minute read
Posted in:  computing social free software Facebook 


## About this post

     alt="Meme alliance logo: upside-down red Facebook F"
     class="inline-image no-filter">

I meant to be writing a couple of blog posts on [Mastodon][ms]. But a
thread on Mastodon led me to start thinking about Mastodon:Twitter::**X**:Facebook. There have been a few alternatives that haven't really gone anywhere, which is kind of unfortunate, but perhaps they were just too
early. And I was thinking about what we'd want today.

I want to write a full article on this, but I started by outlining it, and I think the outline is pretty readable, and I'm just going to post it on the principle that done is better than good.

[ms]: https://joinmastodon.org/

## Why
* Surveilance capitalism
* Damage to the open web (silo)
* Abusive social dynamics
  + tribalism 
    * fake news 
    * outrage cycle
  + pile-ons
  + You can block individuals, but not their foafs or groups.
* promotion of bad personal behaviour
  + grandiosity
  + self-promotion
  + outrage addiction
* click bait 

## Technical considerations

* Distributed vs decentralized/federated
  + distributed scales best and provides most personal control over your data
    * see [Patchwork][ssb] (ssb) for an implementation.
    * No hosting provider required; no onboarding other than installing 
      an app.
  + but it has serious drawbacks
    * harder to implement multi-device
    * storage of full logs on small devices
    * lose your device, lose your identity
  + Federated is easier to implement, more traditional model
    * drawbacks are security (trust admin) and stability (admin must maintain
  + But on the whole, federated is best choice *currently* and will be assumed
    for the purposes of this essay.
* Federation via [ActivityPub][ap], because it's the standard.
  + should provide at least limited interoperability with other types of
    application, like GNU Social.
* Full data export
    + Move all of your data to another server
    + Ideally, your friends/followers are automatically updated as well.
* Scaling down is more important than scaling up
  + One problem with Mastodon is that it is relatively expensive to host an
    instance (compared to GNU Social). Requires 2GB RAM on VPS. 
  + Target here is to support VPS with 512MB RAM. Supporting shared hosting
    might be a bonus, but realistically, that's no longer required.
  + Deployment should be simple (for whatever values of simple we decide on).
  + Goal is to scale by moving users to more instances instead of scaling
    up single instances. But a small instance should support around 200 
    people without performance problems.
* Auth
  + The app should provide OAuth2 for apps that want to use it.
  + The app should be able to act as an [indieauth][ia] provider.
  + The app should also let you register and log in using indieauth.
[ia]: https://indieauth.com/
[ssb]: https://github.com/ssbc/patchwork

## UX considerations

What are the things that make a Facebook-like social app different from a Twitter-like social app (e.g. GNU Social, Mastodon)? And where can we 
improve upon Facebook straightforwardly?

### Different types of posters
* Users
* Groups
* Pages

### Different types of posts
* Statuses
* Notes
* Images (with commentary or captions)
* Videos (same; maybe media is considered one kind of post)
* Polls
* Links (with commentary)
* Events (one of the things many people consider most essential about

### Essential UI features
* handling of Open Graph meta tags
  + IMO one of the main drawbacks of Mastodon is that posts are displayed in
    a very compact and uniform way, with links being presented only as literal
    link text. 
  + Different post types *should* be presented differently, and in general, it 
     should not really be up to the user to type in URLs or @references in the
     body of their posts in order to have links or to tag someone.
  + A client *could* parse OG tags on the target, but this really should be
    done on the server.
* Friendship mutual by default
  - Problem with Twitter/Mastodon is that follower-only posts are effectively
    public, since anyone can unilaterally follow you at any time, *unless*
    you set your account to restricted.
  - But restricted account is not the default, and probably not the norm.
* Rich privacy vocabulary
  + User accounts searchable or not.
  + Post privacy default should be stable, not fluctuate based on last post 
    like on Facebook.
  + Post privacy controls should be front and center.
  + Post privacy should encourage the use of "circles" more than FB does.
    * Also, there should be a stricter-than-private option that e2e encrypts
      for all tagged recipients. This should be the default for "just me"
  + Users can allow followers or not.
* Actions on posts
  + Reactions and comments should be available on most post types, and
     they should be clearly distinguished from posts (unlike Twitter-like sites).
  + A more expressive reaction vocabulary than Facebook provides might be
     a good idea. But see also self-promotion.
  + Sharing: 
    * needs more thought. I've always liked being able to share with 
      added context, but there are good reasons that Mastodon doesn't provide 
      quote tweeting. And if you don't include the equivalent of quote tweeting, 
      then you might as well use Mastodon boosting terminology.
    * One advantage of the way Facebook quote-shares is that you get comments 
       on *your* post from your friends. 
    * Maybe links and statuses/notes should be shared differently, with attribution 
       and original comments stripped from links. 
* Chronological timeline
  + Facebook uses "the algorithm" to surface things on your feed. This has been roundly criticised for being good for Facebook, bad for users.
  + We should use a chronological feed, like Mastodon
  + **Except**, Facebook has a "see first" feature that is really useful. You should be able to tag friends, pages, and groups with "see first". Your chronological feed is now sorted into two buckets, each of which is shown chronologically, but one is shown before the other.

### Searching

Mastodon sharply limits searching, in order to prevent Nazis from [kibozing][kb] for feminists and anti-racists and harassing them, a serious problem on Twitter. On Mastodon, you can only search hashtags, and usernames. The search box also lets you open post URLs from other instances in your regular instance's interface. This choice is controversial, largely because it prevents people from searching in their own histories.

On Facebook, you can basically search for anything public. 

Proposals for this replacement:
1. You can search for hashtags
2. You can search for users by username or display name, as long as they have opted-in to being searchable.
3. You can search public or closed groups and pages by name, keywords, or hashtags, subject to all other privacy restrictions, but you can't search their content. (Maybe loosen this to allow members of closed/secret groups to search content?)
4. You can search your own posts. (And those of your friends?)

[kb]: https://en.wiktionary.org/wiki/kiboze

### Finding friends, pages and groups

The biggest problem with competing with Facebook is network effects. How do we catch up?

Facebook uses a lot of **creepy** methods for finding you people and pages to follow. Our rule has to be **Don't be creepy**.

Facebook bootstrapped its membership by uploading peoples' contact lists and then spamming their email contacts. We can't do that.

Facebook uses your social graph (FOAF) to suggest friends. Maybe this is okay? They also use various kinds of tracking, which is not okay.

We can suggest people based on interests, if they've made their profiles searchable.

There's a lot to think about here.
### Less-essential UI features
* Chat.

  People depend on FB chat, but there are better options. Maybe make it 
  easy to install a Prosody server?

## Social considerations

### Abuse and harassment

In general we want to make abuse and harassment more difficult than on Facebook,
in the same way that Mastodon makes it more difficult than on Twitter.

#### Improve blocking

You should be able to block not only your harasser, but their social graph, and any 
groups they may belong to. 

Individual users should be able to block or mute whole sites, and admins should be
able to do so for their full sites.

#### Content warnings

Facebook completely lacks content warnings, and people try to fake it in different ways.  Mastodon does it mostly right, other than labeling (ie conflating NSFW with sensitive for other reasons). If a post has a content warning, its media should also be considered sensitive and masked. 

#### Improve moderation

On Facebook, reports only go to the site moderation teams, not group or page admins.
Group and page admins can only find out about abuses through direct messages. 
This could probably be improved. Reports to group or page admins probably shouldn't
go to site moderators or risk site suspensions or bans, unless they are escalated by the
page admin, or they are specifically reported for site CoC violations.

Sites should have Codes of Conduct, and site admins should use these when deciding
on site blocks.
### Self-promotion

By self-promotion, here, I don't mean promoting your goods, services, or creations, which 
should be fine. What I mean is tailoring your posts for maximum reactions or chasing
page subscriber numbers. Because doing this lowers the quality of content, and also makes 
you a worse person. 

* reactions should be treated more like comments than as like buttons. They shouldn't be explicitly quantified. Reactions are a good feedback on posts, and getting them makes you feel good. But quantifying them encourages addiction and tailoring posts to maximize them.
* Share counts should also never be surfaced. 
* Analytics should not be available to page admins, because they attract brands and other 

### Fake news, click bait, and outrage addiction

Harder to deal with because of freeze peach issues. 

Distinction between actual fake news (a kind of click bait) and partisan news sources. 

Idea: you can't share a link until you have clicked through to it.  This means no sharing 
based on headlines only. But hard to enforce and also very annoying. 

Site codes of conduct can ban fake news and click bait, and hopefully instances are small 
enough that this doesn't increase moderation load too badly. 

Other than that, this is a very hard problem --- if you provide the ability to share stuff, people will share it. Hard to maintain constructive culture. Lack of incentives for click bait may help some. 

### Accessibility 
* upload of media should make it easy to provide content descriptions, and these should 
   be displayed smartly rather than inlined in the post. 
* No animations or sound should ever auto-play. No, not even on mouseover.
[ap]: https://www.w3.org/TR/activitypub/

## Comment

This blog doesn't support comments, but you can comment on the fediverse. Please comment on [this thread][comments].

[comments]: https://glitch.social/@gcupc/585763