신원: 지갑 주소가 아니라 Inbox¶

지갑 주소를 그대로 메신저 ID로 쓰면 세 가지가 안 됩니다.

한 사람의 여러 지갑을 하나의 수신함으로 합치기
폰과 노트북이 각자 다른 키를 갖기 (주소의 개인키를 기기마다 복사할 수는 없다)
유출된 기기 하나만 잘라내기

XMTP v3는 이를 3계층 신원 모델로 푼다(XIP-46).

flowchart TB
  inbox["Inbox ID<br/>안정 식별자, 메시지의 수신처"]
  w1["지갑 1 (EOA)"]
  w2["지갑 2 (스마트 컨트랙트 지갑)"]
  i1["installation: 폰"]
  i2["installation: 노트북"]
  i3["installation: 태블릿"]
  inbox --> w1
  inbox --> w2
  w1 --> i1
  w1 --> i2
  w2 --> i3

계층	무엇인가	개수
Inbox ID	사용자의 안정적 식별자. 첫 지갑 주소와 nonce를 이어붙인 값의 SHA256. 메시지의 수신처는 주소가 아니라 이 값이다	사람당 1개
identity	Inbox에 연결한 지갑. EOA(EIP-191 서명)와 스마트 컨트랙트 지갑(ERC-1271 서명) 모두 지원	Inbox당 여러 개
installation	앱을 설치한 기기(정확히는 클라이언트)마다 생기는 Ed25519 키 쌍. 암복호화의 실제 주체	Inbox당 활성 10개

기기를 잃어버리면¶

Inbox의 첫 identity가 복구 주소(recovery address)가 되고, 복구 주소만 지갑이나 기기를 폐기(revoke)할 수 있습니다. 그래서 분실한 폰의 installation만 잘라내고 신원은 유지하는 운영이 가능합니다.

신원 변경은 네 가지 동작으로 이뤄진다: CreateInbox, Add, Revoke, ChangeRecoveryAddress.

installation 10개 한도가 실제로 문제가 되는 지점¶

Inbox당 활성 installation은 10개까지입니다. 브라우저 저장소가 빈 상태로 로그인할 때마다 새 installation이 등록됩니다. 그래서 다음이 슬롯을 소모합니다.

새 브라우저나 시크릿 창에서 로그인
Clear site data 후 재로그인
E2E 테스트를 빈 프로필로 반복 실행

한도에 닿으면 Client.create가 응답하지 않고 멈춥니다. 증상은 "로그인 버튼을 눌러도 수신함으로 넘어가지 않는다"입니다.

여기에 더해, MLS 키가 installation마다 다르기 때문에 새 installation은 자신이 대화에 참여하기 전의 메시지를 복호화할 수 없습니다. 네트워크에 암호문이 남아 있어도 열 키가 없습니다. 이것이 Umul에서 "대화가 사라졌다"로 보이는 현상의 정체이고, 자세한 내용과 Umul의 대응은 대화 기록에 있습니다.

신원 변경은 온체인에 남습니다¶

지갑 추가, 기기 추가, 폐기 같은 신원 변경(Identity Update)은 노드에 저장되는 일반 메시지가 아니라 블록체인 트랜잭션으로 기록됩니다. 탈중앙 노드 구현(xmtpd)은 Identity Update를 메시지 경로로 받으면 아예 거부하고, IdentityUpdateBroadcaster 컨트랙트 호출로만 받습니다.

인덱서가 그 이벤트를 다시 읽어 "주소 → Inbox ID" 매핑을 만들고, 대화를 걸기 직전의 "상대 조회"가 이 매핑을 뒤집어 읽습니다.

무엇이 체인에 남고 무엇이 노드에 남는지는 암호화와 전달에 표로 정리했습니다.