Support multiple usernames (aliases) per address

[Tijesunimi004]

What changed

A Stellar address can now hold up to 5 federation usernames (aliases), so a business can run department-specific federation addresses (payments*domain, support*domain) against a single account. Closes #613.

Data model

• prisma/schema.prisma: User.address is no longer @unique. New isPrimary Boolean @default(false) column and a plain @@index([address]) for the reverse lookups that used to rely on the unique index.
• prisma/migrations/20260829120000_add_username_aliases/: drops username_registry_address_key, adds is_primary, creates the address index, and marks every existing (non-deleted) row is_primary = true so current single registrations become their address's primary.

Registration (POST /register and POST /api/v1/register)

• An address that already has usernames is no longer a conflict. The handler counts the address's active usernames:
  • 0 -> registered as the primary (is_primary: true in the response)
  • 1-4 -> registered as a non-primary alias
  • 5 -> 409 CONFLICT, "This address already has the maximum of 5 federation usernames."
• Signature/threshold verification is unchanged and still applies to every alias.

Lookups

• GET /federation?type=id and GET /lookup?address= order results primary-first (isPrimary desc, createdAt asc), so a reverse lookup resolves to the primary username. The tiebreak keeps the result stable for legacy rows and if a primary is later soft-deleted.

Tests

• tests/username-aliases.test.js (new): slot assignment, the 5-username cap, the address-scoped count, and primary-first type=id resolution.
• Updated register-endpoint, register-multisigner, sql-injection, tests/register, and server.test where they asserted the old "address already registered" 409 or mocked only findFirst for the pre-registration check.
• Full suite: 681 passing.

Notes

• The 5-username cap is enforced in the handler (count-then-create), not by a DB constraint, so a burst of concurrent registrations for the same fresh address could in principle exceed it slightly. Acceptable for this use case; a partial unique index or a transaction with SERIALIZABLE would tighten it if needed.
• Soft-deleting the primary leaves the remaining aliases non-primary; the lookup order falls back to oldest-first rather than promoting a new primary. Promotion-on-delete can be a follow-up if product wants it.

[vercel]

@Tijesunimi004 is attempting to deploy a commit to the Abdulazeem's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@Tijesunimi004 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.