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

[cwebber@social.coop]

Now the reality is that "message passing" is hardly a new term

As far as I know though, I did introduce the term "shared heap"

I didn't know what else to call it! Wait actually no that's not actually fully true

[cwebber@social.coop]

If I was going to refer to the CS literature I would probably say that "ActivityPub uses an actor model style approach whereas ATProto uses a global, public, shared tuplespace"

But I wanted the mail metaphor to work and I was pretty sure everyone's eyes would glaze over at "tuplespace"

[cwebber@social.coop]

Anyway, language is this messy squishy thing but part of the success of the previous post I think was terms that allowed us to discuss differences clearly.

(And it is EXACTLY for that same reason that I am gonna dive into analyzing terminology deeper in just a little bit.)

Moving on...

[cwebber@social.coop]

Let's talk about some acknowledgement of scaling expectations, starting with this terminology, happened in @bnewbold's response because I think it's very helpful!

(BTW whenever I quote something with ">" in this thread, if I don't otherwise specify, I'm quoting @bnewbold)

[cwebber@social.coop]

> Other data transfer mechanisms, such as batched backfill, or routed delivery of events (closer to "message passing") are possible and likely to emerge. But the "huge public heap" concept is pretty baked-in.

Okay this is helpful. This sets expectations. This is good to acknowledge.

[cwebber@social.coop]

> Given our focus on big-world public spaces, which have strong network effects, our approach is to provide a "zero compromises" user experience. We want Bluesky (the app) to have all the performance, affordances, and consistency of using a centralized platform.

This is also good to acknowledge.

[cwebber@social.coop]

> So, yes, the atproto network today involves some large infrastructure components, including relays and AppViews, and these might continue to grow over time. Our design goal is not to run the entire network on small instances.

Okay yes, yes this is good to ack

[cwebber@social.coop]

> It isn't peer-to-peer, and isn't designed to run entirely on phones or Raspberry Pis. It is designed to ensure "credible exit", adversarial interop, and other properties, for each component of the overall system.

Good okay thank you

[cwebber@social.coop]

> Operating some of these components might require collective (not individual) resources.

Hm okay, this is also good. Okay remember this sentence. This sentence is gonna be really important in just a minute.

[cwebber@social.coop]

But before we get there oh hey, when I wrote my last blogpost I said "whoa in just 4 months storage expectations jumped from 1TB to 5TB. I bet in a month it'll be double, at least 10TB."

Whoops I underestimated, @bnewbold says in his post it's now at least 16TB. Growin' fast!

[cwebber@social.coop]

@bnewbold also mentions new initiatives like Jetstream and other tooling that provide a lighter experience

well, and that's true! ... though that's done by weakening the "zero compromises experience" quite a bit if you wanted to use them to "self host", more on that later

[cwebber@social.coop]

Now okay remember when I said "this sentence is gonna be important"

You've forgotten it already?

Okay fine I'm gonna quote it again

> Operating some of these components might require collective (not individual) resources.

Okay don't forget it this time! Don't forget it!

[cwebber@social.coop]

> This doesn't mean only well-funded for-profit corporations can participate! There are several examples in the fediverse of coop, club, and non-profit services with non-trivial budgets and infrastructure.

This is certainly true on the fediverse, I am hosted by a co-op. Thank you social.coop

(@bnewbold is also on social.coop!)

[cwebber@social.coop]

> Organizations and projects like the Internet Archive, libera.chat, jabber.ccc.de, Signal, Let's Encrypt, Wikipedia [...], the Debian package archives, and others all demonstrate that non-profit orgs have the capacity to run larger services.

Wait a minute hold on

[cwebber@social.coop]

> Many of these are running centralized systems, but they could be participating in decentralized networks as well.

no wait but wait back up hold on what was that list again

[cwebber@social.coop]

Ok, XMPP and IRC are mostly ephemeral text and I love them, but let's be honest, they're pretty niche and on the decline

I've just... wait a minute we've got to look at some of the org choices here

[cwebber@social.coop]

What are the annual budgets of these FOSS service-hosting orgs?

- Wikimedia: $178 million/year
- Signal: $50 million/year
- Let's Encrypt/ISRG: $7 million/year
- Internet Archive: $25 million/year

This is public information, you can look this up! Read their 990s.

[cwebber@social.coop]

This is all to say, this is not your neighborhood block getting together to pitch in a few bucks to help out their FOSS friends

These are great orgs and compared to large for-profits, these orgs are efficient and use their money well

But these are SIZABLE hosting costs, and NOT easy to fundraise

[cwebber@social.coop]

I say this, by the way, as an Executive Director of a FOSS nonprofit with a much smaller budget and also oh god I hate fundraising I promised myself I would never do a fundraising job again why am I doing this

Did I mention we're doing a fundraiser? https://spritely.institute/donate/

Just sayin' ;_;

[cwebber@social.coop]

People worry about wasteful funding, and right now FOSS organizations are losing many of the funding sources they have. Project 2025 specifically targeted taking the incredibly small amount of money that FOSS orgs get from governments

Fundraising is the worst and it's so hard to fund anything