Add HCS-22 and HCS-23 proposals

[tonycamero]

Migrating HCS-22 and HCS-23 proposals into the new canonical Hiero specs home, as requested by Michael.

HCS-22 introduces Identity Binding Events, defining a canonical HCS message format for asserting verifiable relationships between decentralized identifiers.

HCS-23 introduces Trust Allocation Events, defining message formats and requirements for expressing trust relationships between decentralized identities.

[tonycamero]

DCO signed and checks passing now. Thanks!

[tonycamero]

I’ve been thinking more about the point @kantorcodes raised on Telegram this morning re: the likelihood of hundreds or even thousands of HCS specs over time, and how that scaling pressure shows up most clearly in HCS-10.

Stepping back, HCS-10 feels like it very successfully proved the category, but in doing so it may be carrying multiple roles at once: message formats, behavioral requirements, and what are effectively deployment or use-case compositions. That makes a lot of sense for an early, ambitious standard... and also highlights why future specs probably shouldn’t all converge toward an “HCS-10-sized” document.

One framing that’s been useful for me is to think about decomposing HCS-10 conceptually into three layers:

• Core (Behavioral / Invariants) - a minimal set of normative guarantees required for interoperability
• Schemas (Schema-first specs) - versioned message formats (often extending HCS-2) that stay small and evolve independently
• Profiles (Composition / Use-case contracts) - composable groupings of Core + Schemas that describe “how to build X” without forcing every spec to become a full protocol

From there, an HCS spec evolution path might naturally emphasize schema-first specs by default, reserve behavioral specs for true interoperability needs, and use profiles to capture richer application guidance - potentially backed by a lightweight registry/index as the catalog grows.

This isn’t meant as a critique of HCS-10 - more an acknowledgment that it did its job so well that it now exposes the need for a scalable structure around it.

On my side, I’m aligned with this direction and plan to update my two open PRs (HCS-22 and HCS-23) accordingly, keeping them firmly schema-oriented, avoiding new envelope semantics, and being explicit about what they do not prescribe behaviorally.

@HGraphPunks - does this help move the ball forward for you guys at all? Hope so! Please lmk what I can dig into on your behalf

[HGraphPunks]

Appreciated the PR!

Reading through this, please reference HCS-4 and restructure your HCS messages as they don't align with the structure defined for these specifications

[tonycamero]

@HGraphPunks I've aligned this with HCS-4 more accurately, (including the required p and op fields). Lmk if it lands.

[tonycamero]

@kantorcodes finally getting back to you. Thanks for the thoughtful review and the earlier discussion on scalability.
I fully agree, with potentially 1000s of domain-specific schemas ahead (identity, trust, agent comms, etc.), we need a durable pattern that avoids HCS-10-style bloat.

HCS-22 (Identity Binding Events) and HCS-23 (Trust Allocation Events) are intentionally narrow:

• They define only the canonical message formats, validation rules, and minimal normative invariants needed for interoperability.
• They extend HCS-2 (Topic Registries) + HCS-4 envelope without introducing new top-level semantics.
• Behavioral guidance, use-case profiles, or complex scoring logic is deliberately left out (to be handled in separate profiles or higher-level docs, e.g., via the evolving HCS-25 work you mentioned).

This keeps each spec small, versionable, and registry-friendly (HCS-13 Schema Registry). Long-term, I suggest we formalize this as the default for new HCS-N entries:

• Schema layer (default for most new work like these)
• Core invariants (only when cross-implementation consensus is required)
• Profiles (composable recipes)

Happy to add a short "Design Rationale / Scalability Note" section to both docs if that helps, or refine anything based on your patches/review.

Let me know how you'd like to proceed... I'm good to iterate quickly.