@cassie

Something was said on the community call today by neynar team that didn't sit right with me, and it shouldn't sit right with you either. They asked me why I am pushing for a hypersnap node to be a validator, why not just fork? And when I said I'd answer it in three points, before I could even complete the first point, I was interrupted repeatedly, and they attempted a gotcha question, which failed, but I'd like to clear the air of the misinformation at play. The first point was: our goal is to help farcaster grow. Part of that, is that clients cannot today meaningfully use snapchain to build a client. You need an indexer, or you have to pay a service provider, like neynar, to be that indexer. Before I could elaborate further, or get to the other two points, they attempted to "gotcha" me by saying "but quorum isn't using hypersnap apis, it's using the merkle apis". This is not true. We use both. And to prove that, we have updated the public source of the Quorum implementation so you can see for yourself: https://github.com/quilibriumnetwork/quorum-shared (this contains the hypersnap and merkle api usage) https://github.com/quilibriumnetwork/quorum-mobile (the mobile app) And if they would have let me finished instead of trying to railroad me, I would have clarified completely. We use merkle apis for farcaster dms, because they're not on protocol. We use merkle apis for importing user wallets, because they're using a proprietary setup with privy. We use merkle apis for channel info, because this doesn't live on protocol either. And, we have failover for everything else, because there's no sense in ruining user experience if something goes wrong. But point two, which I was able to briefly allude to in the call, is that Quorum is a _privacy-focused_ client. This means that we give a shit about user safety. This means: no analytics, every possible measure to never even see user data, and enhanced features like E2EE DMs, group chats (which _don't_ interface with merkle apis), voice and video calls, a privacy-preserving wallet api, and a few other important details. But I want to focus on one of the smaller details, because that was part of their attempted gotcha - the use of merkle signers. Clients have an app identifier, in the form of an FID. This FID indicates, whenever you post, where your post came from. It's how the "sent from base app" appeared under posts, and it's how we identified the attacks came from schedly being exploited months ago. Quorum doesn't have an app FID, because people who seek out privacy apps are in many countries, identified as a risk, and in some countries in particular, literally get murdered over it. By using the merkle signer, it _hides_ the fact the user is using Quorum. I have mentioned this many times before, but either they forgot or thought they could somehow use it to imply something else. That said, as now snapchain and hypersnap have the new signer FIP, there's a middle road, where users can create signers of their own, on protocol, and it indicates nothing. Some users may still have high caution and concern, so like all of our features, we give the user a choice to opt in to this, despite the low risk, rather than simply choose that path for them. If they choose not to opt in, then they continue using merkle signers. Before I could get any further, I was again derailed. So finally, point three: Being a validator is a commitment – one we take so seriously, that I was the first who even proposed running a separate validator outside of _Merkle and Neynar's ownership_ (this was proposed prior to the acquisition). We want to see farcaster succeed together, and by making that commitment, we are handcuffing ourselves to compatibility. And after some handwaving about variables that they couldn't actually prove or disprove, a point was made – if they are willing to trial things out on testnet with _regular_ snapchain nodes, then there should be _ZERO_ objection to trialing things on testnet with a hypersnap node as a peer. There was no formal commitment to accepting this, merely verbal, and I await them explicitly agreeing to do so before spending the money to run a testnet node to verify what I already know – we are compatible and there are zero latency implications as a validator running hypersnap when communicating with snapchain. But they have to meet us halfway. They have to actually extend the hand and commit to do this with us. And a good start would be to stop treating the one remaining original dev of snapchain like shit just because she disagrees and argues against claims that are not backed by evidence. The ball's in their court, but you can see for yourself that they are not being honest. Timestamp 47:27 for context: https://www.youtube.com/watch?v=2fJIJceE2R4

13 replies

26 recasts

99 reactions