# Community portability in the everyday Orb journey

Local source update: October 2, 2026. No new public deployment or Git push.

## Connect the community you already use

Open community settings → **Community profile → Your community, beyond this site**.
The current hosted owner can connect an existing independent community ID owned
by their profile-bound Privy Orb Wallet, or review a testnet transaction creating
a public identity with that wallet. A public name and owner address require explicit
consent. Creation does not copy member lists, messages, calls or private channels.

The connection is an authenticated Orb database association, not a new onchain
claim that the public registry owns the hosted database. The public record is in
`OrbOpenCommunityArena`; the existing Arena issuer registry remains separate.
No role, access rule, token balance or private chat permission changes as a result.
Onchain and hosted ownership transfers invalidate the association until reviewed.

Members can open the public identity in the static client or download the client.
Only the current hosted owner using the same current onchain owner wallet can
prepare the owner-signed capsule from these settings. The description is editable;
review its public content and confirm consent before signing. Channel templates
are manually selected text, never an automatic private-room export. Signed JSON
and IPFS CAR downloads, independent pinning and an explicit metadata transaction
use the same capsule format as the external client.

## Backend authorization

`GET /api/orb/community-portability?server=…` is member-only, ban-aware, rate-limited
and uncached. It rechecks chain 10143, exact registry runtime and current owner at
one named block. A read failure does not retain a fresh-verification badge.

POST is same-origin, profile-authenticated, limited to 1,500 bytes and requires
the actual hosted owner; an administrator role alone is insufficient. Linking also
requires server-verified Privy ownership and the existing spending-wallet/profile
binding. The wallet must own the public community. A unique database constraint
prevents one identity being associated with two hosted communities. The write
rechecks hosted ownership in its SQL mutation. Owner-only unlinking disconnects
the hosted reference; it cannot erase a contract or move money.

Migration: `drizzle/0045_orb_community_portability.sql`. Apply it to the isolated
Web3 database before running this source. Never apply it to the normal Órbita
database accidentally. Registration and metadata transactions are simulated
before wallet review; unknown outcomes are retained per wallet/community and
checked by receipt rather than automatically resubmitted.

## Contribution journey

A sponsor opens their funded ORB mission and chooses **Schedule a community
playtest**. Home preselects the mission in an event draft; the organizer still
chooses a room they can manage and explicitly saves the event. A session link is
not a sponsor endorsement or grant of access. Mission criteria and funding can
be reviewed before scheduling. A participant opens the mission from the event,
retains a return link, submits public work and awaits the sponsor's decision.

Accepted participants can review and withdraw within the mission panel. Withdrawal
is to their own wallet and includes all currently available mission credit, including
other rewards/refunds; it is not a separate payment per selected mission. A successful
receipt links to **ORB contributions** in the static client. The existing 5% testnet
fee is accrued only on approved contributions; events and RSVP have no new charge.

## Independent verification

The downloadable client includes the deployed ORB mission manifest and mission/token
artifacts. Its ORB contribution reader uses public RPC directly, never Orb API or a
Privy session. It verifies chain, runtime and reward-token binding, reads public criteria,
remaining budget and the selected wallet's submission/credit at a named block.
A forwarded Orb link includes the expected mission contract; a different bundled
manifest is refused instead of verifying the same numeric ID in another contract.

Withdrawal verification checks successful receipt, sender, contract, exact calldata,
chain, canonical block hash and the matching `Withdrawn` event. A withdrawal can combine
several mission rewards or refunds. Sponsor approval is a recorded decision, not proof
of objective work quality or a unique person. Snapshot JSON is an explicit export of
already public information and must be rechecked against a trusted RPC.

## Evidence and limits

- `test-community-portability.mjs`: real routes, isolated SQLite, local deployed registry,
  CSRF/role/foreign-wallet/duplicate refusal, ownership changes, no role side effects.
- `test-community-portability-ui.mjs`: actual settings, registration, signed capsule,
  metadata update, a second member's read-only view, EN/PT and 390 px layout.
- `test-orb-social-ui.mjs`: mission-prefilled scheduling and bidirectional session link.
- `test-missions-orb-ui.mjs`: two browser wallets fund → submit → approve → withdraw
  in the panel → verify the real local receipt in the static client with Orb API offline;
  wrong-wallet and forged receipts are refused.

Privy adapters in those tests are simulated. They do not establish two-real-Privy
acceptance, public liquidity/fills, actual IPFS replication, physical microphone/live
compatibility or an independent security audit. Existing hosted chat/media remain hosted.
See [rehearsal checklist](orb-hackathon-rehearsal.md) for the remaining real-user run.