Yoclib Multibase Laravel Package

Product Decisions This Supports

• Content-addressing and CID features: Multibase is the self-describing encoding layer (base16, base32, base58btc, base64, etc.) that underpins IPFS CIDs, multihash, and multiformats. This package directly enables any roadmap item that needs verifiable, self-describing content identifiers.
• Decentralized identity (DID / VC) initiatives: DIDs and Verifiable Credentials routinely rely on multibase-encoded keys and identifiers. If you're scoping SSI, wallet, or credential features, this is a plausible building block for the PHP backend.
• Expanded encoding coverage in v1.2.0: The release adds Base45, Proquint, and Base256emoji, plus UTF-8-aware code detection. This broadens the package beyond core multibase into human-friendly/pronounceable identifiers, emoji-based encodings, and QR/health-certificate-adjacent formats. That slightly improves its fit for UX-facing identifier work, but it does not change the strategic licensing/maintenance posture.
• Build-vs-buy input for a tiny utility: Multibase encoding is a thin, well-specified primitive. The existence of this package gives you a "buy" baseline to compare against a ~200–400 line in-house implementation — useful when weighing dependency surface vs. spec compliance. The added encodings make an in-house replacement somewhat larger if you need full parity.
• Interoperability with JS/Go/Rust ecosystems: If your PHP service must round-trip identifiers with IPFS/Filecoin/DID clients written in other languages, a spec-compliant multibase codec is a hard requirement, not a nice-to-have.
• Roadmap gating: The 1-star / 0-dependent profile is itself a decision input — it flags that adopting this is effectively a "build it ourselves or vendor it" decision, not a "lean on the community" decision.

When to Consider This Package

Consider it when:

• You have a concrete, scoped need for multibase encode/decode (CIDs, DID keys, content-addressed identifiers) in a PHP service.
• You specifically need Base45, Proquint, or Base256emoji encoding/decoding and want a single PHP implementation rather than stitching together separate libraries.
• You are prototyping a web3/decentralized-storage or human-readable-identifier feature and want spec-correct behavior fast rather than writing bit-twiddling yourself.
• You can tolerate a GPL-3.0 dependency (or your product is itself GPL-compatible / internal-use only).
• You treat it as vendored code you own — fork, audit, pin — rather than an upstream you depend on for evolution.

Look elsewhere (or build in-house) when:

• License is decisive: GPL-3.0 is a hard blocker for most commercial closed-source products and many SaaS architectures. This alone often kills adoption; a permissively licensed alternative or a small in-house codec is usually preferable.
• Maintenance/security posture matters: 1 star, 0 dependents, single-maintainer, and still low visible adoption. v1.2.0 adds features and tests, but there is still no evidence of security review, fuzzing, or active triage. Do not treat it as a trusted crypto-adjacent dependency.
• You need breadth across the full multiformats stack: if you also need multicodec, multihash, multiaddr, and CID parsing, a single-purpose multibase codec is only a fragment; evaluate the full stack.
• You need performance at scale: a pure-PHP codec may not meet hot-path throughput; benchmark before committing, especially for Base256emoji/UTF-8 handling.

How to Pitch It (Stakeholders)

To executives: This is a small, tactical dependency that unlocks a specific class of features — content addressing and decentralized identity — that appear in our [web3 / verifiable data] roadmap. It is not a strategic platform bet. v1.2.0 improves feature breadth with Base45, Proquint, and Base256emoji support, but two caveats still dominate: (1) it is GPL-3.0 licensed, which conflicts with our standard commercial licensing posture, and (2) it has essentially zero community adoption, so we would own and support it ourselves. My recommendation remains a build-or-vendor decision: use it as a reference implementation and either fork it under review or reimplement the codec in-house to control licensing and maintenance risk.

To engineering: Multibase is a well-specified, self-describing encoding prefix layer used by IPFS CIDs, multihash, and DIDs. This package is a spec-compliant PHP codec; v1.2.0 adds Base45, Proquint, and Base256emoji and makes code detection UTF-8-aware. Those are useful additive features, not breaking changes. The core risks are unchanged: single maintainer, low adoption, GPL-3.0, and no visible security review. If we adopt it, pin the version, vendor it, and add conformance tests against the multibase spec vectors plus the newly added encodings. Given the still-small surface area, I'd rather we own this code — it removes the license question, gives us test coverage, and eliminates a supply-chain dependency for primitives we can fully specify.