Hey, hoodie here. Today i want to talk to you about a topic very very important to me, and also quite difficult to address, through the lens of social media technology. so first, we have to start with a definition.

a Community is a group of people, whether they be small or large, diverse or near-identical individuals, any group of people is a community, in the literal sense of the word.

This is a weird topic to address, because there are two features that deal with community, in the literal sense, as well as dealing with the complex social rules that lie under that. Those two features are the topic of today's article. For those of you in the audience not particularly excited by my methodical method of teaching, i'll throw out there that we're dealing with what many call 'groups', or 'bangtags', in GNUSocial tech.

So, let's talk about community, in the general sense, real quick, to get a few things out of the way. Community, literally speaking, can never be accurately judged or valued in any meaningful manner. As such, the tech we create must allow the user to make decisions about every individual aspect of this. A good example is the concept of a follow count. Does the user want people to know this information? this is a community issue, in terms of what subject of development we are talking about.

I mention this because, I, personally, as a user, wish I could keep that information private. There are reasons to have it public, but I personally do not appreciate that information being told to anyone who chooses to glance at me.

As such, I should be allowed to hide this information. There is a counterargument, in that users need to know that information, in the case of whether or not they should be allowed to boost your posts, should they ask. I personally believe the software should be extended via the feature I designed, namely, General Requests (link to full medium article on that matter).

Related to this, a wonderful feature already exists, which makes the lack of a feature I just described personally acceptable for me, that exists within the GlitchSoc fork of mastodon (link to github). This feature allows us to "hide your network", in it's own words, which means it let's us hide the exact data of who is and is not being followed by a user, from the user.

Alright, so now we've taken some of the more vague examples and explained how that interacts with the concept of community, from a technical perspective. Let's move on to a feature that many want in social media: Groups.

Well, what is a group? In the literal sense it's the same as a community, they are the same definition. A group of people, after all. So for us to make ethical group tech, we have to rephrase the feature's title. What do people really want from groups? The answer is more ways to organize data and posts, and specifically, opt-in groups of users, as a timeline that people can link to each other, in many cases, or otherwise use as a group conversation, or... well, now we're getting off topic.

There are many ways to define a group, in the aspect of a feature to enable this sense of community, or other form of sharing in an organized fashion. When we reframe it like this, there are two use cases that the users want, and they are very different, even though they lie on the same spectrum of software toolset that the social media in question must fulfill to suit these needs. I would personally call this feature "groups" because it is in fact, easier to say than community, as well as being shorter, and snappier.

Organize existing Community

Firstly, at one extreme, people want to be able to post to a place that their friends won't miss it. In this way, it is rather similar to a message board, or a forum. Now we have to think about how this interacts with privacy. Do the users want strangers to see those posts? Probably not all of the users, for sure. So we need to make it so those posts can only be seen by people allowed into the group, or commmunity. The community probably needs a private posting setting as the max setting, or at the very least, the ability to set a max publicity. As such, we can also set a default publicity, so that users can define the general tone of the group. Similarly, they will need to be able to kick users, or at the very least limit who gets in, preferably both. If groups get too large, they might need to be able to limit who gets in, or at the very least, who can let people in. Now we have a decent run down of how moderation will need to work. Users can be 'Trusted' to allow them to invite people to the group, and people can be 'Moderators' to allow them the ability to kick people and accept them in, if we get a general request implementation for offering user invites anonymously. The original owner will be the one who can delete the group. Maybe owners should be able to transfer that right, and if the group is disbanded, the users should be notified in their notifications timeline.

Discover new Community

Alright, so we looked at the users most likely to need privacy, what about those big groups? Many users want groups to be used to make people who participate in a similar hobby and such more accessible and discoverable. They probably want settings to allow anyone to view it, if it's an art-group, or a writing-group, or something on those lines. Now we can start to think about what kind of posts those people will make. If they produce content such as art, and want to use the group in that manner, maybe replies that are not to yourself should be excluded from the group, or at least allowed to be excluded from the group, via a setting. They also probably don't want to leave their friends behind, so maybe we should look at history, next, for how we will make things public. GNUSocial had bangtags, which are just another sort of hashtag, that anyone can publically follow. So, let's use that technology, and allow hashtags to be either '!tag' or '#tag' for the future, with a public feed in RSS or Atom, subscribable via ActivityPub tech. Our group implementation can customize a hashtag of either sort that is the 'group tag'. Maybe, '!tag's can be seen even if they are marked unlisted, as a backwards compatible use-case. Alright, let's say the group gets really, really big, but we don't want trusted users, only moderators, to be able to accept someone into the group. Maybe we can use '&group' as a way to allow users to address admins of the group, or the whole, should they choose to be addressable. Really, the biggest part is making this dialogue all open, for future improvements. The first step is making this all plausible to begin with, and by now, hopefully i've laid out the most basic needs.

Now there's our first feature, and hopefully I got y'all excited for the possibility of a future in which this stuff is much more widespread, as i sure wished I had enough friends in the facebook space, that weren't getting harmed by that software, to interact with. Now let's step back from the well known connotation of community, and look at it again in the literal sense. Let's say I, as a user of the Mastodon software, have a friend. Yep, you guessed it, we're going to reconsider the 'following' paradigm. The ideal is to use lists, which already exist in Mastodon, for this purpose. There's a problem, though. Let's say I want to follow someone, but don't want them on my timeline all the time. Right now you have to mess with muting, and mute the user, but also still follow them, to add them to a list. I'd propose a different feature, and allow the user to make the user go to any list they choose, with the Home timeline being a list you cannot delete, when you click the follow button. After all, if they're in a list, you're still following them, on some level, just not as actively.

Anyway, I am sure you all are tired of hearing me talk at you, so I will take my leave for now. I hope you enjoyed the article, or at the very least, learned something. Thanks for listening,

- hoodie aida kitten.

here are some links to support me if you wanna send me a few bucks or support my work.