Cross platform notifications just shipped on Yup mobile for Farcaster and Bluesky. Very interesting tech lift on backend. Farcaster events are streamed directly from our own Farcaster Hub; and Bluesky events from ATProto server using repo sync.
How are you thinking of handling user interactions with pruned data (e.g reply / reaction to pruned cast). Or will this just be for read / display purposes
Similar. More like 1.5-2 hrs for baby bc drive to/from daycare. No gym + shower bc do that at night. Rest of time is breakfast, planning day, + reading news
When I was a kid, Taco Bell had a game where if you could land a coin on bottom lever you’d win an item on menu. Noticed if you gently shake column it’s much easier to win. Could get entire meal for 40c. I won almost every time and ended up getting rate limited to 1 try per day.
Yeah they’ve been doing this for weeks https://warpcast.com/vern/0xb0c37e
Less appealing when using diff languages. But could work. Most benefits in my experience have come from easy code sharing between apps in same language using shared locally linked packages.
We use monorepo for our nodejs backend code with turborepo. Multiple services with shared utils + models. Single, unified CI flow for automated builds and deploys. Major benefits imo
Same as in v1 actually. It accepts content uri similar to ERC721s. IPFS /Arweave most common
Potential flow would be: 1) client generates key pair and publishes pub key 2) app signs message and adds signature before publishing to hub 3) external clients index message if signature came from client in whitelisted client list
Idea comes from pain point with indexing content from Lens. We selectively index content posted from more reputable clients (Phaver/Orb/Lenster), but no way to verify content was actually published from either of those apps.
Fc is on other end of spectrum, so different challenges. But from that list I would say app signatures. Provides trustworthy way of verifying that a message came from trusted client, which is helpful for mitigating spam and filtering out messages from malicious or low quality clients.
Fleshed this out a bit more here: https://warpcast.com/vern/0x0c4899
Summary of my initial thoughts on Lens v2 (Bonsai): https://autumn-provelone-3d8.notion.site/Thoughts-on-Lens-v2-Bonsai-c75176e2e1b043d18141da5d84fd8f84
Great idea. Think it should be easily extendable. Should be straightforward to add support for other dbs. Also should provide individual tables for each data type (casts, reactions, users) instead of just messages. Full commentary here: https://github.com/farcasterxyz/hub-monorepo/issues/855#issuecomment-1524269626
Alchemy has transfers api which could work https://docs.alchemy.com/reference/alchemy-getassettransfers
The big difference here is that if user's want the composability of EVM (e.g., having posts be NFTs) they can, but it's optional -- not the default. That's a step in the right direction
The new architecture is orders of magnitude cheaper and more performant because it's leverage Arweave/Bundlr rather than broadcasting every tx to Polygon directly. Benefit is they inherity the strong CR + DA guarantees of Arweave/Bundlr, while reducing costs + latency.
Tx data is submitted to Arweave (using Bundlr) for data availability, which is much cheaper and faster than using polygon. Data availability guarantees of Bundlr /Arweave >>> than Farcaster hubs, since hub network is not actually BFT. Smart design choice imo
Note: tx is never actually broadcast to polygon chain, just verified using eth call
It’s not using optimistic rollup tech at all actually. All that’s happening is 1) users sign polygon tx 2) tx is submitted to Arweave using bundlr for data availability 3) tx is simulated / backrun against Lens contract on polygon using eth_call to verify tx would’ve succeeded if actually submitted to chain