cross-posted from: https://kbin.social/m/tech/t/364852

Anti-piracy group Rights Alliance removed the prominent "Books3" database, that was used to train high profile AI models.

Or is it just me ;p

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 {} ^.^

PART 2

I strongly encourage instance admins to defederate from Facebook/Threads/Meta.

They aren't some new, bright-eyed group with no track record. They're a borderline Machiavellian megacorporation with a long and continuing history of extremely hostile actions:

• Helping enhance genocides in countries
• Openly and willingly taking part in political manipulation (see Cambridge Analytica)
• Actively have campaigned against net neutrality and attempted to make "facebook" most of the internet for members of countries with weaker internet infra - directly contributing to their amplification of genocide (see the genocide link for info)
• Using their users as non-consenting subjects to psychological experiments.
• Absolutely ludicrous invasions of privacy - even if they aren't able to do this directly to the Fediverse, it illustrates their attitude.
• Even now, they're on-record of attempting to get instance admins to do backdoor discussions and sign NDAs.

Yes, I know one of the Mastodon folks have said they're not worried. Frankly, I think they're being laughably naive >.<. Facebook/Meta - and Instagram's CEO - might say pretty words - but words are cheap and from a known-hostile entity like Meta/Facebook they are almost certainly just a manipulation strategy.

In my view, they should be discarded as entirely irrelevant, or viewed as deliberate lies, given their continued atrocious behaviour and open manipulation of vast swathes of the population.

Facebook have large amounts of experience on how to attack and astroturf social media communities - hell I would be very unsurprised if they are already doing it, but it's difficult to say without solid evidence ^.^

Why should we believe anything they say, ever? Why should we believe they aren't just trying to destroy a competitor before it gets going properly, or worse, turn it into yet another arm of their sprawling network of services, via Embrace, Extend, Extinguish - or perhaps Embrace, Extend, Consume would be a better term in this case?

When will we ever learn that openly-manipulative, openly-assimilationist corporations need to be shoved out before they can gain any foothold and subsume our network and relegate it to the annals of history?

I've seen plenty of arguments claiming that it's "anti-open-source" to defederate, or that it means we aren't "resilient", which is wrong ^.^:

• Open source isn't about blindly trusting every organisation that participates in a network, especially not one which is known-hostile. Threads can start their own ActivityPub network if they really want or implement the protocol for themselves. It doesn't mean we lose the right to kick them out of most - or all - of our instances ^.^.
• Defederation is part of how the fediverse is resilient. It is the immune system of the network against hostile actors (it can be used in other ways, too, of course). Facebook, I think, is a textbook example of a hostile actor, and has such an unimaginably bad record that anything they say should be treated as a form of manipulation.

Edit 1 - Some More Arguments

In this thread, I've seen some more arguments about Meta/FB federation:

• Defederation doesn't stop them from receiving our public content:
  • This is true, but very incomplete. The content you post is public, but what Meta/Facebook is really after is having their users interact with content. Defederation prevents this.
• Federation will attract more users:
  • Only if Threads makes it trivial to move/make accounts on other instances, and makes the fact it's a federation clear to the users, and doesn't end up hosting most communities by sheer mass or outright manipulation.
  • Given that Threads as a platform is not open source - you can't host your own "Threads Server" instance - and presumably their app only works with the Threads Server that they run - this is very unlikely. Unless they also make Threads a Mastodon/Calckey/KBin/etc. client.
  • Therefore, their app is probably intending to make itself their user's primary interaction method for the Fediverse, while also making sure that any attempt to migrate off is met with unfamiliar interfaces because no-one else can host a server that can interface with it.
  • Ergo, they want to strongly incentivize people to stay within their walled garden version of the Fediverse by ensuring the rest remains unfamiliar - breaking the momentum of the current movement towards it. ^.^
• We just need to create "better" front ends:
  • This is a good long-term strategy, because of the cycle of enshittification.
  • Facebook/Meta has far more resources than us to improve the "slickness" of their clients at this time. Until the fediverse grows more, and while they aren't yet under immediate pressure to make their app profitable via enshittification and advertising, we won't manage >.<
  • This also assumes that Facebook/Meta won't engage in efforts to make this harder e.g. Embrace, Extend, Extinguish/Consume, or social manipulation attempts.
  • Therefore we should defederate and still keep working on making improvements. This strategy of "better clients" is only viable in combination with defederation.

PART 2 (post got too long!)

(I don't know if crossposting is possible on lemmy yet, this is from !technology@beehaw.org)

I think this a good example of the true power of open source and open research to accelerate technological advancement. My suggestion for projects: make it as easy and modular as possible so the maximum number of improvements can be made in parallel.