Proposal: Improve get-single-profile response consistency and error clarity

[brootle]

1. Inconsistent response status for missing profiles

When calling the get-single-profile endpoint with a valid public key or username that does not have an associated profile, the API currently responds with:

• Status: 404 Not Found
• Response:

{
  "error": "GetSingleProfile: could not find profile for username or public key: , BC1YL..."
}

Issue:

• A 404 implies the endpoint is missing, which is not the case — the user exists, but simply doesn’t have a profile.
• It introduces an inconsistent response shape between users with and without profiles.
• It complicates client-side logic, caching, and error handling.

Suggested Solution:

Return a 200 OK status with a consistent structure such as:

{
  "Profile": null,
  "IsBlacklisted": false,
  "IsGraylisted": false
}

2. Improve error messaging clarity

When querying by either Username or PublicKeyBase58Check, the returned error currently includes both fields, even if one was not part of the request:

• Query:

{ "Username": "nader1" }

Error:

{ "error": "GetSingleProfile: could not find profile for username or public key: nader1, " }

• Query:

{ "PublicKeyBase58Check": "BC1YL..." }

Error:

{ "error": "GetSingleProfile: could not find profile for username or public key: , BC1YL..." }

Issue:

• This adds noise and confusion to error logs and makes debugging more ambiguous.

Suggested Solution:

Tailor the error message based on the provided field. For example:

• If only Username is provided:

{ "error": "GetSingleProfile: could not find profile for username: nader1" }

• If only PublicKeyBase58Check is provided:

{ "error": "GetSingleProfile: could not find profile for public key: BC1YL..." }

Summary of proposed improvements:

✅ Use 200 OK with Profile: null when a valid user has no profile
✅ Return only the identifier field actually used in the error
✅ Keep response format consistent whether profile is found or not

These changes would improve developer experience, reduce ambiguity, and allow cleaner client-side integration.

Thanks for considering this enhancement!