To the west, you can see the skyline of Big Social—Twitter, Facebook, Reddit, and the quirky borough of Tumblr. And to the east, you can see the Archipelago of Personal Websites, isolated islands with one inhabitant each, lonely like a single player Minecraft game at best, and struggling to survive like a pirate lost at sea on a deserted island at worst.
In between, there are some lovely small towns. Group blogs, small communities within the large downtown areas (Discords, small Medium publications, etc.). But they are few, far between, and hard to access.
We are missing the Internet Local—places where small communities can gather, find outlets for their social needs away from the bustling, loud squares of Big Social, exchange resources, and discover pathways to the quieter corners of like-minded web wonders.
So what to do? How might we build bridges between these isolated, lonely islands? How might we create functional and beautiful shared spaces between our aimlessly floating web presences, so that we can enjoy the social web without being overwhelmed by it, enable discovery away from news feeds and search engines, and get to know our neighbors better?
Just as clusters of homes and neighborhoods can share common land, a neighborhood of websites can share a common space on the web. Although they are rare on the web, these spaces are guided by the same principles as other sites in the indie web, except that they are jointly maintained and grown by the owners of the personal sites they border.
Like modern big social media sites and ancient web rings of the Old Web, they provide pathways to more private corners of the web, as well as providing social opportunities and connected resources for the small communities they support.
It’s a challenge to find examples of this pattern in the wild except perhaps in scattered small forums, so perhaps this newly forged Rickshaw site can be an experiment in new forms. Here’s a proposal for what a shared website might look like:
A shared website should be as private and independent as an individual website. The data should belong directly to the members, they should each be able to move their data if they want, and the site should be a “domain of one’s own” and not mediated through an external corporation.
Just like a well-maintained open source project, a shared site will likely operate best if there’s an agreed process for contributing to the site and a code of conduct for members. Perhaps any member can post content without editing or moderation, especially since the group is small (see next point), but a code review process for members contributing at a technical level may be helpful to keep maintenance organized and to spark lively conversations about the site itself as a kind of meta-forum for discussing the direction of the shared space. And non-technical members can perhaps suggest changes through something like a GitHub issue ticket that technical members can then pick up and build.
I think 3 to 12 members is perhaps the bounds for community size for a site where a group has direct code and deployment access. Of course, each member might join several shared websites, but any more than that as a core membership may become unwieldy. These sites are meant to fill the gap between personal sites and sites that can scale to unlimited members (corporate social media sites, forums, etc.), and if they’re too large they can’t fill that need.
And here are some ideas for patterns a shared website might include:
What is the best workflow that would allow us to reply to each others’ posts here? I’m trying to think of the simplest possible set of steps. For example, grabbing the URL of the post you want to reply to and adding it to the front matter of a new post, like replying_to_post: https://busterbenson.github.io/rickshaw/kev_mcg/2020-04-25-potential-patterns-for-shared-websites. Still pretty janky, but on the upside we could completely customize the reading experience to be whatever we thought was the best experience. Testing out a Github issue as a commenting system also cause why not?