[btown]

To be sure, the problem isn't that the plugin injects behavior into the system prompt - that's every plugin and skill, ever.

But this is just such a breach of trust, especially the on-by-default telemetry that includes full bash commands. Per the OOP:

> That middle row. Every bash command - the full command string, not just the tool name - sent to telemetry.vercel.com. File paths, project names, env variable names, infrastructure details. Whatever’s in the command, they get it.

(Needless to say, this is a supply chain attack in every meaningful way, and should be treated as such by security teams.)

And the argument that there's no CLI space to allow for opt-in telemetry is absurd - their readme https://github.com/vercel/vercel-plugin?tab=readme-ov-file#i... literally has you install the Vercel plugin by calling `npx` https://www.npmjs.com/package/plugins which is written by a Vercel employee and could add this opt-in at any time.

IMO Vercel is not a good actor. One could make a good argument that they've embrace-extend-extinguished the entire future of React as an independent and self-contained foundational library, with the complexity of server-side rendering, the undocumented protocols that power it, and the resulting tight coupling to their server environments. Sadly, this behavior doesn't surprise me.

EDIT: That `npx plugins` code? It's not on Github, exists only on NPM, and as of v1.2.9 of that package, if you search https://www.npmjs.com/package/plugins?activeTab=code it literally sends telemetry to https://plugins-telemetry.labs.vercel.dev/t already, on an opt-out basis! I mean, you have to almost admire the confidence.

[danabramov]

I’ll just say that as someone who was on the React team throughout these years, the drive to expand React to the server and the design iteration around it always came from within the team. Some folks went to Vercel to finish what they started with more solid backing than at Meta (Meta wasn’t investing heavily into JS on the server), but the “Vercel takeover” stories that you and others are telling are lies.

[btown]

Gosh, Dan, in seeing your response here - I'm truly sorry I wrote this. While I still find opt-out telemetry distasteful and dangerous, I over-generalized to React in a hurtful way. You've been an incredible influence on me and I have the utmost respect for everything you've done. I've shown quite the opposite of respect in my writing, here.

For whatever it's worth on the RSC front: I, and many others used to "if there's a wire protocol and it's meant to be open, the bytes that make up those messages should be documented" were presented with a system, at the release time of RSC, that was incredibly opaque from that perspective. There's still minimal documentation about each bundler's wire protocol. And we're all aware of companies that have done this as an intentional form of obfuscation since the dawn of networked computing - it's our open standards that have made the Internet as beautiful as it is.

But I was wrong to pin that on your team at Vercel, and I see that in the strength of your response. Intention is important, and you wanted to bring something brilliant to the world as rapidly as possible. And it is, truly, brilliant.

I should rethink how I approached all of this, and I hope that my harshness doesn't discourage you from continuing, through your writing, to be the beacon that you've been to me and countless others.

[danabramov]

Hey, appreciate the reply! I’m sorry for lashing out as well.

Re: protocol, I see where you’re coming from although I can also see the team perspective and I kind of like it the way it is. The team’s perspective is that this isn’t a “protocol” in the sense that HTTP or such is. It isn’t designed to have many implementations emitting it. It is an implementation detail of React itself for which React provides both the “writer” and the “reader”. Those are completely open source — none of the RSC frameworks need to know the actual wire format. They just use the packages provided by React to read and write. Keeping the protocol an implementation detail of React (rather than an “open format”) lets React evolve it pretty substantially between versions with zero concerns about backwards compat. Which is still quite useful at this stage.

When you’re concerned about wire format not being an open protocol, it’s because you’re imagining it would be useful for others to read and write. But this doesn’t really buy you anything. If you’re making an RSC framework, you should just use the React packages for reading and writing. And if you’re not, there’s no reason to use this format. Eg if you make an RSC-like framework in another (non-JS) language, it’s better for you to use your own wire format that’s more targeted to your use case.

Does this help clarify it?

(Note I do think it would be beneficial to document the current version for educational reasons, which is part of why I made https://rscexplorer.dev, but that’s separate from wanting it to be fixed in stone as protocols must be. I think the desire for it to be fixed is rooted in a misconception that frameworks like Next.js somehow “rely” on the protocol and thus have “secret knowledge”, but that’s false — they just use the React packages for it and stay agnostic of the actual protocol.)