shazow pfp
shazow
@shazow.eth
How can open social protocols fail us? I put together an analysis comparing several specific failure modes between Farcaster, Bluesky, and Mastodon. Please let me know if any of the protocol descriptions could be presented more fairly! https://shazow.net/posts/open-social-2025/
8 replies
8 recasts
27 reactions
androidsixteen pfp
androidsixteen
@androidsixteen.eth
Great read, small typo `shazow.bsky.socialf` What is your recommendation for people who are looking to invest / commit to an open social protocol -- which would you recommend (could be more than one), and where would you deploy resources to improve that protocol?
1 reply
0 recast
0 reaction
shazow pfp
shazow
@shazow.eth
Pushed a fix, ty! My fav thing about Farcaster is the sovereign ID, onchain key management, and native payments/onchain operations. My fav thing about Bluesky is ATProto and the layered architecture that can be scaled separately (DID -> PDS -> Relays -> AppView). It's a controversial take but I suspect there is a "better than the sum of its parts" synthesis here! It would be a far smaller change to bring Farcaster to a mostly-Bluesky-compatible ATProto than the reverse. Think of it like Threads coming to Mastodon: https://warpcast.com/shazow.eth/0xd76e8ff3 That said, if I were to "invest" long term, I'm not very bullish on public global social feeds. On a 10+ year timescale, my bet would be on new kinds of private group chats that cross-pollinate and publish public byproducts. My fav things about Farcaster are likely still relevant here!
1 reply
0 recast
1 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
1. Why on Earth did I find this thread 4 months later? :-) 2. Re: "new kinds of private groups", what do you think about this? https://blog.vrypan.net/2024/06/26/farcaster-l2/
2 replies
0 recast
1 reaction
shazow pfp
shazow
@shazow.eth
Finally got a chance to read! Sounds a lot like ATProto's lexicon namespaces? Except the bundles are aggregated/immutable, which I think loses some utility of shared relay infrastructure. (An "L2" would need to run its own infra, at which point I'm not sure why Farcaster needs to be involved? There's no "inherited security" or atomicity benefits of being a based rollup, right?) High level, I think this is a design flaw of the Farcaster protocol: Everything is assumed to be in the main namespace and always "alive", there's no notion of segmenting namespaces and there's no notion of immutable archives. For example, say we take your sports app scenario but instead apply it for archiving casts. Anything more than 90 days old gets "rebundled" into an immutable archive, freeing up "alive storage" that is otherwise more expensive. I think this is a fine idea but it would break today's assumptions and I think it's culturally opposed to what Farcaster leadership wants this to be. (Maybe I'm wrong?) I guess high level, it's not clear to me what the "layer" relationship is between the L1 and L2 here. To me it sounds more like an "offchain"/"onchain" relationship, rather than a rollup-style relationship. But considering it from a consumer/builder perspective: Say I'm making an "offchain" live sports for realtime chatting, leveraging the Farcaster social graph... why would I even post it back onto Farcaster after at all? Who benefits?
1 reply
0 recast
0 reaction
shazow pfp
shazow
@shazow.eth
To be clear, the advantage of doing this in ATProto using a custom lexicon namespace is you get to reuse all the same relay infrastructure. In effect, you don't have to run the equivalent of a full hub to add some custom functionality feed for your own app.
2 replies
0 recast
0 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
> Say I'm making an "offchain" live sports for realtime chatting, leveraging the Farcaster social graph... why would I even post it back onto Farcaster after at all? Who benefits? You actually make it easy for me (an other app) to fetch this content and show/use it too. We currently have apps that use the fc social graph, like dracula, zora (at least it used to do so), etc. How do I get access to their content as an app dev? How can I be sure that if they decide to shut down, I can preserve my content? L2s would solve both problems.
0 reply
0 recast
1 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
The way I see it, Forecaster's core features is identity and social graph. Casts are a nice feature, but they are a feature that could have been implemented on top of Farcaster, just like direct casts are implemented on top of Farcaster. In a way, the L2s I describe are an alternative implementation of casts, not stored on Snapchain (was written before snapchain, but the idea is the same). The L2 inherits L1 security in the sense that a delta submitted to an L2 must be valid in L1 (a valid signer, valid signature, etc). You could say they are off-chain messages, that can be submitted at any time to L1 if you like (or moved to an other L2). You also get a proof that the bundle has been included in the L2, because its hash is submitted to L1 (using BundleAdd). Yes, you will have to run your infra, but you get the hardest parts for free (identity, authentication, social graph). Storing content (casts, reactions) is the easiest part, and trivial to implement imo.
0 reply
0 recast
1 reaction