this is an excellent summary of the real-life problems - moderation, discoverability, searchability - of a future federated Bluesky AT Protocol network from @jonny

https://neuromatch.social/@jonny/110552684614320107

see also

https://github.com/bluesky-social/proposals/issues/18
https://github.com/bluesky-social/proposals/issues/19

i particularly like the observation that the functions people *want* from social media - moderation, discoverability, search - just straight-up require centralisation.

Decentralisation has its virtues, such as the fediverse ticking along mostly fine while Twitter and Bluesky pooped themselves on Saturday. But for usability for non-nerds, decentralisation is a harsh antifeature - see Mastodon. You can't search your fuckin' friends, I mean wtf, FUNCTION NUMBER ONE on a new network!

Any eventual atproto network will naturally centralise on a big graph server, 'cos otherwise you don't get search or discoverability.

there isn't as yet a central repository of critiques. also the protocol isn't finished yet, there's a lotta vaporware and handwaving.

actual Trust & Safety people of considerable experience, e.g. Yoel Roth from Twitter and Denise from Dreamwidth and formerly of LiveJournal, spent many futile hours posting at length to the company CEO and devs on how Bluesky's plans would make essential moderation functions literally impossible.

even if Bluesky gave a hoot about doing moderation properly, which doesn't seem to occur to them. they seem literally incapable of understanding the question.

some of the devs are getting to understand the problems. because Bluesky pressed them into service to do moderation personally. they understood there was a problem here once they saw some shit.

but basically Bluesky wrote a moderation white paper and fell in love with it, and they are impervious to any idea they didn't think of themselves, or the history of thirty years of internet social media.

like, when you get to "let's make block lists public!" why the fuck are you doing something that obviously stupid? "well the white paper requires it" i mean.

there is no one weird trick to technically scale moderation. you have to do the fucking moderation. with people.

that's *fine* for now - there is no network. bsky.app is a fun single-node server to be on. 200k users, high quality queer shitposters, great userbase!

but it's important to keep in mind that it's *run* by rationalist neoreactionary-leaning blockchain bros who have shown an unfortunate tendency in practice to defend their neo-nazi friends from being kicked off for death threats against minorities.

the technical details are secondary, even if you approach them with an unwarranted assumption of good faith. because atproto was designed with bad assumptions by idiots. it's a historical fact that Jack Dorsey's driving motivation was to make a network nazis couldn't be permanently banned from. that's what he funded these people to do, and the tech is just details at that point.

on Mastodon, Bluesky would have been fediblocked by now just for its nazi coddling.

btw i will definitely be calling Bluesky's wizard white paper idea "compostable moderation" from now on

jonny (good kind) (@[email protected])

so far, #BlueSky / #ATProtocol seems like a federated system the same way Google Alerts is a federated system. - you can self host your website or uses Google sites. - Google crawls you - People subscribe to algos/alerts - Google Alerts emails you the matches

Neuromatch Social

@davidgerard @jonny What I would like, eventually, is a system where mod/discover/search are potentially centralized, but I have my choice of which center to select without having to pick a fundamentally different set of content. (Which opens the door to a "center" which is, like, a tree of centers.)

I doubt BlueSky is that system because I subscribe to the conspiracy theory that BlueSky was specifically designed, before it split off from Twitter, to cement the Twitter servers at the center.

@mcc @davidgerard @jonny discoverability and search are not necessarily centralized by any means. It just requires a different design to enable them in a consensual way across decentralized instances.
@anildash @mcc @davidgerard @jonny
Every time I read «discoverability and search requires centralization» I have to wonder if people failed to learn from Kademlia or are purposely ignoring that the concept of distributed search & discover has already been solved in the past, on even more distributed networks than the Fediverse.
@oblomov @anildash @mcc @jonny sounds great, so why isn't it standard here
@davidgerard @oblomov @anildash I made a toy/prototype distributed mastodon project (and the point where I skidded out *wasn't* Kademlia, that part worked great). I would tend to think of Kademlia as good for *lookup* rather than *search*. Text search is a fuzzy operation rather than one-to-one. I would think of Kademlia as a dubious choice for a full-text index because publishing a hash in Kademlia requires you to join the network multiple times, at multiple locations, once per published object
@davidgerard @oblomov @anildash So say we're imagining a search layer on Mastodon rather than on a hypothetical pure-Kademlia social network. And leave aside that the thing holding back search on Mastodon is *a consensus it is unwanted*. Imagine searching for "Mastodon". You go to the point in search space corresponding to "Mastodon". You look for peers. And you find… every single server in the Fediverse. Because they *all* host posts about Mastodon. Now what do you do?

@davidgerard @oblomov @anildash Do you spam every single ActivityPub server in existence & ask for a list of its posts containing "Mastodon"? How do you sort the results?

The most successful Kademlia deployment I know of is the BitTorrent magnet link network. That *didn't*, to my knowledge, choose to use K for *text* search. Text search was farmed to… centralized indexing services, like TPB.

If anyone EVER successfully built a full-text search prototype atop K I'd love to see that paper/blog.

@davidgerard @oblomov @anildash (Note: I'm not making any attempt to disagree with Anil's original point https://mastodon.social/@[email protected]m/110660077658528760 just, the item in the toolbox I would reach for trying to make that real is most probably not Kademlia. Especially not in the ActivityPub/Fediverse instance context where the peer trust relationship is somewhat stronger than in Kademlia's original use case.)

@mcc @davidgerard @anildash

Allow me to shy away from full-text search, because aside from the technical issue there's also, as you point out, a sizeable social aspect that is a whole different discussion, and let's focus for a moment on user and hashtag discoverability, and let's agree on the idea that rather than a pure Kademlia solution we'd want to aim at something that can work on top of the existing network without bogging it down.

1/

@oblomov @mcc @davidgerard @anildash
I don't know enough to say much about the technical implications, but I think there'd definitely be support for some sort of distributed user directory so long as it were opt-in, and easy enough to opt back out of
@ajswritesthings @mcc @oblomov @anildash yep. there's various kludges to find your twitter network or whatever, but an opt-in phone book would definitely be a feature

@ajswritesthings @mcc @oblomov @anildash may i note also: the style of thread that goes:
"lol you fools i have the obvious technical answer that nobody's implemented yet, you rubes, you simpletons"
* others detailing why this is wrong *
"well obviously I didn't mean *that*,"

is fatuous reply guy nonsense and please don't do it here

@davidgerard

I'll take the blame for that, my phrasing was obviously extremely poor (to be generous): it was intended to remark just that centralization is not a hard requirement, but it obviously came out as suggesting we should be using Kademlia specifically, which wasn't the intention.

@ajswritesthings @mcc @anildash