Copy English

Why

Two projects, opposite architectures, and the same premise underneath: an account or a file path is a poor long-term identity.

ERC-7812 is the standardisation attempt. Provable identity is fragmented — Privado ID, EAS, Rarimo each carry their own registry — and the proposal is to collapse that into one singleton on-chain registry where any protocol can store and prove statements by zero-knowledge proof without publishing the underlying data. Vitalik is a co-author. The Rationale section on why a singleton is the part to read, because the argument for one shared registry over many is the whole design decision and everything else follows from it. This card sits between dsrv-portal, which asks who vouches for a credential, and erc-8141, which asks what the protocol absorbs — the middle question is where the statement lives.

Docbank is the clearest example of the opposite bet, and it is worth running rather than reading about. Agents that file, retrieve and revise documents need a system of record, not a sync folder — and a file path makes a poor identity once things get moved and renamed. Docbank's answer: the catalogue stays on your machine, a document keeps its identity through moves, every version is named by a verifiable SHA-256 digest, and stale automation hits an explicit revision conflict instead of silently overwriting. That last property is the one that matters for agent-facing archives, because a silent overwrite by an agent working from stale state is exactly the failure that has no signal at run time.

Holding them in one card makes the shared conclusion visible. Both refuse to let the location be the identity — one replaces it with a registry entry provable by ZK, the other with a node ID and a content digest. The difference is where the authoritative record lives and who can be made to answer for it, and that is the same question priced-by-the-wrong-thing reaches from tokenised equity and build-rent-or-own-the-rail reaches from bank ledgers. The ledger is always the easy half.

How it works

Same premise, opposite architectures

What to read in the standard

The Rationale, and specifically why a singleton. The argument that one shared registry beats many is the design decision; storage layout, proof format and interface all follow from it. The reference implementation (rarimo/evidence-registry) is where to check whether the argument survives contact with code.

What Docbank does that a sync folder does not

Apache-2.0, Go 1.26+ with CGO and Node 24+ to build from source. Sibling project to msgvault, which does the same for messages.

The shared conclusion

Neither lets the location be the identity, and both make the record verifiable by something other than trust in a provider. The registry does it by publishing a proof and withholding the data; the vault does it by publishing nothing and keeping a digest. Which one is right depends entirely on who has to be convinced — a counterparty who was never in the room, or you in five years.

Where it lands in Jayverse

• Personas: give each persona a stable ID, not a filename or off-chain path. Metadata should keep identity across renames/moves; version each persona's metadata by content digest so an update is provably the same persona, not a new one.
• Number: address each distributed reading by a content digest, and make stale writes conflict instead of silently overwriting. A reading's filename should not be its identity; a revision-conflict on stale automation is safer than a silent overwrite of an indicator.
• Auditor: record which model — on-chain-provable registry or off-chain digest-addressed record — each Jayverse identity artifact follows, and who is accountable for it. Persona metadata and Number readings don't need the same answer, but each needs a stated one.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

기록은 경로가 아니다 — 같은 문제의 레지스트리와 금고

ERC-7812 은 어떤 프로토콜이든 데이터를 공개하지 않고 ZK 로 신원 진술을 저장·증명할 수 있는 온체인 레지스트리 하나를 제안합니다. Docbank 는 같은 전제에서 정반대 베팅을 합니다 — 카탈로그는 내 기계에 남고, 파일 경로가 아니라 안정적인 노드 ID 가 정체성입니다.

표준 쪽은 읽기 전용 — 지갑 불필요. 왜 싱글턴인가를 다루는 ERC-7812 의 Rationale 부터, 그다음 레퍼런스 구현: eips.ethereum.org/EIPS/eip-7812 · github.com/rarimo/evidence-registry. 금고 쪽은 설치해서 돌립니다: docbank add ~/Documents --dest /archive → docbank tree /archive → docbank web. 알파 소프트웨어이므로 대체 불가한 것은 독립 사본을 유지하세요. github.com/kenn-io/docbank

왜

프로젝트 둘, 정반대 아키텍처, 그리고 밑에 깔린 같은 전제: 계정이나 파일 경로는 장기 정체성으로 형편없다.

ERC-7812 은 표준화 시도입니다. 증명 가능한 신원은 파편화돼 있습니다 — Privado ID·EAS·Rarimo 가 각자 자기 레지스트리를 갖고 있습니다 — 그리고 제안은 그것을 온체인 싱글턴 레지스트리 하나로 접자는 것입니다. 거기서 어떤 프로토콜이든 원본 데이터를 공개하지 않고 영지식 증명으로 진술을 저장하고 증명합니다. Vitalik 이 공동 저자입니다. 읽을 부분은 왜 싱글턴인가를 다루는 Rationale 입니다 — 여럿 대신 하나의 공유 레지스트리를 택하는 논거가 설계 결정 전부이고 나머지는 거기서 따라 나옵니다. 이 카드는 누가 자격증명을 보증하나를 묻는 dsrv-portal 과 프로토콜이 무엇을 흡수하나를 묻는 erc-8141 사이에 앉습니다 — 가운데 질문이 그 진술이 어디 사는가입니다.

Docbank 은 정반대 베팅의 가장 선명한 사례이고, 읽기보다 돌려 볼 값이 있습니다. 문서를 정리·검색·개정하는 에이전트에게 필요한 것은 동기화 폴더가 아니라 기록 시스템이고 — 파일 경로는 옮기고 이름을 바꾸는 순간 형편없는 정체성이 됩니다. Docbank 의 답: 카탈로그는 내 기계에 남고, 문서는 이동을 관통해 정체성을 유지하며, 모든 버전은 검증 가능한 SHA-256 다이제스트로 이름 붙고, 낡은 자동화는 조용히 덮어쓰는 대신 명시적 리비전 충돌에 부딪힙니다. 마지막 성질이 에이전트용 아카이브에서 중요한 것입니다 — 낡은 상태로 일하는 에이전트의 조용한 덮어쓰기가, 실행 시점에 신호가 없는 바로 그 실패이기 때문입니다.

한 카드에 두면 공통 결론이 보입니다. 둘 다 위치가 정체성이 되는 것을 거부합니다 — 하나는 ZK 로 증명 가능한 레지스트리 항목으로, 다른 하나는 노드 ID 와 콘텐츠 다이제스트로 대체합니다. 차이는 권위 있는 기록이 어디 살고 누구에게 책임을 물을 수 있는가이고, priced-by-the-wrong-thing 이 토큰화 주식에서, build-rent-or-own-the-rail 이 은행 원장에서 도달하는 같은 질문입니다. 원장은 언제나 쉬운 절반입니다.

동작 방식

같은 전제, 정반대 아키텍처

표준에서 읽을 것

Rationale, 그중에서도 왜 싱글턴인가. 여럿보다 하나의 공유 레지스트리가 낫다는 논거가 설계 결정이고, 저장 레이아웃·증명 형식·인터페이스가 전부 거기서 따라 나옵니다. 레퍼런스 구현(rarimo/evidence-registry)이 그 논거가 코드와 부딪혀도 살아남는지 확인할 자리입니다.

Docbank 이 동기화 폴더와 다르게 하는 것

Apache-2.0, 소스 빌드에는 Go 1.26+ (CGO) 와 Node 24+. 메시지에 대해 같은 일을 하는 자매 프로젝트 msgvault 가 있습니다.

공통 결론

둘 다 위치가 정체성이 되게 두지 않고, 둘 다 공급자에 대한 신뢰가 아닌 것으로 기록을 검증 가능하게 만듭니다. 레지스트리는 증명을 공개하고 데이터를 보류해서, 금고는 아무것도 공개하지 않고 다이제스트를 쥐고 있어서. 어느 쪽이 맞는지는 전적으로 누구를 설득해야 하는가에 달렸습니다 — 그 자리에 없었던 거래상대냐, 5년 뒤의 나 자신이냐.

Jayverse에서의 위치

• Personas: 각 페르소나에 파일명이나 오프체인 경로가 아니라 고정된 ID를 부여한다. 이름 변경이나 이동에도 정체성이 유지되어야 하며, 페르소나 메타데이터 버전은 콘텐츠 다이제스트로 관리해 업데이트가 새 페르소나가 아니라 같은 페르소나임을 증명할 수 있게 한다.
• Number: 배포되는 각 리딩을 콘텐츠 다이제스트로 주소화하고, 오래된 쓰기는 덮어쓰지 않고 충돌시킨다. 리딩의 정체성은 파일명이 아니어야 하며, 오래된 자동화가 지표를 조용히 덮어쓰는 것보다 리비전 충돌이 더 안전하다.
• Auditor: 페르소나 메타데이터와 Number 리딩 각각이 온체인 증명 레지스트리 모델인지 오프체인 다이제스트 기록 모델인지, 누가 책임지는지 기록한다. 둘이 같은 답일 필요는 없지만 각각 명시된 답은 있어야 한다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑