Jason Goldberg Ⓜ️ 💜
@betashop.eth
I woke up this morning in Tokyo to 2 casts from @dwr.eth regarding future of Farcaster As a developer building on Farcaster, I found them to be a bit contradictory, unsettling, & overly defeatist. Farcaster has been building a solid foundation for a strong future. That future is dependent on app... longcast.jam.so/jjcJMh
17 replies
3 recasts
9 reactions
Greg
@greg
fwiw I think some of this is asking too much of the Merkle team, specifically “Dan, Varun and team should post regularly from Jam and Discove and other FC apps, actively promote them” “WC team pledge not to introduce any new features that are not available in the protocol”
4 replies
0 recast
3 reactions
Jason Goldberg Ⓜ️ 💜
@betashop.eth
I think it’s completely fair to ask protocol developers to actively support the ecosystem apps built on the protocol, much like Vitalik makes a point of using Ethereum apps Dan’s post was a screenshot essay - it could have been a longcast on jam. It’s not that he has to make jam his... longcast.jam.so/jjZoIC
2 replies
0 recast
0 reaction
osama
@osama
i’ve said this before: jamcasts are walled garden behaviour. it could be rendered long cast within jam but then for interop it should be posted to protocol as either thread or screenshot essay. I don’t use Jam and it’s annoying to goto external links to read something
3 replies
0 recast
0 reaction
Tayyab - d/acc
@tayyab
Eh I think it’s a fair growth tactic. As long as he uses the protocol, he can choose what he does, and nothing is stopping other clients from adopting longcasts… as I believe it’s an ipfs linked file.
1 reply
0 recast
0 reaction
timdaub
@timdaub.eth
Na I think it‘s fine to read on jam actually
0 reply
0 recast
0 reaction
MOLO
@molo
completely agree. I assumed longcasts were text split into casts and concatenated and was surprised they are kept as separate entities. results in a lot of content being kept off-protocol
1 reply
0 recast
0 reaction
