> However, I disagree with some of the analysis, and have a couple specific points to correct.

[cwebber@social.coop]

Before we get deep into that, when we left last night I was extremely tired and had been working at my computer for over 14 hours. I then said I was going to drive two hours across the state that evening.

Thankfully thanks to the support of people who love me, I did not do that foolish thing!

[cwebber@social.coop]

So anyway, I am better rested, and also I woke up to the surprise that our fundraiser is doing a lot better, like by a lot, than it was yesterday, which is nice because I was extremely stressed out https://spritely.institute/donate/

So I am feeling much better and alive and today I remembered to eat lunch

[cwebber@social.coop]

But you probably aren't here to hear about my lunch choices or how much sleep I got or whether or not I forgot to bring my ADHD medication with me (I did so now I am drinking a bunch of caffeine instead), you are probably here to hear the rest of the analysis about decentralization and Bluesky etc

[cwebber@social.coop]

So let us get to it, let's talk about whether or not Bluesky can scale *down* in a meaningful way.

In my last essay I made assertions that this was important for decentralization and said ATProto wasn't great for this, and this was one thing people challenged me on

So let's take a look!

[cwebber@social.coop]

When I say "scale down", what I generally mean is "small instances can generally participate on the network". (We'll talk about "scale wide" later.) But another useful possibility which has come up is "can you make a smaller, more isolated use-case and use the same protocol for it"

[cwebber@social.coop]

This latter version of scale down does come up in Bryan's article:

> A specific form of scale-down which is an important design goal is that folks building new applications (new Lexicons) can "start small", with server needs proportional to the size of their sub-network.

(cotd)

[cwebber@social.coop]

Strictly speaking, I agree, ATProto can scale down in this use case! For example, if you wanted to make a small specialized forum for collaborative storytelling, you could use ATProto for it, and that's true, you could do it

But is it the right choice?

[cwebber@social.coop]

In some ways we are talking about two different things here: extension of functionality (which you might want the same scale for) and having a smaller and more isolated community

But regardless

[cwebber@social.coop]

ATproto positions itself *specifically* as designed for not wanting to miss messages, and I talked previously about how ATProto's design requires a god's-eye view.

It's a bit strange of a choice when you say "let's run a smaller community"

[cwebber@social.coop]

Given that message passing systems handle small scale systems *beautifully*, and *still* allow for interactions with larger scale systems, it's a bit confusing to me *why* you'd choose ATProto for such use cases. What is the specific benefit you'd gain? Especially because it's actually lossier here

[cwebber@social.coop]

At any rate, there's a bit of conflation here. "It scales down" by saying "you can have an isolated community/use case that's oblivious to the rest of the system" is categorically distinct from "it scales down" in terms of "a small node can meaningfully participate with the larger system"

[cwebber@social.coop]

At any rate, the problem with "scaling down" is much clearer when it comes to the problem of "scaling wide".

Or let me put it a different way: ATProto *explodes in complexity* when you try to scale it towards meaningful decentralization

[cwebber@social.coop]

Yes that's right we're getting to the spicy part of this conversation. We did the warm-up, now it's time to talk about the real thing, whether or not decentralization in the way I believe people *think* that term means is reasonably possible with ATProto as it's currently designed

[cwebber@social.coop]

But before we do that, I need to stretch and run to the bathroom

So for those of you following along, if you found this, Secret Goblin #3, let me know: ""

Oops wait actually we gotta talk about that one for a sec there's a reason I left it in scare quotes

[cwebber@social.coop]

Why on earth is the textual descriptor for Unicode U+1F47A "JAPANESE GOBLIN", does anyone know?

It's a Tengu, right?

Despite being the only actually named "goblin" emoji, I feel awkward about this one because is it correct to call it a "JAPANESE GOBLIN" instead of just "TENGU"?!?!

I don't know!

[cwebber@social.coop]

If you have knowledge or OPINIONS about "", its name choice in unicode, or, for that matter, a white person just dropping it in the middle of a group chat WITHOUT putting it in quotes (I did tho), feel free to derail the comment thread

Otherwise it's time for a

=== STRETCH BREAK ===

[cwebber@social.coop]

I'm back. It's time to talk about it: does Bluesky/ATProto suffer a "quadratic explosion" as we move from centralization towards *meaningful* decentralization?

I claimed it did, but I was challenged on this. What did I mean? Am I right or wrong?

It's time to find out!

[cwebber@social.coop]

In the previous blogpost I said the following:

> If this sounds infeasible to do in our metaphorical domestic environment, that's because it is. A world of full self-hosting is not possible with Bluesky.

(cotd)

[cwebber@social.coop]

Decentralized ATProto is quadratic quote, cotd:

> In fact, it is worse than the storage requirements, because the message delivery requirements become quadratic at the scale of full decentralization: to send a message to one user is to send a message to all. Rather than writing one letter, a copy of that letter must be made and delivered to every person on earth.

[cwebber@social.coop]

This was probably the thing I got the hardest pushback on from a team member of Bluesky, that it is not quadratic as we scale towards decentralization.

Truth be told, I don't have a degree in CS. Most of what I know I learned from studying independently and community resources. Was I wrong?