civkit / civkit-node

CivKit Node
Other
65 stars 12 forks source link

Implement `AttestationManager` #5

Open ariard opened 1 year ago

ariard commented 1 year ago

All the offers received by the BoardManager, independently of the communications channels (BOLT4 onions, BOLT8 noise channel or NIP 01 websocket) and sources (clients or peers).

The AnchorManager (in anchormanager.rs) should accept serialized offer payload from the BoardManager, pack them in an anchor and at periodic intervals (e.g every X blocks or clock ticks), counter-sign them with the board public key and submit for validation to the selected Mainstay server.

The anchor format should be some metadata (version, time, previous anchor SHA256 hash if proof-of-immutable-sequence is opted-in) and a byte payload.

The Mainstay protocol is documented here: https://commerceblock.readthedocs.io/en/latest/mainstay-background/index.html and the original paper is available here: https://cloudflare-ipfs.com/ipns/ipfs.commerceblock.com/commerceblock-whitepaper-mainstay.pdf

ariard commented 1 year ago

After more thinking on the architecture of civkitd, the AttestationManager should be transferred more on the service-side of the Civkit, as a hosted service of the Nostr relay.

The AttestationManager should be still a full-fledge notary service like Mainstay and receive over those communication channels:

The ServiceManager should just offer a nice interface to the AttestationManager to listen to the above events and send back messages to clients or services peers.

Will be more v0.0.3ish I guess.

nicosey commented 1 year ago

@ariard do you see this as subscription based or pay per attestation? Also what would be the epochs per attestation?

ariard commented 1 year ago

I think both model can work, subscription or pay per attestation. The former sounds nicer from a UX viewpoint (e.g Nostr client don’t have to “think” about their notes attestation consumption) though the later one sounds more compelling to compensate servers, especially for worst-case scenario.

See BOLT watchtower for a discussion of payment modes, which I think applies to attestation management: https://github.com/sr-gi/bolt13/blob/master/13-watchtowers.md#payment-modes

I think the epochs for the attestation will be some service-level agreement that one announces through a gossip-like network (see BOLT7). It’s very a client-side notion what is a good epoch quality of service, and the server should price in consequence the subscription / fees.

nicosey commented 1 year ago

Ok, so we could start on a per attestation per slot for now. Make Mainstay NOSTR aware and have it stop any PK is a slot in the merkle tree.