I love the way you think and surely, so many others here in the Logseq community, whom I am looking forward to hearing as well.
I think the protocol discussions are way too early, especially there are other things the Logseq community can think of. The thing about Logseq is that for me, as a mere bystander, Logseq is how HTTP/HTML should have been designed in the first place. Somehow, it didn’t happen and we are where we are.
So I think there’s an opportunity to first re-introduce the simple concept of a website to people and re-introduce it with Logseq as the starting point. Simply due to the exact ability that you yourself mentioned: easy input of structured data.
In fact, Logseq may want to look at two aspects: the workflow side of things and closer integration with the Unix platform. Logseq is client-based and can be tied to the power of the command line. Another aspect Logseq can look into, potentially, is ways to consume the data that is produced inside of it. The query concept is very powerful but we should easily be able to turn queries into tables, tile views, etc.
So, as you can see, I think there’s an immense opportunity ahead to let people know that anyone can now have an extremely nuanced website. At least people like me will join. I am a programmer in the sense that I can use an API if it’s created by responsible engineers. As soon as a library becomes experimental or poorly designed, people like me cannot use them. Logseq on the other hand is compared (at least for me) with Excel, as a piece of software that runs the risk of being adopted by a larger audience that the usual geeks that adopt however difficult tech in our industry. Kudos to them but what about us who are not that technical.