Category Archives: Uncategorized

Web 7.0 AgenticOS™: Neuromorphic Agent Architecture Reference Model (#NAARM) – Project “Shorthorn”

Create your own magic with Web 7.0 AgenticOS™. Imagine the possibilities.

Introduction

This article describes the Neuromorphic Agent Architecture Reference Model (NAARM) for Web 7.0 AgenticOS™.

The intended audience for this document is a broad range of professionals interested in furthering their understanding of Web 7.0 AgenticOS for use in software apps, agents, and services. This includes software architects, application developers, and user experience (UX) specialists, as well as people involved in a broad range of standards efforts related to decentralized identity, verifiable credentials, and secure storage.

Web 7.0

“Web 7.0 is a unified software and hardware ecosystem for building resilient, trusted, decentralized systems using decentralized identifiers, DIDComm agents, and verifiable credentials.”
Michael Herman, Trusted Digital Web Project, Hyperonomy Digital Identity Lab, Web 7.0 Foundation. January 2023.

Credit: Alex Thurow, https://youtu.be/4OjZOyG6nMo

Web 7.0 AgenticOS™

Web 7.0 AgenticOS™ is a macromodular, neuromorphic agent platform for coordinating and executing complex systems of work that is:

  • Secure
  • Trusted
  • Open
  • Resilient

Web 7.0 AgenticOS™ is 100% Albertan by birth and open source.

Project “Shorthorn”

Project “Shorthorn” is a parody project name based on Microsoft’s Windows “Longhorn” WinFS project (a SQL-based Windows File System project) with which the author was involved in from a design preview and feedback, consulting, and PM technical training (Groove Workspace system architecture and operation) perspectives (circa 2001-2002).

What makes Shorthorns great:
– They’re good at turning grass into meat (great efficiency).
– Shorthorn cows are amazing mothers and raise strong, healthy calves (nurturing great offspring).
– Their genetics blend well with other breeds for strong hybrid calves (plays well with others).
…and so it is with Web 7.0 AgenticOS™.

Web 7.0 Foundation

The Web 7.0 Foundation, a federally-incorporated Canadian non-profit corporation, is chartered to develop, support, promote, protect, and curate the Web 7.0 ecosystem: Web 7.0 AgenticOS operating system software, and related standards and specifications. The Foundation is based in Alberta, Canada.

What we’re building at the Web 7.0 Foundation is described in this quote from Don Tapscott and co.:

“We see an alternate path: a decentralized platform for our digital selves, free from total corporate control and within our reach, thanks to co-emerging technologies.”
“A discussion has begun about “democratizing AI.” Accessibility is critical. Mostaque has argued that the world needs what he calls “Universal Basic AI.” Some in the technology industry have argued that AI can be democratized through open source software that is available for anyone to use, modify, and distribute. Mostaque argues that this is not enough. “AI also needs to be transparent,” meaning that AI systems should be auditable and explainable, allowing researchers to examine their decision-making processes. “AI should not be a single capability on monolithic servers but a modular structure that people can build on,” said Mostaque. “That can’t go down or be corrupted or manipulated by powerful forces. AI needs to be decentralized in both technology, ownership and governance.” He’s right.”
You to the Power Two. Don Tapscott and co. 2025.

A Word about the Past

The Web 7.0 project has roots dating back approximately 30 years to before 1998 with the release of Alias Upfront for Windows. Subsequent to the release of Upfront (which Bill Gates designated as the “most outstanding graphics product for Microsoft Windows 3.0”), the AUSOM Application Design Framework was formalized.

AUSOM Application Design Framework

AUSOM is an acronym for A User State of Mind — the name of a framework or architecture for designing software applications that are easier to design, implement, test, document and support. In addition, an application developed using the AUSOM framework is more capable of being: incrementally enhanced, progressively installed and updated, dynamically configured and is capable of being implemented in many execution environments. This paper describes the Core Framework, the status of its current runtime implementations and its additional features and benefits.

What is AUSOM?

The AUSOM Application Design Framework, developed in 1998, is a new way to design client-side applications. The original implementation of the framework is based on a few basic concepts: user scenarios and detailed task analysis, visual design using state-transition diagrams, and implementation using traditional Windows message handlers.

The original motivation for the framework grew out of the need to implement a highly modeless user interface that was comprised of commands or tasks that were very modal (e.g. allowing the user to change how a polygon was being viewed while the user was still sketching the boundary of the polygon).

To learn more, read The AUSOM Application Design Framework whitepaper.

Einstein’s Advice

The following is essentially the same advice I received from Charles Simonyi when we were both at Microsoft (and one of the reasons why I eventually left the company in 2001).

“No problem can be solved from the same level of consciousness that created it.” [Albert Einstein]
“The meaning of this quote lies in Einstein’s belief that problems are not just technical failures but outcomes of deeper ways of thinking. He suggested that when people approach challenges using the same assumptions, values, and mental habits that led to those challenges, real solutions remain out of reach. Accoding to this idea, improvement begins only when individuals are willing to step beyond familiar thought patterns and question the mindset that shaped the problem.” [Economic Times]

Simonyi et al., in the paper Intentional Software, state:

For the creation of any software, two kinds of contributions need to be combined even though they are not at all similar: those of the domain providing the problem statement and those of software engineering providing the.implementation. They need to be woven together to form the program.

Web 7.0 AgenticOS is the software.

A Word about the Future

“Before the next century is over, human beings will no longer be the most intelligent or capable type of entity on the planet. Actually, let me take that back. The truth of that last statement depends on how we define human.” Ray Kurzweil. 1999.

NOTE: “Artificial Intelligence” (or “AI”) does not appear anywhere in the remainder of this article. The northstar of the Web 7.0 project is to be a unified software and hardware ecosystem for building resilient, trusted, decentralized systems using decentralized identifiers, DIDComm agents, and verifiable credentials – regardless of whether the outcome (a Web 7.0 network) uses AI or not. Refer to Figures 4a, 4b, and 6 for a better understanding.

DIDComm Notation, a visual language for architecting and designing decentralized systems, was used to create the figures in this article.

Simplistic Agent-to-Agent Communications Model

Figure 0. Simple Agent-to-Agent Communications Model

Figure 0. depicts the design of a typical simple agent-to-agent communications model. DIDComm Notation was used to create the diagram.

Web 7.0 AgenticOS: Conceptual and Logical Architecture

The Web 7.0 architecture is illustrated in the following figure.

Figure 1. Web 7.0 Neuromorphic Agent

Figure 1 is an all-in illustration of the conceptual architecture of a Web 7.0 Neuromorphic Agent. A Web 7.0 Agent is comprised of a Frontal LOBE and the Neural Messaging pathway. An Agent communicates with the outside world (other Web 7.0 Agents) using its Outbound (Talking), Seeing, and Inbound (Listening) Interfaces. Agents can be grouped together into Neural Clusters to form secure and trusted multi-agent organisms. DIDComm/HTTP is the default secure digital communications protocol (see DIDComm Messages as the Steel Shipping Containers of Secure, Trusted Digital Communication). The Decentralized Identifiers (DIDs) specification is used to define the Identity layer in the Web 7.0 Messaging Superstack (see Figure 6 as well as Decentralized Identifiers (DIDs) as Barcodes for Secure, Trusted Digital Communication).

An agent remains dormant until it receives a message directed to it and returns to a dormant state when no more messages are remaining to be processed. An agent’s message processing can be paused without losing any incoming messages. When an agent is paused, messages are received, queued, and persisted in long-term memory. Message processing can be resumed at any time.

Additionally, an Agent can include a dynamically changing set of Coordination and Execution LOBEs. These LOBEs enable an Agent to capture events (incoming messages), compose responses (outgoing messages), and share these messages with one or more Agents (within a specific Neural Cluster or externally with the Beneficial Agent in other Neural Clusters (see Figure 5)).

What is a LOBE?

LOBE (Loadable Object Brain Extensions) is a macromodular, neuromorphic intelligence framework designed to let systems grow, adapt, and evolve by making it easy to add new capabilities at any time. Each LOBE is a dynamically Loadable Object — a self-contained cognitive module that extends the Frontal LOBE’s functionality, whether for perception, reasoning, coordination, or control (execution). Together, these LOBEs form a dynamic ecosystem of interoperable intelligence, enabling developers to construct distributed, updatable, and extensible minds that can continuously expand their understanding and abilities.

LOBEs lets intelligence and capability grow modularly. Add new lobes, extend cognition, and evolve systems that learn, adapt, and expand over time. Expand your brain. A brain that grows with every download.

What is a NeuroPlex?

A Web 7.0 Neuroplex (aka a Neuro) is a dynamically composed, decentralized, message-driven cognitive solution that spans one or more agents, each with its own dynamically configurable set of LOBEs (Loadable Object Brain Extensions). Each LOBE is specialized for a particular type of message. Agents automatically support extraordinarily efficient by-reference, in-memory, intra-agent message transfers.
A Web 7.0 Neuroplex is not a traditional application or a client–server system, but an emergent, collaborative execution construct assembled from independent, socially-developed cognitive components (LOBEs) connected together by messages. Execution of a Neuroplex is initiated with a NeuroToken.

Horizontal Unbundling: Coordination and Execution Agents

Figure 2. Web 7.0 AgenticOS: Agent Logical Architecture: Horizontal Unbundling

Figure 2 illustrates how the deployment of Coordination and Execution LOBEs can be horizontally unbundled – with each LOBE being assigned to a distinct Frontal LOBE. This is an extreme example designed to underscore the range of deployment options that are possible. Figure 3 is a more common pattern.

Horizontal Rebundling

Figure 3. Web 7.0 AgenticOS: Agent Logical Architecture: Horizontal Rebundling

Figure 3 depicts a more common/conventional deployment pattern where, within a Neural Cluster, a small, reasonable number of Frontal LOBEs host any collection of Coordination and/or Execution LOBEs.

Minimal Execution Agent (Trusted Digital Assistant)

Figure 4a. Web 7.0 AgenticOS: Agent Logical Architecture: Minimal Execution Agent

Figure 4a is an example of a minimal agent deployment pattern that hosts a single Trusted Digital Assistant (TDA) LOBE.

Figure 4b MCP-enabled Trusted Digital Assistant

Vertical Debundling: Web 7.0 Neural Clusters

Figure 5. Web 7.0 AgenticOS: Agent Logical Architecture: Neural Clusters and Beneficial Agents

Figure 5 depicts the deployment of a Web 7.0 Neural Cluster. Messages external to the Neural Cluster are only sent/received from the Beneficial Agent. Any additional messaging is limited to the Beneficial, Coordination, and Execution LOBEs deployed within the boundary of a Neural Cluster. A use case that illustrates the Neural Cluster model can be found in Appendix D – PWC Multi-Agent Customer Support Use Case.

DIDComm 7.0

Figure 6a. Web 7.0 AgenticOS: Conceptual Architecture (All-in)

Figure 6a is an all-in illustration of the conceptual architecture of a Web 7.0 Neuromorphic Agent. DIDComm Messages can be piped from the Outbound Interface of the Sender agent to the Inbound Agent of of Receiver agent – supporting the composition of secure, trusted agent-to-agent pipelines similar (but superior) to: i) UNIX command pipes (based on text streams), and ii) PowerShell pipelines (based on a .NET object pump implemented by calling ProcessObject() in the subsequent cmdlet in the pipeline).

NOTE: PowerShell does not clone, serialize, or duplicate .NET objects when moving them through the pipeline (except in a few special cases). Instead, the same instance reference flows from one pipeline stage (cmdlet) to the next …neither does DIDComm 7.0 for DIDComm Messages.

Bringing this all together, a DIDComm Message (DIDMessage) can be passed, by reference, from LOBE (Agenlet) to LOBE (Agenlet), in-memory, without serialization/deserialization or physical transport over HTTP (or any other protocol).

PowerShellDIDComm 7.0
powershell.exepowerbuzz.exe (maybe powernet.exe)
Cmdlet Agenlet (LOBE (Loadable Object Brain Extension))
.NET ObjectVerifiable Credential (VC)
PSObject (passed by reference)DIDMessage (JWT) (passed by reference)
PowerShell PipelineWeb 7.0 Agentic Graph
Serial Routing (primarily)Arbitrary Graph Routing (based on Receiver DID and DIDMessage type)

Feedback from a reviewer: Passing DIDComm messages by reference like you’re describing is quite clever. A great optimization.

Coming to a Web 7.0 LOBE near you…

DIDComm 7.0 Superstack

Figure 6b. DIDComm 7.0 Messaging Superstack

Figure 6b illustrates the interdependencies of the multiple layers within the DIDComm 7.0 Superstack.

Technology Wheel of Reincarnation: Win32 generic.c

Figure 6c. Win32 SDK Sample App: generic.c

References

SSI 7.0 Identity Framework

SSC 7.0 Metamodel

SSC 7.0 Trust Circle Model

Web 7.0 Neuromorphic Agent Identity Model (NAIM)

Figure 7. Web 7.0 Neuromorphic Agent Identity Model (NAIM)

The NAIM seeks to enumerate and identify all of the elements in the AARM that have or will need an identity (DID and DID Document). This is illustrated in Figure 7.

Table 1. Web 7.0 Neuromorphic Agent Identity Model (NAIM) Chart

Beneficiaries, Trustees, and Fiduciary Duty

Figure 8. Beneficiaries, Trustees, and Fiduciary Duty

Figure 8 highlights in red the trusts and fiduciary duty relationships between (a) a Beneficiary (Alice, the person) and (b) her Beneificiary Agent (a trustee). Similarly, any pair of agents can also have pair-wise trusts and fiduciary duty relationships where one agent serves in the role of Beneficiary and the second agent, the role of Trustee.

Appendix A – Web 7.0 AgenticOS: Edge Agent DMZ Deployment

This section is non-normative.

Figure A-1. Web 7.0 AgenticOS: Edge Agent DMZ Deployment

Appendix B – Web 7.0 AgenticOS: Multiple Digital Persona Deployment

This section is non-normative.

Figure B-1. Web 7.0 AgenticOS: Multiple Digital Persona Deployment

Alice has 2 digital personifications: Alice Smith and Alice Athlete. Each of these personifications has its own digital ID. Each of Alice’s personas also has its own Trusted Digital Assistant (TDA) – an agent or agentic neural network.

Figure B-2. Web 7.0 Networks and Trust Graph

Bob has (at least) 4 digital personifications: Bob Aggie, Bob Nova, Bob Sovronia, and Bob Developer. Using Web 7.0 Trust Graph Relationships and Verifiable Trust Credentials (VTCs), Bob can also have personas that are members of multiple Web 7.0 networks.

Appendix C – Different Brain Functionalities and Their State of Research in AI (2025)

Figure C-1. Different Brain Functionalities and Their State of Research in AI (2025)

Source: Advances and Challenges in Foundation Agents: From Brain-Inspired Intelligence to Evolutionary, Collaborative, and Safe Systems. arXiv:2504.01990v2 [https://arxiv.org/abs/2504.01990v2]. August 2025.

Figure C-2. Simplified Brain Anatomy (Source unknown)
Figure C-3. Web 7.0 AgenticOS Layers

In Figure C-3, the Trust Library forms the Inner core and the UX LOBEs, the Crust. The Outer core is comprised of the Fast Cache and Long-Term Memory LOBEs, Neural and Basal Pathways, DID Registry, and LOBE Library. The Mantle is where the Coordination and Execution LOBEs execute.

Appendix D – PWC Multi-Agent Customer Support Use Case

Figure D-1. PWC Multi-Agent Customer Support Use Case

Source: Agentic AI – the new frontier in GenAI. PWC Middle East. 2024.

This use case exemplifies the use of the Web 7.0 Neural Cluster model. Table D-1 maps the PWC Use Case terminology to the corresponding Web 7.0 AARM terminology.

Web 7.0 AARMPWC Use Case
Beneficiary AgentMaster agent
Coordination Agent (and LOBEs)Orchestrator agent
Execution Agent LOBEsMicro-agents
Table D-1. Web 7.0 AARM – PWC Use Case Terminology Cross-Reference

Appendix E – Groove Workspace System Architecture

Resources

Macromodularity

  1. Organization of computer systems: the fixed plus variable structure computer. Gerald Estrin. 1960.
  2. Macromodular computer systems. Wesley Clark. 1967.
  3. Logical design of macromodules, Mishell J. Stucki et all. 1967.

Powered By

Michael Herman
Decentralized Systems Architect
Web 7.0 Foundation
October 15, 2025

2 Comments

Filed under Uncategorized

Google’s Strategic Response to Super Apps

Create your own magic with Web 7.0 AgenticOSs. Imagine the possibilities.

Copyright © 2025 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License


Google’s Strategic Response to Super Apps

Platform Layer: Defensive Flexibility

  • Android modularization: Google could further modularize Android (e.g. via Project Mainline, Play Services) to allow more granular control over APIs and updates—making it easier to support or restrict super app behaviors.
  • Policy recalibration: In response to regulatory pressure (e.g. DMA in Europe), Google may loosen Play Store restrictions, support alternative billing, and allow more sideloading to stay competitive.

Developer Layer: Ecosystem Incentives

  • Play Console evolution: Google could offer new SDKs and monetization APIs tailored for mini-apps or embedded services, encouraging developers to build within Google’s ecosystem rather than third-party super apps.
  • Firebase + App Actions: Deep integration with Google Assistant, Search, and Android widgets could give developers super app-like reach without needing a host app.

Distribution Layer: Search as a Super App

  • Google Search + Discover + Assistant already function as a meta-layer for app discovery and engagement. Google may double down on this by:
  • Surfacing app content directly in search results
  • Promoting App Clips / Instant Apps
  • Offering deep links into services without full app installs

Monetization Layer: Bundled Value

  • Google One + Pixel Pass: Bundling cloud, security, and device services into a subscription model mimics super app economics.
  • Play Points + Wallet: Loyalty programs and integrated payments could be expanded to create a unified commerce layer across apps.

User Layer: Identity & Privacy

  • Google Identity Services: Strengthening federated login, cross-app personalization, and privacy dashboards positions Google as a trusted identity broker.
  • Privacy Sandbox: Google’s push for privacy-preserving ad tech (e.g. Topics API) could be framed as a safer alternative to super app data centralization.

Strategic Narrative

Google doesn’t need to build a super app—it already operates one in disguise. Android + Search + Assistant + Wallet + Play Store form a distributed super app ecosystem. The challenge is coherence: can Google unify these services into a seamless user experience without triggering antitrust alarms?

Leave a comment

Filed under Uncategorized

Developer incentives and platform governance

Create your own magic with Web 7.0 AgenticOS™. Imagine the possibilities.

Copyright © 2025 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License

This is the outcome of an October 19, 2025 conversation between Michael Herman and Copilot.


🧩 Developer Incentives: Fragmentation vs Aggregation

Super apps flip the traditional developer model:

Old ModelSuper App Model
Build standalone appsBuild mini-programs or plug-ins within super apps
Compete for store visibilityCompete for in-app placement and promotion
Monetize via ads or subscriptionsMonetize via bundled services, commissions, or shared revenue pools
Own user dataShare or rent access to super app user base

🔁 Strategic Shifts

  • Incentive realignment: Developers trade independence for reach. The super app offers instant distribution, but at the cost of brand autonomy and data ownership.
  • Modular architecture: Developers must adopt SDKs, APIs, and design systems tailored to the host super app.
  • Revenue reshuffling: Instead of direct monetization, developers may earn through usage-based payouts, affiliate models, or loyalty programs.

🏛️ Platform Governance: Centralization vs Regulation

Super apps challenge traditional platform governance:

App Store GovernanceSuper App Governance
Apple/Google set rulesSuper app owner sets rules (e.g. WeChat, Grab)
OS-level privacy and securityApp-level identity, payments, and data control
Regulatory oversight (DMA, GDPR)Emerging scrutiny over super app monopolies

⚖️ Governance Tensions

  • Regulatory gray zones: Super apps blur lines between platform and app, raising questions about antitrust, data sovereignty, and consumer protection.
  • Policy fragmentation: Developers must navigate not only OS-level rules but also super app-specific governance—creating multi-layered compliance burdens.
  • User lock-in: Super apps centralize identity, payments, and services, making it harder for users to switch ecosystems—potentially triggering regulatory intervention.

🔮 Strategic Forecast

  • Developers will increasingly specialize in microservices, loyalty mechanics, and embedded commerce.
  • Platforms may respond with their own super app strategies (e.g. Apple Pay + Messages + Maps integration) or loosen restrictions to retain developer loyalty.
  • Regulators will likely push for interoperability, data portability, and transparency in super app ecosystems.

Leave a comment

Filed under Uncategorized

Mobile Ecosystem Power Stack

Create your own magic with Web 7.0 AgenticOS™. Imagine the possibilities.

Copyright © 2025 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License

This layered breakdown is a sharp way to visualize how control dynamics and strategic shifts ripple through the mobile ecosystem.

This is the outcome of an October 10, 2025 conversation between Michael Herman, ChatCGT, and Copilot.


📱 Mobile Ecosystem Power Stack

LayerPrimary ControlCatalyst for ReshuffleStrategic Impact
Platform LayerApple / GoogleNew API rules, OS policiesDevelopers must realign strategies to comply or compete
Developer LayerApp creatorsRise of cross-platform frameworksDistribution becomes more fragmented and flexible
Distribution LayerPlatforms (App Stores)Algorithmic curation, rankingMonetization models shift based on visibility and reach
Monetization LayerDevelopers / PlatformsSubscription-first modelsRevenue flows restructured, favoring retention over acquisition
User LayerEnd usersEnhanced privacy controlsData value redefined, impacting targeting and personalization

🔄 Strategic Cascades

  • Top-down pressure: Platform rule changes (e.g. ATT, DMA compliance) force developers to rethink how they build, distribute, and monetize apps.
  • Bottom-up resistance: Users assert control via privacy settings, reshaping the value of behavioral data and forcing platforms to adapt monetization logic.
  • Middle-layer fluidity: Distribution and monetization are increasingly interlinked—algorithmic visibility directly affects revenue, while subscriptions demand deeper engagement.

Leave a comment

Filed under Uncategorized

Reshuffle value chain and control points for the mobile app ecosystem

Create your own magic with Web 7.0 AgenticOS™. Imagine the possibilities.

Copyright © 2025 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License

A Reshuffle value chain is basically a rethinking of a traditional value chain where value is reorganized around control points — places in the chain where power, influence, or leverage exists. In the mobile app ecosystem, Reshuffle means understanding how the ecosystem is changing and identifying where control is concentrated so that new entrants, incumbents, or platforms can leverage or defend those points.

Based on an October 19, 2025 conversation between Michael Herman and ChatGPT.


1. Mobile App Ecosystem — Overview

A simplified mobile app ecosystem includes:

  1. Hardware Layer
    • Smartphones, tablets, wearable devices (Apple, Samsung, Google, etc.)
    • Includes OS-specific hardware capabilities.
  2. Operating System Layer
    • iOS, Android, HarmonyOS, etc.
    • OS owners control developer APIs, app store access, update processes.
  3. App Stores / Distribution Layer
    • Apple App Store, Google Play Store, third-party app stores (Amazon, Huawei AppGallery).
    • This layer controls app distribution, discovery, monetization rules.
  4. App Development Layer
    • Developer tools, frameworks, SDKs (Unity, Flutter, Xcode, Android Studio).
    • Includes analytics, cloud services, API access.
  5. Service Layer
    • Cloud APIs, backend services, payment gateways, identity, push notifications.
    • AWS, Google Firebase, Azure, Stripe, etc.
  6. End-User Layer
    • Users consuming apps, engaging with services, making purchases.

2. Reshuffle Value Chain in Mobile Apps

Reshuffle shifts the view of the value chain to highlight new control points — places where power is concentrated that weren’t as visible before, and where value creation & capture is happening.

Here’s what a reshuffled mobile app value chain might look like:

Hardware → Operating System → App Store Distribution → Developer Enablement → Service Platforms → User Engagement → Monetization

But reshuffled control points reorder priorities. For example:

  1. Developer Enablement — SDKs, APIs, cloud platforms
    • Modern ecosystems (Apple, Google, Meta) heavily control developers through API access, documentation, and developer accounts.
    • Control Point: Gatekeeping API access and developer terms.
  2. App Store Distribution — Discovery & onboarding
    • Control over visibility in app stores is massive. Algorithms for search, editorial features, app store optimization (ASO) determine success.
    • Control Point: Store algorithms, ranking mechanisms, review processes.
  3. Operating System / Platform Control
    • Controlling OS-level features (ARKit, biometric APIs, background processing) gives huge advantage.
    • Control Point: OS-level permissions and API exclusivity.
  4. Monetization Infrastructure
    • Payment gateways, subscriptions, in-app purchases.
    • Control Point: Payment rules (e.g., Apple’s 30% cut), subscription management.
  5. User Engagement Data
    • Data flows drive personalization, retention, and cross-selling.
    • Control Point: User data access and analytics tools.

Reshuffle Diagram for Mobile App Ecosystem

StageControl Points
HardwareChipsets, sensors, proprietary hardware
Operating SystemAPIs, permissions, OS updates, platform exclusives
App DistributionApp store ranking, app review, app store rules
Developer EnablementSDKs, developer tools, APIs
Service PlatformsCloud services, identity systems, notifications
User EngagementAnalytics, personalization, push notifications
MonetizationPayment processing, subscriptions, advertising platforms

Where the Control Points Are

In a reshuffle, control points move from being purely physical or technical to being gatekeeping points where access, distribution, or monetization is mediated.

For the mobile app ecosystem, the main control points are:

  1. Operating System / API Access — iOS and Android control core APIs.
  2. App Stores — discovery, ranking, and distribution rules.
  3. Developer Tools & SDKs — frameworks that create lock-in.
  4. Payment Infrastructure — control of monetization flows.
  5. User Data & Engagement Platforms — control of analytics and personalization.


Leave a comment

Filed under Uncategorized

Reshuffle model applied to the mobile app ecosystem

Create your own magic with Web 7.0 AgenticOS™. Imagine the possibilities.

Copyright © 2025 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License

Based on an October 10, 2025 conversation between Michael Herman and ChatGPT.

I feel the following doesn’t match 100% with what is presented in the book #Reshuffle but there are a few interesting tidbits.

Copyright © 2025 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License


🧩 1. Background: What the “Reshuffle” Model Means

In the book Reshuffle, the core concept is that platforms continually reconfigure (“reshuffle”) the value chain — deciding:

  • Where to play (which layers of the ecosystem to own, open, or delegate)
  • How to win (by controlling key interfaces, user access, or data flows)

A reshuffle happens when a player changes the architecture of participation — shifting value, control, and power between ecosystem actors.


📱 2. Applying This to the Mobile App Ecosystem

Let’s consider the mobile ecosystem as layers (simplified):

LayerExamplesCurrent Gatekeepers
HardwareApple, Samsung, QualcommApple, Google
OS / RuntimeiOS, AndroidApple, Google
DistributionApp Store, Play StoreApple, Google
Payment / IdentityApple Pay, Google Pay, Sign in with AppleApple, Google
Apps / ServicesTikTok, Uber, SpotifyIndependent developers
User Relationships / DataAnalytics, Ads, Identity GraphsMeta, Google, Apple increasingly

🔀 3. What a “Reshuffle” Looks Like Here

A reshuffle model describes how control, innovation, or value capture moves between these layers. Here are several current and emerging reshuffles:

A. Reshuffle Downward (Re-integration)

Platform owners pull value back down toward themselves:

  • Apple limits tracking (ATT) → cripples ad networks → reclaims privacy and ad advantage.
  • Google moves privacy features into Android → weakens cross-app data collection.
  • Super apps (WeChat, Grab) integrate multiple mini-apps inside one shell → pull distribution away from OS-level stores.

🧭 Effect: Platforms reclaim data, monetization, and developer dependence.


B. Reshuffle Upward (Decentralization / Open APIs)

Some innovations push value upward to developers and users:

  • Progressive Web Apps (PWAs) bypass app stores.
  • Cross-platform frameworks (Flutter, React Native) reduce dependency on native SDKs.
  • Alternative app stores / sideloading (EU’s DMA) redistribute control.

🧭 Effect: Developers gain autonomy and flexibility, though discovery and monetization remain bottlenecks.


C. Reshuffle Laterally (New Platform Entrants)

New layers emerge, shifting boundaries:

  • AI agents / assistants become new distribution channels (e.g., OpenAI’s ChatGPT apps, Perplexity’s mobile UI).
  • Super app frameworks (e.g., Telegram mini-apps) become meta-platforms inside mobile OSes.
  • Wallet-based ecosystems (identity, crypto, digital goods) create cross-platform continuity.

🧭 Effect: Gatekeepers may lose user touchpoints to “meta-platforms” that sit on top of the OS.


⚙️ 4. A “Reshuffle Model Canvas” for Mobile Apps

ElementDescriptionExample
TriggerWhat changes the distribution of value or control?Regulatory changes (DMA), new tech (AI agents), shifts in user behavior
Anchor LayerWhich layer redefines the interface?OS, identity, or payments
Redistributed ValueWhat moves?Revenue, data, trust, discovery
New GatekeepersWho gains control?AI assistants, mini-app frameworks
Old GatekeepersWho loses control?App stores, SDK-based ad networks
User BenefitWhat improves for users?Choice, interoperability, integrated experience
Developer ImpactWhat improves or worsens?Distribution, economics, discoverability

🧠 5. Example: The “AI Agent Reshuffle”

In 2025 and beyond, an AI-driven reshuffle looks like this:

BeforeAfter
Users search for apps in App StoreUsers ask AI assistants to “book a taxi” or “edit a photo”
Developers fight for app visibilityAI intermediates app selection and invocation
App Store controls discoveryAI layer controls orchestration and recommendation
OS owns distributionAI owns user intent

🧭 Reshuffle Result: AI interfaces become the new “home screen.”
App stores become backend registries. The distribution and discovery value shifts to the AI layer.


🏁 6. Summary

A Reshuffle model for the mobile app ecosystem describes how power and value continually move among:

  • OS and hardware vendors (Apple, Google)
  • Developers and third-party ecosystems
  • New intermediaries (AI agents, super apps)
  • Regulators (mandating openness)

The model emphasizes layer-by-layer realignment — each “reshuffle” altering where innovation, value, and control reside.


Leave a comment

Filed under Uncategorized

Decentralized Identifiers (DIDs) as Barcodes for Secure, Trusted Digital Communication

Create your own magic with Web 7.0 Agentic OS. Imagine the possibilities.

Copyright © 2025 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License

Abstract


The invention of the barcode transformed retail and supply chains by providing a universal, machine-readable identifier that ensured accuracy, efficiency, and interoperability across diverse systems. Similarly, Decentralized Identifiers (DIDs) represent a foundational innovation for digital ecosystems: a universal, cryptographically verifiable identifier that enables trusted communication across domains and platforms. This paper explores the analogy between DIDs and barcodes, examining how both enable end-to-end interoperability, reduce friction, and unlock new models of value creation.

Copyright © 2025 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License


1. Introduction

In 1974, a pack of Wrigley’s gum was scanned at a Marsh supermarket in Ohio, marking the first use of the Universal Product Code (UPC). That moment marked the beginning of a transformation in retail, logistics, and global commerce. By providing a standardized identifier, barcodes automated inventory management, accelerated checkout, reduced human error, and laid the foundation for today’s global supply chains.

Digital ecosystems in the 21st century face an equivalent problem: how to create universal, secure, and machine-readable identifiers that work across organizations, platforms, and jurisdictions. While domain names, IP addresses, and UUIDs serve as identifiers, none are self-sovereign, portable, and verifiable across trust boundaries. Decentralized Identifiers (DIDs) aim to solve this.

This paper argues that DIDs are the barcodes of digital trust: a universal, machine-readable system for identifying entities in secure communications, enabling a new end-to-end supply chain of digital trust.


2. The Barcode Revolution

2.1 Before Barcodes

  • Manual price tags and clerical data entry.
  • Inventory tracking prone to human error.
  • Inefficient supply chains with frequent stockouts and overstocking.
  • Lack of standardization across retailers and manufacturers.

2.2 With Barcodes

  • Universal identifiers: UPC and EAN standards.
  • Machine readability: fast, automated scanning reduced labor costs and errors.
  • End-to-end traceability: from manufacturer → distributor → retailer → checkout.
  • Scalability: millions of products, billions of transactions.

Impact: Barcodes enabled just-in-time inventory, global retail expansion, and precise supply chain optimization [Brown, Inventing the Barcode, 2010]. The key insight: a universal, interoperable identifier unlocks systemic efficiencies across the value chain.


3. DIDs: A Digital Barcode for Trust

3.1 What are DIDs?

Decentralized Identifiers (DIDs) are globally unique identifiers that are self-sovereign, verifiable, and resolvable without reliance on centralized registries. Defined by the W3C, DIDs point to DID Documents, which contain public keys, service endpoints, and metadata necessary for establishing secure communication.

3.2 Core Features

  • Universality: A DID can represent a person, organization, device, or digital asset.
  • Machine readability: DIDs are structured and resolvable by software.
  • Cryptographic trust: Integrity and authenticity are verifiable through signatures and key material.
  • Decentralization: No single issuing authority required; anyone can create a DID.
  • Extensibility: Support for multiple DID methods (blockchain, ledger, peer-to-peer).

3.3 Why It Matters

Just as barcodes freed retail from manual, siloed processes, DIDs free digital ecosystems from centralized identity silos (e.g., social logins, proprietary identity providers).


4. Mapping the Analogy: Barcodes vs. DIDs

Barcode PropertyDID EquivalentImplications
Universal product identifierUniversal decentralized identifierEnables global recognition of digital actors
Machine-readableMachine-resolvable DID DocumentAutomated verification by software agents
Standardization (UPC/EAN)W3C DID Core standardCross-platform interoperability
Scannable at every point in supply chainResolvable across trust domainsEnd-to-end verifiable identity
Facilitates inventory managementFacilitates trust managementEnsures secure digital transactions
Enables retail efficiencyEnables digital trust ecosystemsReduces cost, friction, and fraud

5. Benefits of the Barcode Analogy

  1. End-to-End Traceability
    • Barcodes track goods from origin to checkout.
    • DIDs enable trust from authentication through data exchange to audit.
  2. Automation and Efficiency
    • Barcodes eliminated manual entry; DIDs eliminate manual trust establishment.
  3. Interoperability
    • Any barcode scanner can read a UPC; any DID-compliant system can resolve a DID.
  4. Scalability
    • Barcodes scaled to billions of products; DIDs can scale to billions of devices, people, and services.
  5. Systemic Transformation
    • Barcodes reshaped retail; DIDs could reshape finance, healthcare, IoT, and governance.

6. Limits of the Analogy

  • Centralization vs. Decentralization: Barcodes are managed by centralized registries (GS1), whereas DIDs are inherently decentralized.
  • Trust Layer: Barcodes encode only identity (the product number), not integrity or authenticity. DIDs add cryptographic verifiability.
  • Complexity: Scanning a barcode is simpler than resolving a DID, which requires cryptographic operations and network lookups.
  • Adoption: Barcodes achieved rapid, global retail adoption; DIDs remain in early deployment phases.

7. Strategic Implications

7.1 Identity and Access

DIDs could serve as the UPC of digital identity, enabling universal, interoperable identity across organizations.

7.2 Supply Chain and IoT

DIDs can extend barcodes’ logic into digital-physical convergence, providing secure digital twins for physical assets.

7.3 Finance and Governance

DIDs provide the foundational layer of trust for verifiable credentials, smart contracts, and cross-border compliance.

7.4 The “Barcode Moment”

Just as retail only transformed once barcodes were widely adopted, the digital trust economy will require a tipping point of DID adoption to realize systemic benefits.


8. Conclusion

The barcode transformed retail by enabling universal, machine-readable product identification across the supply chain. DIDs can do the same for digital ecosystems by enabling universal, machine-readable, and verifiable identity.

If DIDs achieve broad adoption, they could serve as the universal identifiers of digital trust, enabling secure, scalable, and interoperable communication across the global digital economy — much as barcodes enabled the rise of global retail supply chains.


References


Inspired by the book Reshuffle by Sangeet Paul Choudary.

Produced as the outcome of a conversation between Michael Herman and ChatGPT. October 1, 2025.

1 Comment

Filed under Uncategorized

DIDComm Messages as the Steel Shipping Containers of Secure, Trusted Digital Communication

Create your own magic with Web 7.0 AgenticOS™. Imagine the possibilities.

Copyright © 2025 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License

Abstract

The steel shipping container transformed global trade by introducing a standardized, secure, and interoperable abstraction for transporting goods. Similarly, Decentralized Identifier Communication (DIDComm) offers a standardized, secure, and interoperable mechanism for transmitting trusted digital information between agents. This paper explores the analogy between DIDComm messages and steel containers, examining their properties, benefits, and limitations, and assessing the potential of DIDComm to catalyze a transformation in digital ecosystems comparable to the shipping container revolution.

Copyright © 2025 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License


1. Introduction

The 20th century witnessed a quiet revolution in global trade: the invention and adoption of the steel shipping container. More than faster ships or larger ports, it was standardization in how goods were packaged and transported that unlocked efficiency, scale, and global interoperability.

In the 21st century, digital ecosystems face a parallel challenge. Secure communication across heterogeneous systems remains fragmented by proprietary protocols, siloed trust frameworks, and inconsistent interoperability. Despite advances in transport protocols (HTTP, WebSocket, Bluetooth) and security primitives (TLS, OAuth, JWT), no universal standard exists for trusted, end-to-end, cross-domain messaging.

DIDComm (Decentralized Identifier Communication) aims to fill this gap. It provides a standardized envelope for secure, interoperable communication between agents in decentralized ecosystems. This paper argues that DIDComm can be understood as the steel shipping container of digital communication — a payload-agnostic, transport-agnostic, secure packaging standard that enables trust to move seamlessly across networks and domains.


2. The Shipping Container Revolution

2.1 Before Containers

  • Cargo packaged idiosyncratically: barrels, sacks, crates.
  • Loading/unloading labor-intensive and slow.
  • High rates of pilferage and damage.
  • Inefficiency in intermodal transport (ship → rail → truck required repackaging).

2.2 With Containers

  • ISO standardization: uniform sizes, fittings, and corner posts.
  • Sealed security: tamper-resistant, weatherproof units.
  • Stackability: efficient storage and loading by crane.
  • Interoperability: ships, ports, trucks, and trains adapted to a single form factor.

Impact: Containerization reduced costs by ~90% and increased the speed and scale of global trade [Levinson, The Box, 2006]. The key insight: decouple contents from infrastructure via a universal abstraction.


3. DIDComm: A Digital Container Standard

3.1 What is DIDComm?

DIDComm is a protocol suite for secure, private, and interoperable communication using Decentralized Identifiers (DIDs) as endpoints. It defines how messages are packaged, encrypted, authenticated, and routed between agents.

3.2 Core Features

  • Standardized envelope: headers, routing metadata, payload.
  • Cryptographic sealing: encryption (confidentiality), signatures (authenticity), checksums (integrity).
  • Transport agnosticism: works over HTTP, Bluetooth, WebRTC, email, etc.
  • Routing via mediators: messages can traverse multiple relays without breaking end-to-end security.
  • Payload agnosticism: the message may carry verifiable credentials, IoT commands, or arbitrary application data.

3.3 Why It Matters

Just as containers enabled intermodal trade, DIDComm enables intermodal trust exchange. Applications, wallets, devices, and services can interoperate without bespoke integrations.


4. Mapping the Analogy: Containers vs. DIDComm

Container PropertyDIDComm EquivalentImplications
Standardized formEnvelope with defined structure (headers, body, metadata)Guarantees interoperability across agents and vendors
Sealed & secureEncryption + authenticationProtects against unauthorized access and tampering
Intermodal transportTransport-agnostic deliveryWorks across protocols without altering the payload
Routing via logisticsMediators, DID resolution, forwardingEnables flexible message delivery
Opaque contentsEncrypted payloadOnly authorized parties can inspect
Global ecosystem supportAgent networks, wallets, identity hubsEmerging infrastructure could mirror global ports and carriers

5. Benefits of the Container Analogy

  1. Interoperability
    • Any DIDComm-compliant agent can process a message, just as any port can handle a container.
  2. Security and Trust
    • Messages are sealed like containers, with tamper-evident cryptography.
  3. Efficiency
    • Reduces the cost and complexity of building integrations across organizations.
  4. Scalability
    • Supports any type of payload: credentials, IoT signals, governance instructions.
  5. Decentralization
    • No reliance on a central authority; trust derives from cryptographic keys, similar to how container standards are managed by ISO, not controlled by one nation or corporation.

6. Limits of the Analogy

  • Physical persistence vs. digital ephemerality: Containers endure across voyages; messages vanish after delivery.
  • Metadata leakage: Container labels are visible; DIDComm may still expose sender/recipient metadata.
  • Standard stability: Container sizes have been stable for decades; DIDComm may evolve quickly.
  • Global adoption: Containerization achieved near-universal acceptance; DIDComm is still early in adoption.

7. Strategic Implications

7.1 Identity & Credentials

DIDComm provides a secure transport for verifiable credentials, enabling cross-border, cross-domain trust.

7.2 IoT Ecosystems

IoT devices require lightweight, trustable communication. DIDComm offers a containerized way to exchange secure commands.

7.3 Cross-Domain Interoperability

Applications in finance, healthcare, supply chains, and governance can exchange trusted data without bespoke APIs.

7.4 The “Container Moment”

Global trade was reshaped once container standards reached critical mass. DIDComm could catalyze a parallel moment in digital ecosystems if widely adopted.


8. Conclusion

The steel shipping container revolutionized trade by abstracting the packaging and transport of goods into a universal, secure standard. DIDComm has the potential to do the same for digital trust, abstracting communication into a universal, secure, and interoperable form.

If DIDComm achieves broad adoption, it could serve as the logistics backbone of the digital trust economy, enabling decentralized ecosystems to scale with the efficiency and security once brought to global commerce by steel containers.


References

  • Levinson, Marc. The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger. Princeton University Press, 2006.
  • DIF (Decentralized Identity Foundation). “DIDComm Messaging Specification.” https://identity.foundation/didcomm-messaging.
  • Hardman, Daniel. “Introduction to DIDComm.” Hyperledger Aries Working Group, 2021.
  • ISO. “ISO 668: Series 1 freight containers — Classification, dimensions and ratings.”


Based on a discussion between Michael Herman and ChatGPT. September 30, 2025.

1 Comment

Filed under Uncategorized

Web 7.0 Foundation: SDO Accreditation

Create your own magic with Web 7.0 AgenticOS™. Imagine the possibilities.

Copyright © 2025 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License

The Web 7.0 Foundation is a relatively new organization, incorporated in Canada on May 1, 2023². It focuses on developing specifications and standards for a unified software and hardware ecosystem aimed at building resilient, trusted, and decentralized systems¹³.

Source: Conversation with Copilot, 12/27/2024

(1) Web 7.0 Foundation | Canada Corporation Directory. https://www.canadacompanyregistry.com/companies/web-70-foundation/.
(2) Web7Foundation/Specifications: Web 7.0 Foundation Specifications – GitHub. https://github.com/Web7Foundation/Specifications.
(3) Web 7.0 Overview – YouTube. https://www.youtube.com/watch?v=UM1__hsa2Zk.

Standards Development Organizations (SDOs) typically seek accreditation to demonstrate their competence and adherence to specific procedures and standards. One prominent accreditation body is the International Accreditation Service (IAS), which provides accreditation based on criteria such as AC803¹². This accreditation involves an assessment of the SDO’s standardization process, procedures, and management system².

In the United States, the American National Standards Institute (ANSI) accredits SDOs that follow a consensus-based process³. This ensures that the standards developed are the result of a transparent, balanced, and inclusive process.

Accreditation helps SDOs validate their ability to consistently develop high-quality normative documents, enhancing trust and credibility in their standardization efforts².

Source: Conversation with Copilot, 12/27/2024

(1) Standards Development Organizations – International Accreditation …. https://www.iasonline.org/services/standards-development-organizations/.
(2) IAS Creates Accreditation Program for Standard Development Organizations. https://www.iasonline.org/ias-creates-accreditation-program-for-standard-development-organizations/.
(3) Organizations Developing Standards – Standards Coordinating Body. https://www.standardscoordinatingbody.org/sdos/.
(4) Accreditation Criteria for Standards Development Organizations (AC803). https://www.iasonline.org/resources/accreditation-criteria-for-standards-development-organizations-ac803/.

Leave a comment

Filed under Uncategorized

Building a Knowledge Graph from Wikipedia in Neo4j

https://guides.neo4j.com/wiki

https://github.com/jbarrasa/datasets/blob/master/wikipedia/data/cats.csv?raw=true

https://github.com/jbarrasa/datasets/blob/master/wikipedia/data/rels.csv?raw=true

Leave a comment

Filed under Uncategorized