# \[Post deleted\] **URL:** \ **Category:** General Discussion\ **Created:** [January 3, 2023, 12:45pm UTC](https://forum.solidproject.org/t/post-deleted/6028 "2023-01-03T12:45:40Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![NoelDeMartin](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/noeldemartin/32/3144_2.png) [@NoelDeMartin](https://forum.solidproject.org/u/NoelDeMartin)\ **Post date:** [January 13, 2023, 10:24am UTC](https://forum.solidproject.org/t/post-deleted/6028/4 "2023-01-13T10:24:27Z")
Thanks for posting this Ruben, very interesting :). > the first app to sculpt documents and containers in your pod determines where other apps need to look for data. I agree that this is what’s happening in practice today, but I don’t think that’s the idea of Solid. Ideally, apps should be using the Type Index (or Solid Application Interoperability, etc.). But they don’t, so I think the problem is that most apps are not following best practices, not that this is how Solid is supposed to work. I see two ways to solve that. The first one is to actually enforce them, but I worry that it would increase the barrier of entry for new developers. The second one is to make it so trivially easy to use that everyone does it; either because it’s a well-documented best practice or because most libraries in the ecosystem do it out of the box. And maybe the second one would be the best approach. I like to think of this like how lenient HTML is with mistakes. You can write HTML that is not 100% valid, but the browser will still render it, instead of throwing an error. In that regard, I think it would be fine if 90% of Solid Apps used the Type Index but not all of them. The problem is that at the moment, almost none are using it. > This seriously hinders interoperability and serendipitous reuse, which I consider absolutely vital to a thriving personal data ecosystem. I agree with this 100% :D. I wrote a post a while ago titled [Interoperable Serendipity](https://noeldemartin.com/blog/interoperable-serendipity), and for me this is THE point of Solid. > Implementing graph-centric pods and views My opinion of graph-centric pods is that they sound great in theory, but I worry that this will never happen in practice :/. I’ve been developing Solid Apps for 4 years now, and I’m still missing things as simple as [paginating data](https://github.com/solid/specification/issues/227#issuecomment-773945439). Sure, I’m saying that from an impatient app developer’s point of view; I understand that things take time. But honestly, I’d much rather have a document-centric Solid POD that works in practice, than being caught up in theoretical discussions that never become a reality. As an app developer, I also had this question of where I should place the data. But ever since I learned about the Type Index, I don’t have it any more. And even though it’s not perfect, it gets the job done for many use cases. Still, nobody is using it because it’s still a draft and it seems we’re waiting for the perfect solution before settling on anything. As you mention in the article, a graph-centric POD is backwards compatible with a document-centric POD. So I think at this point it’s more useful to develop the existing document-centric architecture further, and transition it towards a graph-centric architecture eventually. In any case, I’m just a mere app developer and I haven’t thought deeply about these topics, so I may be missing something for sure 😅. But my impression is that such a paradigm shift would slow down the progress of Solid even more than it already is. --- _[View the full topic](https://forum.solidproject.org/t/post-deleted/6028)._