[keyserver] accept webhook cast created events tagging comm
Needs RevisionPublic
Actions

Authored by will on Sun, Oct 20, 9:52 PM.

Details

Reviewers

ashoat
varun

Summary

Implement initial taggedCommFarcasterResponder with dummy logic

Depends on D13701

Test Plan

Triggered webhook event on warpcast and successfully received created cast event which passed validation

Repository

rCOMM Comm

Lint

No Lint Coverage

Unit

No Test Coverage

keyserver/src/responders/farcaster-webhook-responders.js
17	This is a dummy statement. This will be removed in a future diff and replaced with relevant logic
lib/types/farcaster-types.js
65	Originally tried to using `NeynarChannel` for this but backtracked as it meant loosening constraints. The webhook event neynar channel object does not include description, follower_count, and lead

will requested review of this revision.Sun, Oct 20, 10:09 PM

ashoat requested changes to this revision.Mon, Oct 21, 8:54 AM

ashoat added inline comments.

keyserver/src/responders/handlers.js
129	What's the point of this line? Seems like we could just spread `responderResult` directly on line 130
lib/types/farcaster-types.js
45–75	3/4 of these types fully enumerate all of their properties. But in the validator code below, you use `t.interface` for all of them. Either the types are incorrect (you need to add `...` to some of them), or some of the validators should use `tShape`.
52	Can we be more specific than `Object`?
60	Can we be more specific than `Object`?

This revision now requires changes to proceed.Mon, Oct 21, 8:54 AM

keyserver/src/responders/handlers.js
129	Yes. This was unnecessary. Going to directly spread `responderResult` in next rebase.
lib/types/farcaster-types.js
45–75	It's the former. We likely shouldn't rely on Neynar/Farcaster to not add additional fields, so I plan to add `...` to the next rebase
52	I'm actually thinking I'll remove this for now
60	We're not using embeds for my current work. Removing