appreciated @pluralistic line of not wanting to join a platform without credible freedom of exit (https://pluralistic.net/2024/11/02/ulysses-pact/)
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. https://fediversereport.com/a-conceptual-model-of-atproto-and-activitypub/ by @fediversereport and https://whtwnd.com/alexia.bsky.cyrneko.eu/3l727v7zlis2i)
also this reference to someone setting up their own relay to mimic the bluesky relay https://bsky.app/profile/alice.mosphere.at/post/3l47yhps2xv2c which is the most expensive infra to replicate current bluesky
curious what people see as the obstacles to credible freedom of exit?
interesting set of criticisms to credible freedom of exit here from @jonny here https://neuromatch.social/@jonny/113365406995624763
mostly about the messiness of multiple relays, even if another relay is technically possible
a bunch of interesting threads
https://neuromatch.social/@jonny/111888891521803177
https://neuromatch.social/@jonny/111894977725231814
https://neuromatch.social/@jonny/110552684614320107
https://neuromatch.social/@jonny/110556286778731619
https://neuromatch.social/@jonny/110556366757290063
https://neuromatch.social/@jonny/110556785385381233
https://neuromatch.social/@jonny/110556351312942422
https://progressives.social/@chargrille/110664052201408190
https://neuromatch.social/@jonny/110664431439742088
https://neuromatch.social/@jonny/113365455504345298
https://sunbeam.city/@jdp23@gotosocial.thenexus.today/113381744654714928
and interesting engagement with this from @bnewbold from bsky https://sunbeam.city/@bnewbold@social.coop/113380830904470229
https://sunbeam.city/@bnewbold@social.coop/113370827301356469
https://social.coop/@bnewbold/113371001659288754
https://sunbeam.city/@bnewbold@social.coop/113370980535586704
https://sunbeam.city/@bnewbold@social.coop/113371016707638902
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 https://sunbeam.city/@bnewbold@social.coop/113380830904470229
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 (https://sunbeam.city/@bnewbold@social.coop/113370827301356469):
> "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
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
@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