It's a consumer product and it has to compete as one. We've been pretty aware of that from the start. I think you're under-estimating what's happening with 3rd

It's a consumer product and it has to compete as one. We've been pretty aware of that from the start. I think you're under-estimating what's happening with 3rd-party feeds. That's a core pattern where independent services can integrate into the UX as if they're native to the product. This means turning the client into an open platform for third-party applications. That's been a success with feeds. They're actively adopted and created by users. Most of the feeds are hosted by skyfeed, a 3P app which gives users a GUI to create them. The author of skyfeed submitted this actually. Talented dev afaict but I've not met them, which is kind of the point. (Looking forward to it though, redsolver!) 3P integration operates by a thick client model. We exchange typed JSON that describes content and interfaces. This lets services drive the client through request/response flows. We can bounce out to webviews when we need, but not executing code means better integration into the app, which means users get access to new experiences within the client and providers get users more easily. This being social protocol means that auth and high level verbs (following, liking, commenting) also come along. The Web 1.0 did quite a bit without client scripting, and I suspect this client can too. I also want to mention: the product experience right now is establishing a UX on a protocol-driven network that feels good to consumers. Our metric for success wasn't whether it was novel; it was whether we could meet consumer expectations. If we can prove out scaling -- which I'm now confident we will -- then we've established the core of the network. After that we use that core as a backbone for 3P devs to build integrated experiences, and it should lead to a notably diverse product, and I think that's the compelling position for us to offer.