Content pfp
Content
@
0 reply
20 recasts
20 reactions

agusti πŸ˜πŸ”΅ pfp
agusti πŸ˜πŸ”΅
@bleu.eth
hey @v @horsefacts.eth doesn't this point by @vrypan.eth even accentuate more with now compose-actions also on the mix alongside frames? thoughts on reviving this spec? https://github.com/farcasterxyz/protocol/discussions/123#discussioncomment-9034815
3 replies
2 recasts
7 reactions

agusti πŸ˜πŸ”΅ pfp
agusti πŸ˜πŸ”΅
@bleu.eth
maybe big bois browsers won't, but other dapp-like browsers like @mikedemarais.eth rainbow, or others, could do so more fast, alongside all the alt-clients like supercast, wildcard, recaster, fiids, etc etc
1 reply
0 recast
3 reactions

horsefacts pfp
horsefacts
@horsefacts.eth
Supportive in broad principle, but there are a lot of specific details that need careful thought: What entities belong in the scheme? Do deep links to behaviors (compose, follow) rather than data make sense and are these fully baked and universal enough to include? How can the scheme change over time, so we don't break old URLs? Only one app can register a protocol handler like farcaster:// at a time. How do we handle this? Protocol handlers are notoriously annoying on mobile. Would it be better to introduce a shared public good domain like farcaster dot link that could serve a fallback page? All of these need good answers, and I come up with new ones every time I think about this one. But that doesn't mean we shouldn't do it, just that we need to figure it out.
2 replies
0 recast
1 reaction

Starllium pfp
Starllium
@benya
So what next for now
0 reply
0 recast
0 reaction