Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement AttestationManager #5

Open
ariard opened this issue Jun 12, 2023 · 4 comments
Open

Implement AttestationManager #5

ariard opened this issue Jun 12, 2023 · 4 comments

Comments

@ariard
Copy link
Contributor

ariard commented Jun 12, 2023

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 ariard mentioned this issue Jun 20, 2023
twshelton added a commit to twshelton/civkit-node that referenced this issue Jun 21, 2023
@ariard
Copy link
Contributor Author

ariard commented Jul 12, 2023

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:

  • Nostr events
  • BOLT4 onion TLV payload
  • BOLT1 messages

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
Copy link
Contributor

nicosey commented Sep 8, 2023

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

@ariard
Copy link
Contributor Author

ariard commented Sep 8, 2023

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
Copy link
Contributor

nicosey commented Sep 9, 2023

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.

@ariard ariard mentioned this issue Sep 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants