As someone who spends a lot of time on social media for niche fandoms, I like being able to go to spaces dedicated to a specific topic, because it’s a good way to find people who are willing to discuss said niche fandom with me. However, when these spaces are walled gardens, like Discord, that can result in having to repost the same thing across multiple of these spaces just to see who is willing to talk, which feels self-aggrandizing. When those spaces have no bounds at all, like Bluesky or Tumblr, I often have no idea who I can talk about these subjects with if I don’t have preexisting mutuals interested in it, and posting on main feels like it might as well be an uncaring void. Even when there are drive-by post-likers, I very often have no idea who they are.
Tags and custom feeds exist within ATproto, which can sort of be used to organize topics. But neither of these alone form a community. Anybody can post to a tag, which means there can be conflict over what content “belongs” in that tag. On the opposite level, custom feeds grab posts without necessarily letting the original poster know about it, much less agree to have their post featured there, and are more on the level of saved filtered search results than anything else. These both are a way to find content of a specific sort, but don’t necessarily invite conversation with the people who produced that content. As a fan, content about my interests is okay, but it's really the people behind them that makes me want to stay.
It should be possible to create more organized posting spaces within the Atmosphere, which sync up with fanart from Bluesky, meta essays from Leaflet, rambles from Pckt, and more. To this end, I am proposing a software infrastructure that allows non-technical people to easily create three pieces needed to operate a semi-open space: a feed that displays posts submitted to it, a roster of members, and a labeler that names community members with responsibilities within the space. I will discuss each of these in more detail below. I’m not a technical person myself, so I’d love to hear ideas on how this can be practically implemented.
Piece #1: The Submission Feed
The idea is that instead of having a feed that algorithmically decides what posts are in there, the feed has posts that users voluntarily submit to it. By default, this goes into the feed where anybody who is subscribed to it gets it delivered as a set bundle. At any point moderators can decide to remove a post from the submission feed. This doesn’t get rid of the post from the ATproto network entirely, but does stop it from being presented along with other contents of the submission feed.
The goal is to give the community a way to make sure that content within the submission feed stays on topic and within the bounds of local norms, without having to wait on Bluesky or any other similar service to ban problem users. After all, there are a lot of behaviors that are annoying in a community context but don’t merit being kicked off the platform entirely. For example, if an artist submits an illustration of characters A and B kissing to a feed that’s supposed to have art and writing of characters B and C in a relationship, the moderators can remove that post to enforce their local community norms while leaving the artist’s posts up on their own timeline. In this way, the submission feed has more quality control than a tag, while being more intentional about post inclusion than a standard algorithmic feed.
Piece #2: The Roster
The next part of this idea is a roster of all community members. There are multiple uses for this, which I will go into below.
First, some communities may want more control over who can post into their submission feed than just removing inappropriate posts as they occur. A roster of approved members can be used to grant credentials to post into the submission feed, similar to Baldemoto’s implementation of furryli.st. This means that potential members will have to ask to gain posting permissions, and problem members can be removed from the roster.
Second, a roster can be published publicly to let community members see who else is on it. This could be configured like a forum’s “who’s online” list, to let members get a sense of the size of their community and who else is there with them at the moment. Similarly, this roster can be linked to a labeler, so that community members encountering other community members in the wild can instantly know that they both are in the same group. (More on this below.) These features won’t be appropriate for every community, but may be useful for helping people find others within the group.
Piece #3: The Labeler
It’s important for users to know who is in charge of an online group, ie, the mods. Very often, this is whoever creates a community and those they select to have power alongside them, with people entering and exiting that group of specially designated moderators over time. Other platforms may do this differently, like how Discourse grants increasing moderation permissions based on how long they have been active in a community. Regardless of how this is assigned, users should know who makes the rules and decisions in the group.
To make this visible, the submission feed is paired with a labeler that labels all those with moderation powers in-context with their posts. This labeler may also label other things, such as being on the community roster in general, special titles members have earned, or being monetary supporters of the community. Anybody who subscribes to the submission feed is automatically subscribed to the labeler too.
Simple Community-In-A-Box Setup
All of this is pretty technical stuff. I couldn’t do this off the bat if you asked, and there are many other people in a similar boat as me, where they have the will to run communities but not the technical aptitude to do it unassisted. So the set up and management process has to be simplified enough to bring them into the realm of possibility for non- and less-technical people. By lowering the skill floor in such a way, we make the Atmosphere more hospitable to the types of communities that actually bring people onto the platform, increasing user adoption.
Ideally this will be as easy as creating a new Discord server or a Subreddit. This means a nice GUI with no need to touch code. In addition, it should be mobile-first, since a lot more people access the internet from their phones than from computers. As a designer, I’m fairly well positioned to ideate on the UI for this, whether through Figma or agentic coding, but I expect I’d need help on the backend.
How To Get People To Pay For It
It’s a sad fact of the world that running things costs money. Digital infrastructure, even meta infrastructure that helps people build simple versions of it for their individual communities, is not an exception. I don’t know off the top of my head how expensive this would be to run, but it’s better to get started on this sooner rather than later.
My overall instinct is to go for a Discord or forum-style monetization method where some members pay to keep the group running for everybody, in return for shiny status markers, customization options, and some quality-of-life upgrades. The more people with paid memberships there are who choose to boost a community, the more benefits the community as a whole can get. There could also be Reddit-style awards that members can purchase to grant to people’s posts, which help foster a sense of community while helping to pay for things.
Traditionally, social media platforms use advertising to make money, but I am wary of pursuing that as an option. Rahaeli of Dreamwidth has argued that advertising is fundamentally unsustainable as a form of making money for social media. Unless the service is already based around something very specific, advertisers have little idea what ads users there are likely to click, so the site will have to collect a lot of data from users in order to target ads. The point of this proposal isn’t to build specific communities, but the infrastructure to allow building these communities, so it has that problem with lack of specificity. Figuring out how to add advertising into this seems like it will add significant technical overhead that will still have to pay for itself, along with content restrictions that may significantly block user adoption.
If anyone else has thoughts on this idea, whether from fandom or outside, I'd love to hear them! My expertise is in design, so it's helpful hearing what those on the engineering and business sides think about this.