Hacker News Reader

Comment by bluesign | Hacker News Reader

Great to see someone with experience with Solid. I have few questions, maybe you can answer.

I saw on your blog about wiki data model example. Let's say you built a Solid app around that one. Put on a website like superwiki.com, allowing users to create their wiki pages.

Now then later, wikipedia came to scene, published another data model, and made another Solid app, put on wikipedia.org.

- How will I move let's say my data from superwiki to wikipedia? - Does wikipedia then have to somehow implement some import functionality? - Or Solid has to have a protocol (standard) for wiki entries?

View on HN

> How will I move let's say my data from superwiki to wikipedia?

Your data is not on superwiki, but on your Pod. So you can connect Wikipedia to your Pod, see your data in their app, but it's still in your Pod, rather than having been moved.

> Does wikipedia then have to somehow implement some import functionality?

As follows from the previous answer: no, because the data never moves to Wikipedia. However:

> Or Solid has to have a protocol (standard) for wiki entries?

No, apps define their own data model, so Wikipedia will have to understand Superwiki's data model. Ideally, they agree on a common standard for this, using that standardisation either as a selling point or as a way to comply with future regulations. But of course, an app could also just unilaterally imitate the other's data model, just like e.g. browsers imitated each others' extension API or bookmarks data model.

(Disclosure: I also work for Inrupt, but views are my own.)

I understand data is not moving but if data structures are different there has to be some kinda merge or cloning of the data.

So basically I am at Wikipedia and Superwiki's mercy for interoperability.

What is the value of having(hosting my own data) if I cannot move.

"unilaterally imitate the other's data model" sounds good at the beginning, but what will happen when superwiki is constantly evolving its data structure, and wikipedia also at the same time developing features. And now imagine this with N Actors instead of 2.

Regulations maybe can help on basic data , but for extended data there will be a lot of conflict. (ex: I can move my friend list, but can't move let's say special data I assigned to them in one app)

Correct, you are at the mercy that both Wikis are interoperable. But, each of the N actors can have its model and only agree on an abstraction, which the interoperability is based on. Let's assume an application provides a new feature, which deviates from the abstraction model. As an example, that feature could be of a "like" counter. The counter would then only be visible in a subset of application.

Since the underlying data structure is a graph, every application can attach arbitrary information to an node. But the application only retrieves the necessary bits. Furthermore, I think that apps must be able to handle missing bits to some extent.

I hope this is not confusing. If it helps, one could think of Solid to be the GraphQL endpoint, where the clients send queries expressed as SPARQL and only get back the requested bits of information.

> What is the value of having(hosting my own data) if I cannot move.

The value of having your own data is, precisely, that you have your own data; nothing more and no less.

Furthermore, and although I'm no expert in Solid's and other implementations, it's quite likely that you, or other technologists, can more easily help you achieve the interoperability you so desire if your data is not locked away behind thousand APIs and rate-limits; after all you do have your data in your pod. Think of Instagram, what if all your data was stored locally? Even if it was stored in a really messy JSON schema or whatever you can think of; it's still trivial to massage that data to import it into Wikimedia, or iterate through it and send it in batches to your email, or remove it, etc.

I'm not sure how solid plans to keep applications from stealthily generating derivatives of the data they manipulate. I can imagine some sort of separation would have to happen at the browser level where the "app" provides a scaffold and the browser replaces in your data.

I think that is spot on. As for:

> I'm not sure how solid plans to keep applications from stealthily generating derivatives of the data they manipulate. I can imagine some sort of separation would have to happen at the browser level where the "app" provides a scaffold and the browser replaces in your data.

I don't believe Solid will be able to "enforce" anything - worst case, apps can just not use Solid. I see Solid as the technology that enables apps to respect your control of the data, but the incentives for implementing that has to come from elsewhere, e.g. customer demand or legislation.

(Again, personal views, not necessarily Inrupt's.)

My understanding and expectation are that it’s up to various actors to build processes/apps that use what data you have and make available to them in ways that are meaningful for their service. You then get the benefit of having YourData in services X, Y, and Z. In your example, your data has a Superwiki presence and a Wikipedia presence, which may not be identical, as its up to Superwiki and Wikipedia to present your data in their own meaningful way.

Assuming each service has the capability to create and store data, that new data is still yours, and other actors could request access to it.

I think this will result in various actors taking on the burden of keeping up with the Joneses—which, I think, would eventually coalesce into similar services establishing their own versions of shared data schemas with their own unique value-adds on top. Of course, these value-adds are likely still your data, and it should create somewhat of a feedback loop for similar, even competing, services. You likely would only be bothered to grant additional data access as the shape of that data changes.

Reply on news.ycombinator.com