Discuss and align definitions of data pod, app, etc.

[RubenVerborgh]

[elf-pavlik]

I find it important to explain somewhere that Solid data pod MAY also act as OIDC Issuer, so the spec doesn't require it with MUST. We could even mention solid:oidcIssuer predicate from WebID-OIDC spec.

In addition any person can have access to data on any number of pods, and one of those pods MAY host person's WebID Profile (again not MUST). We could even mention space:storage predicate, and that some pods not related with it can get discovered by "following one's nose" in data.

[elf-pavlik]

First part of my comment above duplicates #7
Second part still adds to that, maybe we could include a diagram like:

I think many open collaborations would use shared group storage to host all kinds of project management related information, but each participant would already have one's own (indie) WebID each already delegating to some OIDC Issuer that person currently chooses. In that case would we also refer to that shared storage as a pod?

[kjetilk]

My main issue with the definitions of data pod is the association with storage. I think to integrate into the IoT world, Solid pods will urgently need to not be thought of only as storage, but also for management of data streams. At the end of the day, what a client sees is a data stream, it doesn't necessarily need to know that the stream has been or will be stored for all applications.

[elf-pavlik]

Maybe spec better avoids ambiguous terms like POD all together? POD in a meaning of personal data cloud may also allow people to deploy a copy of progressive web applications they want use and even host smart client components that need to run in the cloud.

[dmitrizagidulin]

@kjetilk

My main issue with the definitions of data pod is the association with storage

@elf-pavlik

Maybe spec better avoids ambiguous terms like POD all together

I'd like to bring up another option (that is likely a long shot).

Outside of the Solid community, the various self-sovereign identity groups that are working on similar projects seem to be standardizing on two related terms: hub and agent.

For example, the Decentralized Identity Foundation (DIF) has been working on a system called Identity Hubs, that are designed to securely store and share data (partly based on JSON-LD incidentally). The W3C Credentials Community Group is gearing up to work on a Secure Data Hub spec (see also the Secure Data Hub intro paper for Rebooting 9 - it even mentions Solid! :) ).

Similarly, the Hyperledger Aries community is working on a set of specs and protocols for hub and 'agents', though this emphasizes more key management and user-centric services rather than storage, although storage is also a part of it.

So what's the difference between 'hub' and 'agent'? This blog post provides a great explanation: Rhythm and Melody: How Hubs and Agents Rock Together, but in short:

• hubs - data storage, replication
• agents - key management, key wallets, related APIs

Proposal A: What if we move towards standardizing on the term linked data hub, instead of Pod?

Benefits:

• Aligns with the terminology of the wider community
• 'Hub' works better with IoT use cases
• The 'linked' part of 'linked data hub' highlight's the Solid differentiating feature / emphasis.

Drawbacks:

• Solid has already some inertia / tradition behind the term 'Pod'
• Using 'hub' may imply a bit more architectural similarity to the other projects than we are comfortable with.

Proposal B:
The other option is that maybe we can define the Solid Pod as a combination of 'hub' and 'agent'? (This would cover both the data storage and the identity provider service aspects, etc).

What does the community think?

[dmitrizagidulin]

@RubenVerborgh understood. And what are your thoughts on the term 'data hub' itself?

[dmitrizagidulin]

although I think @timbl feels strongly about "pod"

No prob. I figure I should at least start the conversation, raise awareness of the other terms in the space.

[justinwb]

No objections to "data hub" (although I think @timbl feels strongly about "pod").

If all things were equal i think data hub would be a strong contender as a name. That said, there's so much awareness of the term pod as it relates to Solid that i think we'd create a lot of confusion by trying to move away from it now. Similarly, I think that not using the term "pod" in the specification would lead to people being confused as to why we didn't. At this point I think we need to own it.

[csarven]

As this issue also covers issue #15 but with the advantage of more context, I suggest to acknowledge the discussion at 15 and then close 15.

[csarven]

As we don't have a required set of features as to what would constitute a pod, I wonder if we can approach to frame it differently, along the lines of:

"A pod is a system that MAY provide one or more of the following features..."

Features being WebID, IdP, storage, .. ACL, .. that typically a server makes available.

I don't think that the notion of an app particularly fits under pod, so we can probably have a clear divide there .. [Having said that, I'm also okay with the notion that "applications" cover servers, but so far the term "app(lication)" has been used mostly to refer to a clientside application interacting with a server]

Aside: FWIW, some of my own research/documentation of things pertaining to dataspace services out there: https://csarven.ca/linked-research-decentralised-web#decentralised-dataspaces and https://csarven.ca/linked-research-decentralised-web#decentralised-storage-and-interoperable-applications

[elf-pavlik]

I think we may emphasise different terms for different audiences. For broader audience of people who will mostly act as users, pods and apps, specifically those which provide them UI, may work just fine. For much narrower audience of developers who work on conformant implementations more precise and technical terminology could offer clearer guidance.

I don't think that the notion of an app particularly fits under pod, so we can probably have a clear divide there .. [Having said that, I'm also okay with the notion that "applications" cover servers, but so far the term "app(lication)" has been used mostly to refer to a clientside application interacting with a server]

I mentioned it already in at least one other issue and some other online venues. I'd really like to make sure that we avoid limiting smart clients to applications running locally on person's device, I see a ton of use cases where running smart clients on remote server "in the cloud" can provide better experience. I think that for narrower audience of developers we can stick to well established roles of client and server and whenever possible stay agnostic to where application or just some component of it gets executed.

hubs - data storage, replication
agents - key management, key wallets, related APIs

I think implementers may find spec more helpful if it uses those more specific terms directly - data storage, key management etc. rather than try to roll them into more vague umbrella terms. What terms to use in communication material for broader audiences I would consider a separate issue.