While i agree to not blindly inject any dependency that seemingly makes you productive faster having everybody implementing their own json parser (for example) going to be just as bad? It's not going to be 1 huge CVE that affects many apps it's going to be many CVE's for every single app/implementation.

There's probably a middle ground here that is not the worst of both worlds. 

 There's no problem in embed well audited dependencies, noone would be better secure than use directly libsecp256k1 (maybe the system overall could be fragile in case of a vulnerability discovered, but for your software is the best option).
The problem is take shortcuts to add features instead of build slowly (and sometimes simply dont build at all) less necessary things.
Some of these shortcuts consist in embed to much and low quality dependencies, or use frameworks and make this shortcuts squared. 

 The article specifically states that it's a good idea to reuse cryptographic libraries that have been well tested.

I think it's even fine to initially take on the technical debt of a dependency that lets you get real world experience with an idea faster, as long as you accept the possibility that this dependency probably requires more scrutiny if you intend to keep on using it.

It's complicated and definitely not a black and white case that you should do something yourself. Both ways can go horribly wrong. 

 Another problem with external dependencies is they're very much a black box. Unless the dependency is well documented, at some point you may end up spending the same or more time reading code, understanding the dependency rather than just writing your own. 

 First time I’m seeing this ‘Highlighted’ feature in Damus.  What is this sorcery? 

 Stay tuned, releasing a video and testflight on this today 

 A cool feature of using `git` for dependencies is that you can verify signatures of the commits when pulling them into a project.