Email or username:

Password:

Forgot your password?
Top-level
katzenberger

@MastodonEngineering

Despite this being promoted as supporting multiple "discovery providers", the text says »This will specify how an instance will “feed” content to a discovery provider to index. And how a discovery provider can be queried to actually search and discover content.«

Nothing is being said about why there would ever be a need for a more than a few big providers, once it is established that the big ones "work". As usual, centralization is looming here, by a few corps "generously" offering high-speed "discovery" for "free".

Also, nothing is said about providers sharing results of the indexing, to enable fediverse-wide search - instead, the proposal almost inevitably points to few providers that everybody needs to feed if they want posts to be found.

"Hope" will not change that hence just saying »We want to specify how a discovery provider works and interfaces with a Fediverse server instance. We hope to inspire several competing implementations of the specification.« does not make much sense.

Nothing is said about who outside of the Fediverse gets to query a provider, or to process the data that has been extracted from a fediverse server feed - and for which purposes. It's even expressly mentioned that »These “providers” might serve other purposes than just search and discovery«

»The protocols and implementations will respect user privacy«, but the text only offers "shoulds":

-

»Our reference implementation will respect this setting and only ingest content from creators who opted in to discovery in the first place.« (note the telling words "respect" and "ingest" here, it does not even seem consensus that providers are "fed" by Fediverse servers).


-

»All other information a discovery provider gathers should be anonymous.« Should?


-

»Fediverse Discovery Providers should only ever index content clearly marked as “public”.« Should?


-

»Fediverse Discovery Providers should honor these settings and only index user data and content from users who have opted-into that.« Should?

Another red flag: »This means we might not always be able to incorporate all the feedback we get into the very first draft of everything we publish. But rest assured that we are committed to continue working on this even after this first project has ended, so we will be able to make adjustments later on.«

More privacy after the first implementation is out? And no: With Mastodon gGmbH being the driver of this, and with the current wording, we can not "rest assured".

@EC_NGI

3 comments
ophiocephalic 🐍

@katzenberger
"Nothing is said about who outside of the Fediverse gets to query a provider, or to process the data that has been extracted from a fediverse server feed - and for which purposes."

The fact that the referenced passage links to a blog post about third-party data collection and algorithmic contraband media detection might provide a clue

katzenberger

@ophiocephalic

Another clue there: »Why external providers?

As it stands, scaling a Mastodon instance is hard, as the operators need to form a moderation team with 24/7 availability and good reaction times, learn about all the specific vectors for abuse and common issues, design guidelines and more.«

Their problem is "scaling". Self-inflicted pain from running behemoth servers that are counter to the core idea of the Fediverse, and from deliberately tilting the Mastodon "joining" process so that their own behemoth keeps growing.

@ophiocephalic

Another clue there: »Why external providers?

As it stands, scaling a Mastodon instance is hard, as the operators need to form a moderation team with 24/7 availability and good reaction times, learn about all the specific vectors for abuse and common issues, design guidelines and more.«

ophiocephalic 🐍

@katzenberger
Exactly. The "trust and safety" proposal in the older post is effectively for mastodon.social. So it's rather curious that it's being pointed at in a different proposal which is seemingly about improving search and discovery for smaller instances

Go Up