sunbeam.city is one of the many independent Mastodon servers you can use to participate in the fediverse.
Sunbeam City is a anticapitalist, antifascist solarpunk instance that is run collectively.

Administered by:

Server stats:

105
active users

appreciated @pluralistic line of not wanting to join a platform without credible freedom of exit (pluralistic.net/2024/11/02/uly)

but also from other sources it seems to me like bluesky does have credible freedom of exit just with a different architecture than activity pub? (e.g. fediversereport.com/a-conceptu by @fediversereport and whtwnd.com/alexia.bsky.cyrneko)

also this reference to someone setting up their own relay to mimic the bluesky relay bsky.app/profile/alice.mospher which is the most expensive infra to replicate current bluesky

curious what people see as the obstacles to credible freedom of exit?

pluralistic.netPluralistic: Bluesky and enshittification (02 Nov 2024) – Pluralistic: Daily links from Cory Doctorow

@pluralistic @fediversereport

interesting set of criticisms to credible freedom of exit here from @jonny here neuromatch.social/@jonny/11336

mostly about the messiness of multiple relays, even if another relay is technically possible

Neuromatch Socialjonny (good kind) (@jonny@neuromatch.social)Content warning: long, bsky, atproto, on the impossibility of multiple relays
notplants

there is a lot going on here that im still trying to wrap my head around

but the fact that an organization other than bsky could spin up a new relay and app view which reads from all the same pdses as the original plus additional ones still seems to me like a significant form of freedom of exit

even if other labellers, feed generators and services that worked with the original wouldn't be cleanly portable with the new relay+appview

like I think @bnewbold describes here sunbeam.city/@bnewbold@social.

my reading is that the messiness @jonny describes would be about having feed generators or other intermediate/bonus infrastructure that work with multiple relays?

if you are ok with the alternative relay+appview just sharing data with the old network, but not feed generators and labelers etc., then my understanding is the messiness would not apply and people using the old and new/alternative appview could still interact in a sane way? unless im missing something?

summarized by @bnewbold here (sunbeam.city/@bnewbold@social.):

> "rent" requires ability to "exclude" which isn't possible with fully public data

and the pds at the bottom of the stack are fully public data

relays, feeds, appviews, etc. are all on top of that

the metaphor to the internet makes sense to me, also because the tier 1 internet does require infrastructural investments that are larger than an individual can make, but still is decentralized beyond the control of any one organization or company

@notplants @bnewbold was just about to link jonny's thread 😁

But i think in the end, we only know independent instances are possible once we see them

@powersource @bnewbold

agreed a real-world running app/appview that sanely interacts with the current network but doesn't use any bsky infra other than some of the pdses it pulls from, would be more convincing than any essay or theory

alice.bsky.sh/post/3laega7icmi

alice.bsky.shHow to self-host all of Bluesky except the AppView (for now) — alice.bsky.shby Alice · 3 min read

@notplants @jonny
by default (and by design), labelers and feed generators work fine across any other infra like relays or appviews. labelers and feedgens reference DIDs and AT-URIs (global scope), and can be consumed/requested by any client.

that sort of assumes that all relays are "full network". a feedgen blocking or only subscribing to a subset of network would only "see" and reference content from that sub-set, similar to "defederation" in fedi. but atproto default is full-network