Open ariard opened 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.
@ariard do you see this as subscription based or pay per attestation? Also what would be the epochs per attestation?
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.
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.
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
(inanchormanager.rs
) should accept serialized offer payload from theBoardManager
, 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