This post is a sort of partial dump of my efforts towards an idea/proposal for improving discoverability and onboarding for the Fediverse while avoiding new users just being dumped on a centralised instance. I've seen people suggest that one of our secondary defenses from megacorp social media (like Meta) is improving our UI, so this is part of my attempt to do that.
We can use our non-monetizability to construct algorithms specifically for the purposes of people finding the content and groups they want, rather than for the purposes of selling them shit.
I actually started working on this during the Reddit Migration, but got sidetracked with other things ^.^, so I'm dumping it here for everyone else to make more progress!
I want to discuss a rough proposal/idea that eases the onboarding of new users to the fediverse, and discovery of groups, while hopefully distributing them across more instances for better load balancing and decentralization. More generally, it should enable easier discovery of groups and instances aligned with your own sentiments and interests, with a transparent algorithm focused on user control and directly connecting people with entities that align with what they want to see.
I may interleave some ActivityPub terms in here because I've been working on a much larger proposition for architectural shifts (capable of incremental change from current) that might allow multi-instance actors and sharding of large communities' storage - I want the fediverse to be capable of arbitrary horizontal scaling. Though of course that will depend heavily on my attention span and time and energy. I might also just dump my incomplete progress because honestly my attention is on other projects related to distributed semiconductor manufacturing atm ^.^
What this post addresses is the current issue of onboarding new users ^.^, and helping users discover communities/instances/other users. These users typically are pointed to one of about 5 or 6 major instances, which causes those instances to have to eat costs, especially since loads of users in one place means loads of communities - and the associated storage needs - in one place (as users create communities on their instances).
My proposition/idea consists of the following:
- A mechanism by which instances can declare their relevant purposes in a hierarchical, "refinement" manner
- A mechanism by which instances can declare what sort of instance they are - lemmy, mastodon, kbin, etc.
- A mechanism to specify those purposes such that different terms can be merged in a given instance - for example, multi-language terms for the same item
- A relatively simple algorithm that lets instances select hopefully other reliable instances that are relevant to someone and automatically link over to them on signup.
- A proposition for a hopefully intuitive UI with sensible defaults ^.^
- (maybe in another post) an idea for simplified Fedi signin.
Self-Tagging Structure
The first part of the proposal is specifying a way for instances to tag their general topics and category at varying levels of specificity.
Tagging the "Type" of Social Media an Instance is Running
Each instance should have a descriptor of what software it is running.
This serves as a proxy for what "type" of social media it is (reddit-like, twitter-like, whatever kbin is, etc.), taking into account that users are likely to have visited an instance based on reports that the type of software it runs is what they want.
I propose some string endpoint like instance_software in the top-level instance actor.
Tagging the Focus of Instances
Generally speaking, instances fall into several categories:
- General purpose instances
- Instances which lean towards some topics but are general purpose.
- Instances that are very focused towards some topics to the exclusion of others.
There are also instances with varying levels of moderation, which may be encompassed in this. ^.^
To solve this problem, instances should provide an endpoint (for now, let's call it instance_focus) in their representative actor that produces a collection of so-called subject trees with associated weights.
Subject Trees/Sentiment Trees
Each subject tree is a nested list that looks like the following:
{
"weight": 1,
"polarisability": -0.7,
"subject-tree": {
{
"subject": "programming",
"terms": {
{"en", "programming"},
{"en", "coding"},
{"en": "software-development"}
}
},
{
"subject": "language",
"terms": {
{"en", "language"}
}
},
{
"subject": "rust",
"terms": {
{"*", "rust"},
{"*", "rustlang"}
}
}
}
}
This indicates an instance/other-group that is interested in programming, specifically programming languages or a programming language, and specifically the programming language rust. It also indicates an estimated polarisability by this instance for /programming/language/rust/ of "-0.7" i.e. they estimate that people who feel a certain way towards one subtopic of /p/l/rust/ will also likely feel a similar way to other subtopics of /p/l/rust/ unless explicitly specified. There may be other fields which indicate some of the more complex and specific parameters documented in [the proto-algorithm I wrote][algorithm-snippet], such as specific polarizability with sibling subjects (e.g. if rust had antagonistic sentiments toward cpp, it may have a "sibling-polarizability": { "cpp": 0.5 } field, or something similar).
A useful compact syntax to indicate the tree (for, for example, config files), might look something like the following: /programming{en:programming,en:coding,en:software-development}/language{en:language}/rust{*:rust,*:rustlang}/
This encodes the terms that it knows for these concepts, within the context of the subject above it, along with the language that term is in (star indicating many human languages where the same term is used, e.g. with proper names).
For this system to work, there must be a roughly-agreed upon set of names to use as keys.
The "subject-tree" for "general interest" is just an empty list {} ^.^
I very much approve the effort, which continues in comments explaining more of the idea. I also see great value in "the onboarding of new users to the fediverse, and discovery of groups, while hopefully distributing them across more instances for better load balancing and decentralization."
It's interesting, because I came to the rather opposite conclusion. Instead of refining the process and giving users more options, I voted for dumbing down the process and ~~giving~~ showing users less options. The (a bit provocant) proposal is: Don't let people choose their server, but choose one at random.
We have two types (and the spectrum inbetween) of people who try to join lemmy: Those who understand everything and can make an informed decision, and those who understand nothing. Group 1 already finds ways to achieve their goals. This could be eased, but it exists.
People from group 2 have a less comfortable position. They are faced with lots of technical explanations of alien concepts before making an account, before they can relate what this is all about, what impacts their decisions will have.
I feel the default way to join the fediverse should be to let the fediverse make that choice for you. The fediverse can make a random choice, or use a system with attributes and weights which you proposed.
In different aspects, a random choice can be better or worse than letting users decide, who have incomplete and sometimes inaccurate information, and do not want to spend energy on the topic.
An advanced signup method with user-defined choices should still be available. The default signup way should be big and easily visible, the advanced less prominent but still available.
I wrote a more lengthy comment on why I think signup should be as quick and easy as possible here.
My idea is meant to allow for a spectrum from simply "pick an instance for me" using the weightings for an assumed "the user is interested primarily in general discussion", to "search for an instance for me related to xyz topics as a search query", to fine-tuned discovery ^.^
The weighting is always necessary to use because it allows instances to have more control over who they accept and avoid overloading smaller instances. But you can make the default UI very simple.