[Feature Request]: Clarify naming and documentation for the two distinct Go client packages to reduce developer confusion

[gbarros]

Implementation ideas

Problem Description

The Celestia node repository currently exports two distinct Go client packages that are both commonly referred to as the "Celestia Go client," creating significant confusion for developers and hindering adoption:

1. api/client - A high-level, application-focused client for blob submission and simplified DA operations
2. api/rpc/client - A low-level RPC client providing direct access to all node APIs

This naming ambiguity leads to:

• Developer confusion when choosing the right client for their use case
• Documentation fragmentation with unclear guidance on which client to use
• Confusing search results when developers look for client documentation
• Adoption barriers as developers struggle to understand the ecosystem
• Support overhead with repeated questions about client differences
• Poor developer experience during onboarding
• Unclear integration guides when referencing "the Celestia Go client"

Proposed Solution

We propose renaming the client packages to have distinct, descriptive names that clearly indicate their intended purpose:

Suggested Renamings

• Rename api/client → celestia-sdk, celestia-app-client, or similar descriptive name
• Rename api/rpc/client → celestia-rpc-client, celestia-node-client, or similar descriptive name
• Add a README.md file to api/rpc/client explaining its purpose and use cases

Developer Relations Follow-up

Once renamed, we will:

• Update all documentation to use the new distinct names
• Create guides explaining when to use each client
• Ensure consistent naming across all tutorials and examples

The goal is not to deprecate either client, but to make their distinct purposes crystal clear to developers at all levels.

[i9kaya]

+1 - This is an excellent and much-needed proposal.

The current naming ambiguity for the "Celestia Go client" is indeed a significant pain point that I've encountered firsthand while working with the ecosystem. This confusion creates unnecessary friction during development and onboarding.

Strong Support for the Solution:
The proposed renaming strategy is simple,effective, and follows established conventions in the Go ecosystem. Having distinct, purpose-driven names would immediately clarify the intended use cases for each package.

Specific Feedback on Naming:
Between the suggested options,I particularly favor:

· api/client → celestia-app-client - This clearly indicates it's for application-level interactions
· api/rpc/client → celestia-rpc-client - This explicitly states it's for low-level RPC operations

The celestia- prefix is valuable for discoverability in Go modules and makes the packages' origin immediately clear.

Additional Suggestions:

1. Alias Deprecation Period: Consider keeping temporary aliases with deprecation warnings to give existing users time to migrate
2. Go Doc Improvements: Enhance package-level documentation in both clients with clear examples of when to use each
3. Migration Guide: A brief guide showing how to update imports from old to new names would smooth the transition

Willingness to Contribute:
I would be happy to help implement these changes,including:

· The package renaming and import updates
· Creating the proposed README files
· Updating internal references
· Assisting with documentation improvements

This refactor would significantly lower the barrier to entry for new Celestia developers and reduce support overhead long-term. The investment in clarity now will pay dividends as the ecosystem grows.