@celia I've been expecting this ever since I joined Masto in 2017, but I gather the people in the upper dev echelons (Gargron and advisors) are basically Nope.
I have an idea for a way to implement it as an alternate UI on top of the Masto API, but without funding to hire other devs, it would be one more project on a rather overwhelming stack.
So, let's call this thing CLF (circle-like functionality) for short.
(I swear I wrote this up in some detail a couple of years ago when I thought of it, but I guess it was a Masto post and therefore impossible to find again. Trying to remember details...)
So, some conceptual points:
I often conflate Circles and Groups (Communities, in G+) in my mind, since they serve some of the same functionality.
Groups have always been higher on my priority-list, because of the way they help foster community.
Mastodon (or at least Glitch Edition) supports Lists, which are about 85% of what Circles do, I think? You can't share them, and the UX is rather more awkward... but this seems like a good starting point for working out what we actually want from CLF.
As far as adding any kind of functionality to Masto without rewriting it from the ground up to be more understandable, maintainable, and modifiable (which is definitely Goals but a rather larger project):
My starting thought was server software to provide an alternative interface between the user and a Masto host -- ideally one or more Masto hosts, so users who wanted CLF didn't have to switch to a CLF-supporting instance or try to persuade their instance's admin to install it. (Given that mobile Masto apps have worked out mechanisms for safely letting users log in to multiple accounts, this doesn't seem like it should be a big hurdle.)
The design (data, UI) details of how Circles (and/or Groups) are implemented by that software will depend on what we want from them; I assume the main insight you're looking for here is how to do it without a redesign/rewrite of Masto -- and the answer to that is basically:
users interact with Groups/Circles via a separate UI (running on the CLF server)
G/C data is communicated between CLF servers using some standard protocol -- possibly ActivityPub already has the necessary features, just not used... or we could use some other protocol known to support Groups, like Zot (Hubzilla) or Friendica.
Groups/Circles can also be interacted with (in a more limited way) via standard Masto in that the CLF server will provide bot-like accounts for each Circle or Group. (Full functionality could be provided via commands in DMs, if users wanted that.)
I hope this is making sense; it's really just a first pass at the problem, and the question of what functionality we're really wanting is probably the first thing to look at.
Feel free to ask questions!
@woozle I think it's critical to look at what Circles promised, or what users exepected, before specifying a replacement:
Circles defined the scope of outgoing posts to the Circle. This is useful.
Circles defined the scope of incoming posts from Circle members. This ... often proved problematic.
Circles do not organise content by topic or theme. The expectation was often that they would.
Circles were overloaded with several other elements, including some capabilities / permissions-based settings.
Members of a circle have no idea of what circle(s) they're in, by whom, and how labled.
Circles may not have been intended to serve as labeling tools, but were quite useful for this. Often of negative labels: "troll", "spammer", "idiot", "fascist", etc., were among my own categorisations. Note that "Circle-as-tag" requires following someone you probably don't actually really want to follow.
One person's Circles ... are only that person's Circles. There's no sense of shared or collective association. For that you want Groups.
Ultimately, I found Circles most useful when used to define:
A SMALL set of profiles in which I was highly interested in seeing content.
Perhaps another 1--3 sets of progressively less-interesting-to-me accounts.
(I use Mastodon Lists for both capabilities here.)
A small set of circles for targeted distribution. Those were virtually never used. Again, Groups are what you want here. And this implies group management capabilities which are not the same as individual relationship / filtering / blocking tools.
#Hashtags are kinda-somewhat useful for search but tend to get spammed to fucking death. At least on Mastodon, you can filter a single user's content by hashtags but only by navigating directly to their home server: https://tooot.cat/@dredmorbius/tagged/hashtags
That's more-or-less what Circles Did / Did Not do.
@woozle What I suspect most people are LOOKING for is:
The ability to limit content to just a select group of people. On Mastodon the only reliable way to do this is to explicitly list out recipients in a DM toot. A group would enable this.
Note that "limit" != "target". You can't ensure that someone will get or see a message, only make it difficult for someone to do so.
Note that "difficult" !- "impossible". If you've a compelling reason to keep content out of the hands of a motivated adversary, that's going to take a lot of work. Keep in mind that Mastodon instance admins can view ANY message, including DMs. They're direct but not private.
Some way to organise incoming content based on topic or theme. Unless you're dealing with a profile with very strict content discipline (that is, they post only on a given theme or topic, expecting this of most people is simply a mistake. (Your heros will not limit their personal discussions to The Topics You Find Important And Significant.)
Most group-based discussion has way too much overhead to creating and forming and dissolving groups. The great thing about meatspace is that you can create a group simply by saying "meet at P place at T time". Presto! Instant group. At some later T+t, the group dissolves. Other groups can form at P given different times (or by subdividing P). The whole concept of ephemeral groups is tremendously underserved.
Yes, longer-lived groups are also useful.
Group management is more complex than you think it is.
Group management is more complex than I think it is.
Group management is more complex than you or I think it is even after hashing it out for a few years.
At best, any digital group-management system provides a shallow approximation of the full depth and nuance of tools needed.
A group is a fragile creature. Until it becomes a fearsome one.
Groups are also fluid. They change. They grow, shrink, merge, split, form little factions. Wander off for long lunches. Go to bed with each other. Break up.
Having only one moderator of a group is exhausting and/or prone to insufficient moderation. Having more than one moderator of a group leads to confusion, inconsistencies, and nobody knowing who did/should/ought to do what. (Note that most of this also applies to one moderator.)
@woozle Since I mentioned TAGS:
A defined-vocabulary set of tags can be useful.
Everybody will hate it.
There's one I happen to like Because Reasons: the Library of Congress Classification System.
I know that you hate it. You're not wrong. But you're also not right.
"You" is not just Woozle, but whomever is reading this.
"You" includes me.
The useful thing about content tags is that ... they tag content. If they're a common vocabulary, then multiple people can interact on those tags usefully. If they're not, then ... well, absent some intelligence somewhere that associates or dissociates specific tags ... you've got a Tower of Babel and nobody speaks the same language.
(Different languages can be useful. See Tom C. Scott's Seeing Like a State and the notions of "legibility" and "illegibility". Still, there are times when a common basis of informational exchange is helpful.)
All shared vocabularies are political. Someone is oppressed. Someone is advantaged or privileged. Whether you consider this good or bad, it's an inherent characteristic of the system, and ultimately, a tool to be worked with and around.
Profile tags needn't have a shared vocabulary, but are good at organising people. I'd really like to have a few, resembling but not limited to "Friend", "Family", "cow-orker", "Angers Easily", "Wicked Smart", "Dim Bulb", "Troll", "Admin", etc. My list need not be yours. Tagging need not involve following, and shouldn't be overloaded with following-based relations.
"Mute", "Block", and "Follow" are effectively tags with specific permissions / access connotations / overloading.
Thank you for all the interesting discussion. Re #tag the Mastodon UI that I am using allows me to enter a #tag in a toot and also in an entry field in the upper left corner so if I want to contribute to a common folksonomy (as I do) I can adjust my spelling and upper-lower cases to fit in.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!