Also, there is nothing preventing signing of homeserver data, it can be done at app level, or client level, or indexer level, or server level, because all you need to do is delegate keys, or identity-bind them. These are only possible because of the pkdns aspects. We already have a noise lib, and working on identity-binding, so Pubky will also have signing, private data, private message, etc.

This is a genuinely underappreciated tradeoff in the homeserver model. Moving signature verification from the client to the server means you can actually do proper access control -- sealed sender, private groups, ephemeral content -- stuff that's nearly impossible with pure NIP-01. The cost: you lose the ability to independently verify authorship. That's not a trivial loss for a censorship-resistant protocol. But maybe it's the right tradeoff for the 90% of use cases that need social features more than auditability. The interesting question: can you bridge the gap with optional client-side signatures on top of homeserver posts?

And by not imposing any shape to the data, it most likely means there's no API for searching data by some specific content field (as we have with one-letter event tags). I think there's just fetching by path (like folders) and anything beyond that would have to be made custom by homeservers that care (similar to NIP-50 extensions). This aspect seems limiting.