How to Run a Small Social Network Site for Your Friends

rw-book-cover

Metadata

Highlights

  • Because we’re mostly all friends with each other, this extra communications mode is kind of like a group chat on steroids. For our community it ends up being a sort of hybrid between Twitter and a group chat. As a result of having a community layer alongside a more public layer, we have a movie night, a book club, and a postcard club. Campers visit each other when we travel, even if we’ve never met in person before. We correspond with each other about what we’re making for dinner and trade recipes. They’re the kind of mundane interactions that you probably don’t want to have with perfect strangers but you cherish in a group of people you care about.
  • Imagine two different software developers. One person writes a piece of software that makes the lives of one million people slightly easier. Maybe it’s better routing for navigation software and it shaves 30 seconds off the commute of a million people. Another person writes a piece of software that only ten people ever use, but it tangibly changes their lives for the better in very material ways; maybe they learn a trade that becomes a career. One of these outcomes is not necessarily better than the other, and yet due to myriad factors, only the software with a million users is likely to get funding from entities—whether the context is for profit or not for profit.
  • I’d like to advance the notion that software does not have to scale, and in fact software can be better if it is not built to scale. I hope some of the examples I’ve given above have illustrated what is possible when software is used by a small number of people instead of a large number of people.
  • Right now on federated social networks you have a concept of people on your own “home” server (which I’ll call local) and people on every other server in the world (which I’ll call public). But we need concepts that are more fine grained than local and public. I would like to see groups of servers that band together through a kind of mutual approval system. The group of people on Server A decide that Server B is to be trusted, and vice versa. They approve each other, in a manner similar to friending someone on Facebook, but for a whole server instead of an individual user. Now the 50 people on server A and the 50 people on server B are in a “neighborhood” together.
  • Big “private” communities should be very very hard to come by — and “public” should be where the “broad” conversations happen.

title: “How to Run a Small Social Network Site for Your Friends” author: “runyourown.social” url: ”https://runyourown.social/” date: 2023-12-19 source: hypothesis tags: media/articles

How to Run a Small Social Network Site for Your Friends

rw-book-cover

Metadata

Highlights

  • Because we’re mostly all friends with each other, this extra communications mode is kind of like a group chat on steroids. For our community it ends up being a sort of hybrid between Twitter and a group chat. As a result of having a community layer alongside a more public layer, we have a movie night, a book club, and a postcard club. Campers visit each other when we travel, even if we’ve never met in person before. We correspond with each other about what we’re making for dinner and trade recipes. They’re the kind of mundane interactions that you probably don’t want to have with perfect strangers but you cherish in a group of people you care about.
  • Imagine two different software developers. One person writes a piece of software that makes the lives of one million people slightly easier. Maybe it’s better routing for navigation software and it shaves 30 seconds off the commute of a million people. Another person writes a piece of software that only ten people ever use, but it tangibly changes their lives for the better in very material ways; maybe they learn a trade that becomes a career. One of these outcomes is not necessarily better than the other, and yet due to myriad factors, only the software with a million users is likely to get funding from entities—whether the context is for profit or not for profit.
  • I’d like to advance the notion that software does not have to scale, and in fact software can be better if it is not built to scale. I hope some of the examples I’ve given above have illustrated what is possible when software is used by a small number of people instead of a large number of people.
  • Right now on federated social networks you have a concept of people on your own “home” server (which I’ll call local) and people on every other server in the world (which I’ll call public). But we need concepts that are more fine grained than local and public. I would like to see groups of servers that band together through a kind of mutual approval system. The group of people on Server A decide that Server B is to be trusted, and vice versa. They approve each other, in a manner similar to friending someone on Facebook, but for a whole server instead of an individual user. Now the 50 people on server A and the 50 people on server B are in a “neighborhood” together.
  • Big “private” communities should be very very hard to come by — and “public” should be where the “broad” conversations happen.