Tag Archives: technology

Updated Principles of Self-Sovereign Identity 7.0 (DRAFT Proposal #1 – 16 Principles)

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

ChatGPT: I read Christopher Allen’s original “Ten Principles” (2016) and pulled a short set of modern, standards- and ecosystem-aware sources (W3C DID / Verifiable Credentials, Trust Over IP, Sovrin, EBSI) to make sure the updated set reflects real-world progress since 2016. (lifewithalacrity.com)

Below is a proposed updated & expanded collection of Principles of Self-Sovereign Identity — 16 principles grouped into themes, each with a short explanation and why it matters today. After the list I include a compact mapping to Allen’s original ten so you can see continuity.

Updated Principles of Self-Sovereign Identity 7.0

Core: sovereignty & agency

  1. Existence & Agency — People (and other identity subjects) have an independent existence and agency over their identifiers and claims. Identity systems must start from the person (or subject) and preserve that agency. (recovers Allen’s Existence/Control). (lifewithalacrity.com)
  2. User Control (Agency in Practice) — Users must be the operational controllers of their identifiers, credential stores (wallets/agents), and consent decisions — including fine-grained, revocable consent. Control must be meaningful (usable) not just theoretical. (walt.id)

Technical interoperability & standards

  1. Standards-based Interoperability — Implementations should rely on open standards (e.g., W3C Decentralized Identifiers and Verifiable Credentials) to enable global, cross-vendor interoperability of identifiers, credentials, and presentations. Standards provide portability and composability across ecosystems. (W3C)
  2. Protocol & Architectural Openness — Protocols (DID methods, messaging like DIDComm, wallet APIs) and reference architectures (e.g., Trust Over IP stack) must be open and modular so ecosystems can interoperate while allowing local innovation and governance. (Trust Over IP)

Privacy, minimal disclosure & security

  1. Data Minimization & Selective Disclosure — Disclosures must reveal the minimum data necessary; support selective disclosure, zero-knowledge proofs, and anonymous/pseudonymous modes to reduce correlation and surveillance risks. (lifewithalacrity.com)
  2. Privacy by Design & Accountability — Systems should be designed for privacy by default and include accountability mechanisms (consent logs, auditable policies) so misuse can be detected and remedied.
  3. Security & Resilience — Identity systems must provide robust cryptographic security, threat-resistant key management (including social recovery and hardware wallet options), and resilience to compromise, outages, and future threats (e.g., post-quantum planning).

Lifecycle, governance & legal

  1. Persistence & Manageable Lifecycle — Identities and credentials should be persistent as the holder requires, with clear, manageable lifecycle operations (issuance, renewal, revocation, expiry, archival, “right to be forgotten”). Allen’s persistence principle expanded to operational lifecycle. (lifewithalacrity.com)
  2. Recoverability & Continuity — Systems must provide practical and secure recovery mechanisms (social recovery, delegated guardianship, legal recovery paths) so loss of keys or devices does not destroy access to identity or essential services.
  3. Governance, Trust Frameworks & Legal Compatibility — Identity ecosystems require transparent governance and legal frameworks (e.g., ToIP governance, regional trust frameworks like EBSI) to mediate disputes, define liability, set assurance levels, and enable cross-jurisdictional recognition. (Trust Over IP)

Ecosystem & practical adoption

  1. Usability & Accessibility — Real self-sovereignty only exists when interfaces, error recovery, and flows are usable by non-experts and accessible to people with disabilities and diverse contexts (language, literacy, device constraints).
  2. Interoperability with Existing Systems — SSI should interoperate with existing eID, legal, financial, and institutional systems (bridging, translation, hybrid trust models) so real services can use SSI credentials today. (EBSI and other national/regional deployments show this direction). (European Commission)
  3. Assurance, Provenance & Auditability — Verifiers need to rely on trustworthy evidence. Credential schemes should include provenance metadata, assurance levels, and revocation mechanisms so verifiers can make informed decisions without central control. (W3C)

Ethics, inclusivity & future proofing

  1. Human Rights & Ethical Use — Identity systems must protect human rights (privacy, freedom of association, non-discrimination) and explicitly avoid enabling oppression, surveillance, or exclusion; risk assessments and ethical review should be part of deployment.
  2. Inclusivity & Non-Discrimination — Systems must be designed to include people without formal credentials, low-resource settings, refugees, and marginalized communities; they must not require devices, connectivity, or literacy levels that exclude vulnerable populations.
  3. Extensibility & Future-proofing — The model must support non-human subjects (devices, organizations, agents), evolving cryptography, new proof techniques, and new governance models — i.e., it must be extensible without breaking user sovereignty. W3C specs and ecosystem work (Sovrin/Hyperledger/ToIP) show that extensibility is central to adoption. (Sovrin)

Short rationale & evidence

  • Standards matter now. Since Allen’s post, the W3C DID and Verifiable Credentials work have become de-facto standards shaping implementations; any modern principles set must call out standards-based interoperability. (W3C)
  • Governance & trust frameworks are essential. Technical primitives alone don’t create real trust for large-scale public or cross-border use — frameworks like Trust Over IP and regional initiatives (EBSI) show the need for human/legal/governance layers. (Trust Over IP)
  • Practical recovery and UX are blockers for adoption. The community has learned that without recoverability and usable wallets/agents, people lose keys and services fail. That motivates explicit Recoverability and Usability principles. (See ecosystem projects and wallet tooling). (walt.id)

Mapping to Allen’s Original 10

To keep continuity: most of Allen’s ten are preserved but expanded into modern categories:

  • Allen’s Existence, Control, Access, Transparency, Persistence, Portability, Interoperability, Consent, Minimalization, Protection are preserved and appear across the updated list (Existence & Agency; User Control; Access incorporated into Usability/Recovery; Transparency → Architectural Openness and Governance; Minimalization → Data Minimization; Protection → Security & Human Rights). See Allen original. (lifewithalacrity.com)

Reference: https://chatgpt.com/s/t_692bd672442881919413c87440f25ce1

Leave a comment

Filed under Uncategorized

Democracy: A Regressive Hybrid of Decentralization and Centralization

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

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

A Democracy can be viewed as a hybrid between Decentralization and Centralization, and considering it in this way helps clarify both its strengths and tensions. Using the framing and language from the article on Hyperonomy Digital Identity Lab™ (on decentralization/centralization) helps ground the idea. (hyperonomy.com)

Figure 1. Decentralization and Centralization: Locus of Control (Chokepoints)

What does Hyperonomy says about Decentralization

  • According to Hyperonomy, decentralization refers to shifting control (identity, data, decisions, etc.) away from a single central authority toward a distributed ecosystem — where trust and coordination emerge from autonomous agents, shared governance, or open protocols rather than top-down institutions. (hyperonomy.com)
  • The decentralization ideal emphasizes resilience, interoperability, autonomy, and giving individuals or smaller units more control over their own domain (e.g. identity or decisions), rather than placing everything under a monolithic centralized authority. (hyperonomy.com)

The broader literature on decentralization (in political science, public administration, etc.) elaborates that decentralization often aims to increase participation, local responsiveness, diversity in decision-making, efficiency in delivering services, and greater relevance to local conditions rather than one-size-fits-all centralized control. (Wikipedia)


Democracy is inherently a mix of Decentralization and Centralization

A democracy — especially representative democracies in modern states — naturally combines elements of both decentralization and centralization.

Decentralization in a Democracy

  • Local representation and decision-making: Democracies often allow (and sometimes require) that decisions be made at local or regional levels (municipalities, provinces/states, counties, districts), giving those sub-national units meaningful authority over many social, economic, or cultural issues.
  • Participation and diversity: By empowering individuals (or local communities) to elect their representatives, democracy channels a plurality of voices and interests, giving local context and grassroots concerns a say in governance — consistent with the decentralization ideal of distributing power rather than concentrating it.
  • Accountability and responsiveness: Local or regional governments that are closer to constituents are often better informed about local conditions; this promotes responsiveness and accountability, aligning with the benefits of decentralization described by governance scholarship. (ScienceDirect)

Centralization in a Democracy

  • Central institutions for broad coordination: Democracies typically rely on national (or higher-level) institutions — parliaments/congresses, courts, central banks, or executive branches — to make decisions that affect the whole polity (defense, trade, national infrastructure, monetary policy, etc.). Those central institutions enable coordination across diverse regions and populations.
  • Standardization, rule of law, and equal treatment: Centralization helps ensure common standards (laws, rights, regulatory frameworks) that apply across the country. Without a central authority, such coherence is hard to maintain.
  • Ability to manage large-scale, cross-regional issues: Some problems (e.g. national security, economic macro-policy, environmental regulation, pandemics) require centralized capacity and coordination across many localities — something that decentralized fragments alone may struggle to handle effectively.

Democracy as a “Hybrid” — a Delicate Balance

Given the above, Democracy functions as a hybrid system:

  • It decentralizes by distributing political power — giving individuals/communities representation, local governance, and a role in decision-making, enabling diversity, participation, and local responsiveness.
  • It centralizes by maintaining institutions that coordinate across the whole polity, ensure uniform rights and laws, manage shared resources, and handle collective action challenges that require unity.

That hybrid nature can be seen as a strength: it combines the flexibility, resilience, and responsiveness of decentralization with the coherence, scale, and coordination of centralization.

But it also introduces tensions:

  • Over-centralization can suppress local autonomy, reduce diversity, and disconnect decision-makers from local needs.
  • Over-decentralization (fragmentation) can lead to coordination failures, inequalities between regions, and difficulties in addressing problems that span local boundaries.

The “sweet spot” for a democracy — in this view — is finding a balance: enough decentralization to empower local voices and contexts; enough centralization to deliver unity, fairness, and capacity for collective action.


What does Democracy gain from using Hyperonomy’s Framing

Using the lens from Hyperonomy (originally articulated in the context of digital systems, identity, and governance architectures) helps generalize the decentralization–centralization tradeoff beyond institutions:

  • It shows that whether power, control, identity, or decision-making is central or distributed is not a binary choice — real systems (whether digital networks or democratic polities) often mix features depending on context, purpose, scale.
  • It highlights that decentralization is always “good” (nor centralization “bad”): what matters is architecture — how responsibilities, trust, and governance are designed and distributed.
  • It underscores resilience, interoperability, and autonomy as design goals — which map well onto democratic ideals like political participation, civil liberties, accountability, and adapting to diverse local conditions.

Conclusion: Democracy is a Regressive Decentralization-Centralization Hybrid

In short: democracy very often is a hybrid between centralization and decentralization. It draws on decentralizing impulses (local decision-making, representation, citizen participation) to ensure diversity and responsiveness, while relying on centralized structures to ensure coherence, rule of law, collective capacity, and fairness across the whole polity.

Using the conceptual framing from the Hyperonomy article helps emphasise that this isn’t a flaw or anomaly — but a necessary but regressive balancing act that shapes how democratic societies function, just as decentralized digital systems must balance autonomy and coordination.

Appendix A – Social Evolution: From Wanderer to Digital Nation State

The democratic principles discussed in this article apply to every stage of societal development, as illustrated in Figure 2. In hindsight, the left side of the diagram is decentralization leaning, while the right side is centralization leaning. The middle is a hybrid.

Figure 2. Social Evolution: Creation of a Nation State

Appendix B – Resources

  1. Voting-based Decision Making based on General Patterns for using VCs to represent n-way relationships (VRC-N)
  2. Change Adoption Models: A Comprehensive Guide
  3. Definitions for Decentralization vs Centralization vs Hyper-Centralization
  4. Decentralization, Centralization, Hyper-decentralization, and Circular Hype-Decentralization
  5. Circular Hyper-centralization, et al.
  6. Democracy: A Progressive Hybrid of Decentralization and Centralization (this article)
  7. User Control & Consent (SSI) and Decentralization

Leave a comment

Filed under Uncategorized

Windows 1.0 SDK Samples: generic.c

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

Documentation

generic.c

/********************************************************************\

*  generic.c: Source code for generic                                *

*                                                                    *

*  Comments: Generic Application                                     *

*                                                                    *

*  Functions:                                                        *

*     WinMain      - Application entry point                         *

*     MainWndProc  - main window procedure                           *

*     AboutDlgProc - dialog procedure for About dialog               *

*                                                                    *

*                                                                    *

\********************************************************************/


/*********************  Header Files  *********************/


#include <windows.h>

#include "generic.h"

#pragma comment(lib, "user32.lib")

#pragma comment(lib, "gdi32.lib")


/*********************  Prototypes  ***********************/


LRESULT CALLBACK MainWndProc( HWND, UINT, WPARAM, LPARAM );

INT_PTR CALLBACK AboutDlgProc( HWND, UINT, WPARAM, LPARAM );


/*******************  Global Variables ********************/


HINSTANCE ghInstance;


/********************************************************************\

*  Function: int CALLBACK WinMain(HINSTANCE, HINSTANCE, LPSTR, int)  *

*                                                                    *

*   Purpose: Initializes Application                                 *

*                                                                    *

*  Comments: Register window class, create and display the main      *

*            window, and enter message loop.                         *

*                                                                    *

*                                                                    *

\********************************************************************/


int CALLBACK WinMain( HINSTANCE hInstance,

    HINSTANCE hPrevInstance,

    LPSTR lpszCmdLine,

    int nCmdShow )

{

   MSG msg;

   HWND hWnd;

   BOOL bRet;

   WNDCLASS wc;


   if( !hPrevInstance )

   {

      wc.lpszClassName = TEXT("GenericAppClass");

      wc.lpfnWndProc = MainWndProc;

      wc.style = CS_OWNDC | CS_VREDRAW | CS_HREDRAW;

      wc.hInstance = hInstance;

      wc.hIcon = LoadIcon( NULL, IDI_APPLICATION );

      wc.hCursor = LoadCursor( NULL, IDC_ARROW );

      wc.hbrBackground = (HBRUSH)( COLOR_WINDOW+1 );

      wc.lpszMenuName = TEXT("GenericAppMenu");

      wc.cbClsExtra = 0;

      wc.cbWndExtra = 0;


      RegisterClass( &wc );

   }


   ghInstance = hInstance;


   hWnd = CreateWindow( TEXT("GenericAppClass"),

      TEXT("Generic Application"),

      WS_OVERLAPPEDWINDOW|WS_HSCROLL|WS_VSCROLL,

      0,

      0,

      CW_USEDEFAULT,

      CW_USEDEFAULT,

      NULL,

      NULL,

      hInstance,

      NULL

   );


   ShowWindow( hWnd, nCmdShow );


   while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0 ) 
   {

      if (bRet == -1)

      {

         // handle the error and possibly exit

      }

      else

      {

         TranslateMessage( &msg );

         DispatchMessage( &msg );

      }

   }


   return (int)msg.wParam;

}


/********************************************************************\

* Function: LRESULT CALLBACK MainWndProc(HWND, UINT, WPARAM, LPARAM) *

*                                                                    *

*  Purpose: Processes Application Messages                           *

*                                                                    *

* Comments: The following messages are processed                     *

*                                                                    *

*           WM_PAINT                                                 *

*           WM_COMMAND                                               *

*           WM_DESTROY                                               *

*                                                                    *

*                                                                    *

\********************************************************************/


LRESULT CALLBACK MainWndProc( 
   HWND hWnd, 
   UINT msg, 
   WPARAM wParam,

   LPARAM lParam )

{

   PAINTSTRUCT ps;

   HDC hDC;


   switch( msg ) 
   {


/**************************************************************\

*     WM_PAINT:                                                *

\**************************************************************/


      case WM_PAINT:

         hDC = BeginPaint( hWnd, &ps );


         TextOut( hDC, 10, 10, TEXT("Hello, Windows!"), 15 );


         EndPaint( hWnd, &ps );

         break;


/**************************************************************\

*     WM_COMMAND:                                              *

\**************************************************************/


      case WM_COMMAND:

        switch( wParam ) 
        {

            case IDM_ABOUT:

               DialogBox( ghInstance, TEXT("AboutDlg"), hWnd, 
                          (DLGPROC) AboutDlgProc );

            break;

         }

        break;


/**************************************************************\

*     WM_DESTROY: PostQuitMessage() is called                  *

\**************************************************************/


      case WM_DESTROY:

         PostQuitMessage( 0 );

         break;


/**************************************************************\

*     Let the default window proc handle all other messages    *

\**************************************************************/


      default:

         return( DefWindowProc( hWnd, msg, wParam, lParam ));

   }


   return 0;

}


/********************************************************************\

* Function: INT_PTR CALLBACK AboutDlgProc(HWND, UINT, WPARAM, LPARAM)*

*                                                                    *

*  Purpose: Processes "About" Dialog Box Messages                    *

*                                                                    *

* Comments: The About dialog box is displayed when the user clicks   *

*           About from the Help menu.                                *

*                                                                    *

\********************************************************************/


INT_PTR CALLBACK AboutDlgProc( 
   HWND hDlg, 
   UINT uMsg, 
   WPARAM wParam, 
   LPARAM lParam )

{

   switch( uMsg ) 
   {

      case WM_INITDIALOG:

         return TRUE;

      case WM_COMMAND:

         switch( wParam ) 
         {

            case IDOK:

               EndDialog( hDlg, TRUE );

               return TRUE;

         }

      break;

   }


   return FALSE;

} 

1 Comment

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

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 (decentralized) mobile app ecosystem

Create your own magic with Web 7.0 / TDW 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 parallels.


🧩 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 Decentralized Mobile App Ecosystem

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

LayerExamplesCurrent Gatekeepers
HardwareApple, Samsung, Qualcomm, GoogleApple, Google
OS / RuntimeiOS, Android, WindowsApple, Google
DistributionApp Store, Play Store, Web 7.0 StoreApple, Google
Payment / IdentityApple Pay, Google Pay, Sign in with AppleApple, Google
Apps / ServicesTikTok, Uber, SpotifyIndependent developers
User Relationships / DataAnalytics, Ads, Web 7.0 Trust GraphMeta, 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 Business 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