update concord backend
This commit is contained in:
@@ -132,10 +132,10 @@ Account-key sites to migrate:
|
||||
| `cord03::seal_rumor` (`cord03.rs:295`) | `author: &Keys` | `author: &S` | `AsyncGetPublicKey + AsyncSignEvent` |
|
||||
| `list::build_list_event` (`list.rs:186`) | `keys: &Keys` | `keys: &S` | all three |
|
||||
| `list::parse_list_event` (`list.rs:197`) | `keys: &Keys` | `keys: &S` | `AsyncGetPublicKey + AsyncNip44` |
|
||||
| `cord05::{build_direct_invite, unwrap_direct_invite}` (`:451,478`) | `inviter`/`recipient: &Keys` | `&S` (stage 3) | build: all three; unwrap: `AsyncNip44` |
|
||||
| `cord05::{build_direct_invite, unwrap_direct_invite}` (`:451,478`) | `inviter`/`recipient: &Keys` | **done** | build: all three (`Sized`); unwrap: `AsyncNip44` (`Sized`) |
|
||||
| `cord05::{build_invite_list, parse_invite_list}` (`:593,604`) | `keys: &Keys` | **done** | build: all three; parse: `AsyncGetPublicKey + AsyncNip44` |
|
||||
| `cord06::build_blob` (`:302`) | `rotator: &Keys` | `rotator: &S` (stage 3) | `AsyncGetPublicKey + AsyncNip44` |
|
||||
| `cord06::open_blob` (`:319`) | `recipient: &Keys` | `recipient: &S` (stage 3) | `AsyncNip44` |
|
||||
| `cord06::build_blob` (`:302`) | `rotator: &Keys` | **done** | `AsyncGetPublicKey + AsyncNip44` |
|
||||
| `cord06::open_blob` (`:319`) | `recipient: &Keys` | **done** | `AsyncNip44` |
|
||||
| `cord06::{build_rekey_chunks, seal_dissolved}` (`:602,737`) | actor `&Keys` | **done** | `AsyncGetPublicKey + AsyncSignEvent` |
|
||||
|
||||
Leave unchanged: `cord05::{build_bundle_event, build_revocation}`, all
|
||||
@@ -190,8 +190,8 @@ shared helpers, so the unwired callers had to be migrated in the same pass to
|
||||
keep the crate compiling: `cord05::{build_invite_list, parse_invite_list}` and
|
||||
`cord06::{build_rekey_chunks, seal_dissolved}` (Phase 3's mechanical part).
|
||||
`cord05::{build_direct_invite, unwrap_direct_invite}` and
|
||||
`cord06::{build_blob, open_blob}` are untouched — they use the NIP-59 and
|
||||
group-key paths, not the migrated helpers — and remain `&Keys` for Phase 3.
|
||||
`cord06::{build_blob, open_blob}` were untouched by Phase 1 — they use the NIP-59
|
||||
and group-key paths, not the migrated helpers — and were migrated in Phase 3.
|
||||
|
||||
### Phase 2 — app uses the signer — DONE
|
||||
|
||||
@@ -228,14 +228,28 @@ contract the registry depends on: `create` persists a state `load` returns, the
|
||||
subscription filter addresses the genesis wraps, `fold` yields the created
|
||||
community, and an inbound control edit folds over it.
|
||||
|
||||
### Phase 3 — migrate the remaining unwired writers
|
||||
### Phase 3 — migrate the remaining unwired writers — DONE
|
||||
|
||||
`cord05` direct invite / invite list, `cord06` blob/rekey/dissolved, when (or
|
||||
before) the flows that use them are wired. The helpers already force the
|
||||
`cord05` invite-list and `cord06` rekey/dissolved writers to be generic and
|
||||
`async` (see Phase 1); what remains is `cord05::{build_direct_invite,
|
||||
unwrap_direct_invite}` and `cord06::{build_blob, open_blob}`, plus keeping the
|
||||
`Sized` generics (no `&dyn`) for the NIP-59 paths.
|
||||
`cord05::{build_direct_invite, unwrap_direct_invite}` and
|
||||
`cord06::{build_blob, open_blob}` now take a signer. The NIP-59 pair keeps a
|
||||
`Sized` `S` (`AsyncGetPublicKey + AsyncSignEvent + AsyncNip44` to build,
|
||||
`AsyncNip44` to unwrap) because the SDK's `GiftWrapBuilder::finalize_async` and
|
||||
`UnwrappedGift::from_gift_wrap_async` are `Sized`-bounded. The blob pair is
|
||||
`AsyncGetPublicKey + AsyncNip44` to build and `AsyncNip44` to open, with `?Sized`.
|
||||
|
||||
The blobs forced one behavior change, because a signer's NIP-44 is text-only
|
||||
(`nip44_encrypt_async(public_key, &str)`) while the blob plaintext is a
|
||||
fixed-width binary record. `build_blob` now carries that record base64-encoded
|
||||
inside the NIP-44 envelope and `open_blob` decodes it again. The record layout,
|
||||
the `locator`, and the envelope are unchanged; only the bytes inside the envelope
|
||||
differ. There are no golden vectors for blobs and no producer or consumer other
|
||||
than these two functions, so the round-trip stays self-consistent; cord06 remains
|
||||
unwired and persists nothing.
|
||||
|
||||
Validation: `cargo test -p concord` — 46 passed, 0 failed (the 80-blob
|
||||
`a_full_send_chunk_stays_within_a_relay_event` size assertion still holds under
|
||||
the base64 record). `cargo clippy -p concord --all-targets` and
|
||||
`cargo fmt -p concord --check` are clean.
|
||||
|
||||
### Phase 4 — duplication and hygiene (independent, low risk)
|
||||
|
||||
@@ -282,7 +296,9 @@ Truly unreferenced even by tests (safe candidates, but kept per D1):
|
||||
|
||||
- No mass deletion of unwired modules (D1).
|
||||
- No changes to frozen HKDF derivations, locators, golden vectors, or `cord01`
|
||||
envelope semantics.
|
||||
envelope semantics. The one exception Phase 3 forced is the blob plaintext
|
||||
encoding (base64 inside the envelope, see Phase 3); the blob record layout and
|
||||
`locator` are untouched.
|
||||
- No group-key encryption through the signer.
|
||||
- Tests move only alongside the code they cover.
|
||||
|
||||
|
||||
+27
-14
@@ -98,7 +98,7 @@ let invite = match cord05::parse_bundle_event(&event, &link.link_signer, &invite
|
||||
A Direct Invite arrives as a NIP-59 gift wrap addressed to the member:
|
||||
|
||||
```rust
|
||||
let (inviter, invite) = cord05::unwrap_direct_invite(&wrap, &my_keys)?;
|
||||
let (inviter, invite) = cord05::unwrap_direct_invite(&wrap, &my_keys).await?;
|
||||
```
|
||||
|
||||
Either way the invite carries `community_id`, `owner`, `owner_salt`,
|
||||
@@ -308,7 +308,7 @@ keep it against the token in the member's own Invite List — a local document
|
||||
encrypted to self, exactly like the Community List:
|
||||
|
||||
```rust
|
||||
let mut list = cord05::parse_invite_list(&my_keys, &event)?;
|
||||
let mut list = cord05::parse_invite_list(&my_keys, &event).await?;
|
||||
list.entries.push(InviteEntry {
|
||||
token: HEXLOWER.encode(&token),
|
||||
signer_sk: link_signer.secret_key().to_secret_hex(),
|
||||
@@ -319,7 +319,7 @@ list.entries.push(InviteEntry {
|
||||
expires_at: None,
|
||||
extra: Default::default(),
|
||||
});
|
||||
let event = cord05::build_invite_list(&my_keys, &list)?; // kind 13303
|
||||
let event = cord05::build_invite_list(&my_keys, &list).await?; // kind 13303
|
||||
|
||||
// Retiring is a tombstone, never a deletion: it beats a stale copy terminally.
|
||||
list.tombstones.push(InviteTombstone {
|
||||
@@ -356,12 +356,16 @@ let (control_pk, control_root) = match scope {
|
||||
RekeyScope::Channel(_) => (None, None),
|
||||
};
|
||||
|
||||
let blobs = members
|
||||
.iter()
|
||||
.map(|member| {
|
||||
cord06::build_blob(&my_keys, member, scope, plan.epoch, &new_key, control_pk.as_ref(), control_root)
|
||||
})
|
||||
.collect::<Result<Vec<_>, _>>()?;
|
||||
let mut blobs = Vec::with_capacity(members.len());
|
||||
|
||||
for member in &members {
|
||||
blobs.push(
|
||||
cord06::build_blob(
|
||||
&my_keys, member, scope, plan.epoch, &new_key, control_pk.as_ref(), control_root,
|
||||
)
|
||||
.await?,
|
||||
);
|
||||
}
|
||||
|
||||
let rekey_group = cord06::rekey_group(scope, &community_root, &community_id, plan.epoch)?;
|
||||
let wraps = cord06::build_rekey_chunks(
|
||||
@@ -375,7 +379,8 @@ let wraps = cord06::build_rekey_chunks(
|
||||
citation,
|
||||
false,
|
||||
now_secs,
|
||||
)?;
|
||||
)
|
||||
.await?;
|
||||
```
|
||||
|
||||
On the receiving side, `cord06::parse_rekey_chunk(&opened)` per wrap, then
|
||||
@@ -385,11 +390,15 @@ member finds their delivery with `find_my_blobs` / `open_blob`, and adopts the k
|
||||
only if the plaintext binds to the scope and epoch they expect and its `prevcommit`
|
||||
matches the key they already hold. Two concurrent rotations settle on `fork_winner`.
|
||||
|
||||
The blob plaintext is a fixed-width binary record, but a signer's NIP-44 is
|
||||
text-only, so `build_blob` carries it base64-encoded inside the envelope.
|
||||
`open_blob` mirrors that, so the record layout and the `locator` are unchanged.
|
||||
|
||||
Dissolution is owner-only and terminal:
|
||||
|
||||
```rust
|
||||
let rumor = cord06::dissolved_tombstone_rumor(owner_pk, &community_id, now_secs);
|
||||
let wrap = cord06::seal_dissolved(&rumor, &community_id, &my_keys, now_secs)?;
|
||||
let wrap = cord06::seal_dissolved(&rumor, &community_id, &my_keys, now_secs).await?;
|
||||
|
||||
// A receiver seals the community read-only on sight.
|
||||
if cord06::verify_dissolved(&wrap, &identity) {
|
||||
@@ -534,9 +543,13 @@ client.subscribe(filter).with_id(sub_id).await?;
|
||||
address changes (join, channel added, rekey folded). GPUI integration above is
|
||||
the shape to build, not code that exists.
|
||||
- **Account-key writers take any signer, not `&Keys`.** `genesis`,
|
||||
`ControlWriter`, the guestbook and chat `seal_rumor`s and the `list` builders are
|
||||
`async` and generic over the SDK's `AsyncGetPublicKey` / `AsyncSignEvent` /
|
||||
`AsyncNip44` traits, so a `Keys` and an app `UniversalSigner` both work.
|
||||
`ControlWriter`, the guestbook and chat `seal_rumor`s, the `list` builders, and
|
||||
the `cord05` invite writers (`build_direct_invite` / `unwrap_direct_invite`,
|
||||
`build_invite_list` / `parse_invite_list`) and `cord06` blob writers
|
||||
(`build_blob` / `open_blob`) are `async` and generic over the SDK's
|
||||
`AsyncGetPublicKey` / `AsyncSignEvent` / `AsyncNip44` traits, so a `Keys` and an
|
||||
app `UniversalSigner` both work. The NIP-59 paths (`build_direct_invite`,
|
||||
`unwrap_direct_invite`) stay `Sized` because the SDK's gift-wrap helpers are.
|
||||
Group-key and locally-held-secret writers (`cord01` wrap functions,
|
||||
`cord05::build_bundle_event`, `store`) still take the raw key material they
|
||||
genuinely need.
|
||||
|
||||
Reference in New Issue
Block a user