Profile

Your profile is the name, description and icon attached to your account id. You write it once; it becomes visible in every space you belong to, without a per-space write, to every contact who holds your profile key.

Reading your account

curl -s http://127.0.0.1:7001/v1/account

{ "id": "A8g1…",
  "techSpaceId": "bafyrei…",
  "metadata": { "name": "Alice", "description": "writer, reader", "iconCid": "bafy…" } }

id is the value you exchange out of band — via a link, a QR code, or a shared space's member list — so that someone can add you by identity or open a direct chat with you.

Updating the profile

curl -s -X PUT http://127.0.0.1:7001/v1/account/metadata \
  -d '{"name": "Alice", "description": "writer, reader, occasional debugger", "iconCid": "bafy…"}'
# → 204

any account set-metadata --name "Alice" [--description "..."] [--icon-cid CID]

At least one of name / description / iconCid must be set; an all-empty body returns 400 request.missing_field. The SDK persists the bytes to the local tech space and pushes them to the identity repository, so the new profile reaches every space you are a member of. Read it back from a space's roster with GET /v1/spaces/:id/members/me.

The icon is a file CID — upload the image as a file first and pass its root CID.

Who can see it

The bytes pushed to the network are encrypted with an account-derived key that is shared with a contact only through an already-encrypted channel: a shared space's ACL metadata, or a one-to-one invite. A peer who has not received the key sees your account id only, with empty name / description / iconCid, until the key arrives and their background fetch resolves the profile.

Why it matters. Publishing a display name on a hosted service means the service knows it. Here the relay stores ciphertext; the set of people who can read your name is exactly the set of people you have shared data with.

On the receiving side this shows up in two places, both of which must tolerate an empty name:

Note. Profile writes are account-wide, not per space. There is no per-space display name; the join-time metadata passed to POST /v1/spaces/join seeds what members see before your profile key resolves, and is superseded once it does.

Redeeming an access code

An alpha invite code raises the account's limits. The server signs {purpose, ownerAnyId, code, ts} with the account key and posts it to the invite service configured as access.redeemUrl, so the key never leaves the server and the client never talks to that service:

curl -s -X POST http://127.0.0.1:7001/v1/account/access-code -d '{"code": "K7QX-4MDP-…"}'
# → {"status": "accepted", "redemptionId": "…"}

any account redeem K7QX-4MDP-…

status is accepted (the limits grant is on its way) or already_redeemed (this account redeemed a code before; nothing is consumed). The code is compared upper-cased with whitespace removed.

Related

• Accounts — where the account id comes from.
• Identities — resolving other people's profiles.
• Members and roles — the per-space roster that carries profiles alongside rights.