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

[RubenVerborgh]

No description provided.

[RubenVerborgh]

@justinwb wrote:

Might consider adding 'Solid' as a prefix here (i.e. Solid data pod). Beyond that, while I'm partial to Solid data pod, I think the term people are most familiar with is Solid pod. It may make sense to go with that to be consistent with its use out in the world.
—#13 (comment)

Consider following the overall Solid app definition here with specific types of Solid apps (Solid webapp, Solid native app, Solid bot). Can then use Solid app when referring to any type, or explicitly call out the type(s) for particular use cases as needed. When writing about CORS I think it is helpful for readers to have this additional distinction, but certainly there will be other use cases beyond CORS where understanding the type of app will be even more important and maybe not as obvious.
—#13 (comment)

[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?

[RubenVerborgh]

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

I'm afraid that ties us to closely to technology, and "Linked Data" (unfortunately!) has a reputation with regard to complexity.

The other option is that maybe we can define the Solid Pod as a combination of 'hub' and 'agent'?

I don't think the pod is an agent, for the simple fact that it is one of the few components in the ecosystem that does not act, i.e., it only responds, but will never take initiative.

[dmitrizagidulin]

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

[RubenVerborgh]

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

[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.

[mwherman2000]

FYI: Wrt to agents in Hyperledger Aries, checkout the Aries Agent RFC by @dhh1128.

I don't think the pod is an agent, for the simple fact that it is one of the few components in the ecosystem that does not act, i.e., it only responds, but will never take initiative.

Questions

1 What are the active components/services in the Solid ecosystem called? What is the best visual diagram of the Solid architecture? [I created the Hyperledger Indy Architecture Reference Model.]
2. What is the eventing model for a Pod? ...whereby new, deleted, or changed content in a Pod triggers some sort of internally or externally registered script or business process?

[mwherman2000]

FYI: Wrt to "wallets" and wallet terminology, Darrell O’Donnell has written a fairly comprehensive report: The Current and Future State of Digital Wallets (webcast).

FYI: Wrt to decentralized identity models terminology more generally, the Sovrin Glossary is also a good resource. [I've also developed a Sovrin Governance Framework Comprehensive Architecture Reference Model (SOVRIN ARM) Interhttps://github.com/mwherman2000/sovrin-armactive Explorer for the Glossary.]

[kjetilk]

Catching up now on comments, I came to revisit this, and if I interpret @elf-pavlik 's comment well, perhaps it makes sense to use the term "pod" informally, we all kinda know what it means, and it is likely to change over time, much like the term "homepage".

When writing normative text, we should use other, more precise terms. Pod should be reserved for more informal settings, where it can be more geared towards the audience.

[csarven]

Kjetil, I believe the suggestion to omit data pod was originally made in #15 (comment) (if not earlier, links welcome).

I believe this issue is resolved by a number PRs, e.g., #365 , #475 , #476 .

Definitions for new terms can be tracked in separate issues.