Category Archives: Uncategorized

Transcription of Selected Parts of the DIF SDS/CS March 11, 2021 Zoom Call: Hub and EDV Discussion featuring Daniel Buchner’s Description of a Hub

Context

This is a transcription of selected parts of the EDV-Hub conversation during the DIF SDS/CS Thursday weekly Zoom call on March 11, 2021. This is the call where Daniel Buchner described (verbally) several aspects about what is and what is not a Hub.

This partial transcription focuses primarily on Daniel’s comments as they relate to the question “what is a Hub?”.

NOTE: The time code timestamps are accurate but not precise. They may be out by +/- a couple of seconds.

Recording

Link to the Zoom recording (audio plus chat): https://us02web.zoom.us/rec/share/-6PUTYTQfZt-2E23VYFFUcAQsdjiocqGy8hlOaCk1jNOC41EuEHmB8UP7hpmOmfs.qbMCfoK4E_wwDXmV

Transcription

28:00 Dmitri: EDVs are for the most part defined.

28:35 Michael: What I was looking for is a litmus test. Oh yah, it goes in this bucket. Oh yah, it goes in that bucket. We don’t have that simple working definition – pair of working definitions – that easily contrasts the two.

29:40 Adrian: I’ve never felt I’ve understood Hubs in those terms.

30:14 Daniel: I think what a Hub is definitely not completely mutable by the user. It’s a standard interface for at a basic …

30:50 Daniel: What a Hub is really is a friendly application-level set of interfaces and functionality over an EDV that provides stuff like queuing up push-style messages to the owner of the Hub when they come online and go grab all of the outstanding objects. It allows people to store data by semantic type so that I can say here’s my Tweet objects [31:12 Daniel continuing], here’s my list objects, here’s playlist objects, and be able to give permissions in capability form out to people to see and decrypt parts of those objects.

So, this is what it is in a nutshell. An EDV is a great thing but you have to answer the question as Michael did in his paper with Twitter. Can you build Twitter off of just the EDV API elegantly, maybe you could torture yourself to do it but could you build it elegantly, would it be something [31:42 Daniel continuing] that speaks to app developers – probably not. You need a layer that is more app-focused…in my opinion.

32:10 Daniel: A Hub was always designed to be a rather dumb datastore. It’s not trying to do complex data transformations. [32:16 Daniel continuing] It’s a semantic searchable store of data that you can get permissions to certain subsets of the data as an app asking Alice for those permissions. [32:27 Daniel continuing] An Agent is very much more powerful. An Agent is actually pulling data down, decrypting it, doing a bunch of things. [32:35 Daniel continuing] I would see a Hub like an application datastore that is yours. That you allow apps to store data for you or other people. You can have one living on a local device; you could have one in the cloud. You could have an instance in several places and they all can sync together and even though they are implemented differently by a cloud provider (like Microsoft), they would have all the same APIs and guarantees because it is a standard. That’s how I envision it.

32:43 Orie (in chat): https://medium.com/decentralized-identity/rhythm-and-melody-how-Hubs-and-agents-rock-together-ac2dd6bf8cf4

33:00 Michael: So, does the Hub’s datastore wrap or build upon on an EDV? …or is it completely like left vs. right?

33:01 Daniel (in chat): A Hub is a gateway/router between apps and EDVs.

33:10 Daniel: If you read that post that Orie posted in the chat. It is really great that he referenced that. [33:16 Daniel continuing] A Hub is essentially a layer that …

33:20 Daniel: We hoping that at the end of this, a Hub can sit above an EDV is where the EDV is where everything is encrypted and a sort of level-level thing. The Hub is like the application-style interface. Maybe like the Firebase API that speaks internally to store encrypted objects in a low-level way with the EDV.

33:31 Orie (in chat): EDV <> Hub <> Agent

33:37 Daniel: Orie is absolutely right but I would probably reverse the order. An Agent is super powerful; a Hub is less powerful; an EDV is very low-level storage and it is sort of like a Hub is the app layer that sits on top of an EDV …hopefully.

47:32 Daniel (in chat): It is a semantically indexed datastore, of which it can only see truly public data

52:17 Michael (in chat): Hub = intelligent public service endpoint … for EDV data

52:31 Daniel (in chat): YES!

52:39 Daniel (in chat): slightly intelligent

53:02 Daniel (in chat): only in the sense that it can layer some semantic APIs over the internal public objects.

End of Transcription

Click the diagram below to enlarge it…

Billg Fall 1997 Retreat: Improving the Software Development Processes at Microsoft

Click here to download:

• ORTHOGONAL DEFECT CLASSIFICATION (ODC4MSFT)

Click here to download:

• Fully Decentralized Twitter (Dewitter) App Scenario: Platform Requirements (presentation)

1. Trusted Digital Web: Trusted Content Storage Architecture (TCS Stack): Architecture Reference Models (TCS-ARMs) – Work-in-Progress
2. Trusted Content Storage (TCS Stack): Decentralized Twitter (Dewitter) App Scenario
3. Trusted Content Storage (TCS Stack): Decentralized Twitter (Dewitter) Platform Requirements List
4. TDW Hub Architecture Reference Model (HUB-ARM)
5. Trusted Content Storage (TCS Stack): Secure Resource Sharing (SRS) using Replicated Stubs: Solution Concept
6. Fully Decentralized Twitter (Dewitter) App Scenario: Platform Requirements (presentation to DIF SDS/CS WG – March 18/2021)

Parallelspace Corporation, the leading developer of Truly Collaborative Business Solutions for Groove Workspace.

(1/5) @Ray Ozzie on the importance of understanding one’s self… This, to me personally, is the most impactful of all of Ray’s #CHMFellows #vignettes. https://instagram.com/p/CMf8X_SJdFw/

(2/5) Took me a long time to figure out who I am …in fact, it took until just recently. I’m a #FirstPrinciplesThinker: https://hyperonomy.com/2021/03/10/first-principles-thinking/
…which can be a huge frustration to me and those around me when you aren’t cognizant of who you are. Thank you @Ray Ozzie #CHMFellows

(3/5) For example, remember the Groove Tool development environment Parallelspace Corporation created using an the C Preprocessor and the (depreciated) Microsoft Visual Interdev web development platform (a precursor to Visual Studio)? #FirstPrinciplesThinking. #CHMFellows

(4/5) Groove Tools like Parallelspace eMail …the fully integrated version of Microsoft Outlook that ran transparently inside Groove Workspace. #FirstPrinciplesThinking. #CHMFellows

(5/5) And many, many other custom Groove tools based on #FirstPrinciplesThinking. Thank you @Ray Ozzie
https://hyperonomy.com/2021/03/17/truly-collaborative-business-solutions-for-groove-workspace-from-parallelspace-corporation/

(6/5) …all accomplished with my trusted colleague Sanjay Malhotra. Great times. 🙂

The TDW Glossary Relationship Compass was inspired by:

1. ANSI/NISO Z39.19-2005: Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies
2. Synaptica KMS – Enterprise Taxonomy Management
3. TDW Glossary Management and Collaboration Platform (TDW-GMCP): Initial Results

Click each figure to enlarge it.

The points of the TDW Glossary Relationship Compass are based on the relationship types defined in ANSI/NISO Z39.19-2005.

Click here to download the Technical White Paper (TWP) Document Development Plan and Schedule (PDF).

Acknowledgements

• Microsoft Corporation

Click the HUB-ARM to enlarge it. It will open in a new tab. Read the narration provided below the HUB-ARM.

Narration

Each bullet in the list below describes a numbered bubble in the diagram above.

1. Alice’s App (1) has secure access to Alice’s Public Data (5), Alice’s Private Data (8), and Alice’s Secret Data (11).
2. Alice’s App (1)’s secure access is realized by the Layer D Hub Service Endpoints (2). The Layer D Hub Service Endpoints (2) support intelligent, semantics-based, query-by-schema access via a pubic interface exposed by a collection of Hub Protocol Handlers (3).
3. Layer D Hub Service Endpoints (2)’s collection of supported Hub Protocol Handlers (3) might include: Bluetooth, HTTP REST, gRPC, Web Sockets, etc.
4. Layer D Hub Service Endpoints (2) primarily provide access to the functionality supported by the Layer D Federated Query and Retrieval Service (4). The functionality supported by the Layer D Federated Query and Retrieval Service includes intelligent federated routing of semantics and schema-based queries plus aggregated retrieval of matching resources from Alice’s Public Data (5), Alice’s Private Data (8), and/or Alice’s Secret Data (11).
5. Alice’s Public Data (5) is managed by the Hub Microkernel (6) which supports UJWT Data Vaults (7) containing collections of unsigned JWT resources.
6. The Hub Microkernel (6) provides CRUD access to the collections of unsigned JWT resources in one or more UJWT Data Vaults (7) attached to the Hub Microkernel (6).
7. One or more UJWT Data Vaults (7) can be attached to a Hub Microkernel (6) and are used to store collections of unsigned JWT resources.
8. Alice’s Private Data (8) is managed by the Hub Microkernel (9) which supports JWS Data Vaults (10) containing collections of JWS (signed JWT) resources.
9. The Hub Microkernel (9) provides CRUD access to the collections of JWS (signed JWT) resources in one or more JWS Data Vaults (10) attached to the Hub Microkernel (9).
10. One or more JWS Data Vaults (10) can be attached to a Hub Microkernel (9) and are used to store collections of JWS (signed JWT) resources.
11. Alice’s Secret Data (11) is managed by the EDV Microkernel (12) which supports JWE Data Vaults (13) containing collections of JWE (encrypted JWT) resources.
12. The EDV Microkernel (12) provides CRUD access to the collections of JWE (encrypted JWT) resources in one or more JWE Data Vaults (13) attached to the EDV Microkernel (12).
13. One or more JWE Data Vaults (13) can be attached to an EDV Microkernel (12) and are used to store collections of JWE (encrypted JWT) resources.
14. An Indexing Crawler Service (14) might enable the indexing of publicly available content in Alice’s Data Vaults (7, 10, 13). Private and Secret Data Vaults will most likely not expose any indexable data vault-level or resource-level data.
15. A Data Vault Directory Service (DVDS) (15) might exist to enable the lookup and resolution of Alice’s Data Vaults (7,10, 13) by various public data vault properties. Private and Secret Data Vaults will most likely not expose any public data vault properties and would not be locatable using the DVDS (15).

Acknowledgements

The above proposal for describing a Hub using the TDW Hub Architecture Reference Model (HUB-ARM) was inspired by Daniel Buchner’s verbal description of a Hub during the DIF SDS/CS call on Thursday, March 11, 2021 plus subsequent conversations on the DIF SDS/CS mailing list (Adrian Gropper).