As Per the comment here #33 (review)

I think we might need to generate one WriteLogger for each level of severity:
error
warn
info
debug
trace

Now that nostr is installed as part of the setup locally as part of PR 9 (#9), I am proposing add the following 2 lines to the building section. Cargo should be lowercase and it might be helpful to specify the packages build into target.

cargo build
cd target/debug
#run commands above like ./civkitd

If the team agrees with such small changes to make this instruction correct and explicit, I am happy to do this.

In light of upcoming changes in the NIPs and NIP-16 being merged with NIP-01, we should look to implement NIP-16:
https://github.com/nostr-protocol/nips/blob/master/16.md

Write down documentation on how to use the components:

• user A launch civkitd and civkit-marketd
• user B launch civkit-sample and connect to civkitd, service policy from civkitd-marketd is announced with scriptpubkey to pay
• user B pay the scriptpubkey and transaction confirms
• user B generate a merkle block with getxoutproof from bitcoin core
• user B calls submitcredentialproof with the merkle proof proof and signed credentials are returned back from civkitd
• user B sends a sendmarketorder with bolt 11 invoice and board pubkey to publish ; credentials are attached and flood to civkitd
• civkitd verifies the credentials signature, stores the market order and flood to all connected clients
• user C receives a market order with the bolt11 invoice
• user C can buy good from user B by using on-chain or off-chain wallet thanks to the bolt11 invoice

When running cargo build on main this error is appearing. As a developer/contributor, I need a working main so I can fork it and run tests so fixing this is important.

This can potentially be resolved by changing the credential_msg_byte in credentialgateway.rs to be mutable.

We could also refactor the function to receive an immutable reference.

error[E0308]: mismatched types
  --> src/credentialgateway.rs:89:114
   |
89 | ... = CredentialAuthenticationPayload::decode(&credential_msg_bytes...
   |       --------------------------------------- ^^^^^^^^^^^^^^^^^^^^^ types differ in mutability
   |       |
   |       arguments to this function are incorrect
   |
   = note: expected mutable reference `&mut _`
                      found reference `&&std::string::String`

Before merging, it would be great to have very basic CI where we can check that civkit-cli, civkitd and civkit-sample binaries are building on at least Darwin, Ubuntu and Debian platform.

Here what Bitcoin Core is doing: https://github.com/bitcoin/bitcoin/tree/master/ci we can do the same just far more basic in consideration of today project maturity.

We have 200+ warnings that are not breaking the build. Alot of this could be resolved by linting and manual review. Given there are many of these, this could be quite large and broken out into smaller tasks. Leaving this as a placeholder/reminder to start.

Current civkitservice API enable one to host a civkit service on top of a blessed relay (RegisterRequest). On service registration the service policy should be propagated to relay peers and clients. Service might say what is actually offered (e.g board type) and for how long the service is accessible on this relay (e.g X days, Y months or indefinite). Service registration might happen in the future over Nostr websocket for more interface flexibility.

error[E0061]: this function takes 2 arguments but 3 arguments were supplied
   --> src/credentialgateway.rs:131:40
    |
131 | ... = ServiceDeliveranceResult::new(service_id, ret, reaso...
    |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                --------
    |                                                    | |
    |                                                    | unexpected argument of type `Vec<_>`
    |                                                    help: remove the extra argument
    |

As a developer, I need to resolve this error to run a successful cargo build. The third argument appears to be causing this issue. It could be fixed by updating ServiceDeliveranceResult to take 3 arguments.

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

The staking credentials is a cryptographic protocol enabling a Lightning node or Nostr relay to sell “services” in exchange of a pre-paid credential. The protocol has been designed to preserve client privacy by relying on blinding or anonymous credentials.

For CivKit node integration, at reception of a new client event in clienthandler (“[CIVKITD] - Nostr: Message received from {}!”), the event and its tag should be sent to the credential gateway, the gateway probe its internal state to guess if the credential has been paid. If it a success, the event should be stored and send to the clients which have subscribed.

I’m thinking to go with Bitcoin Core wallet for the first payment backend of the credential Issuer. On-chain easier than off-chain to assert the correctness of the staking credentials flow for Nostr.

Introduce and refine the new civkitservice.proto API with #45.

NIP-33 introduces the notion of “parameterized replaceable events” on top of which new proposed order event is building.

Can not start civkitd, i just build civkitd from source and run it on my local machine. However, it failed, just get an error message:

Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }

Here is what i did:

1. clone the codes via git: git clone https://github.com/civkit/civkit-node.git
2. compile: pushd civkit-node && cargo build --release
3. start: ./target/release/civkitd
   and then got the error.

Seems that I need to create some files or directories. Already tried to copy example-config.toml to config.toml, not working. Am i missing something?

Here is the OS and rust version I use:
OS: Ubuntu 20.04.3 LTS
Rustc: rustc 1.71.1 (eb26296b5 2023-08-03)

Good to have NIP-20 support, then we can return result to clients in case of failure (e.g too many events). https://github.com/nostr-protocol/nips/blob/master/20.md

Following Lightning and Bitcoin Core conventions, civkit-node could be configured respectively for mainet, testnet and signet (and regtest ?) This matters when we’ll have Mainstay support for Nostr events attestations that are dependent on chain inclusion and one can generateblock at wish.

Now we have TOML support to parse config file thanks #29 , the log could be captured in a LoggerRecord and be dropped in a file on-disk, rather being printed on stdout.

See for example: https://github.com/aljazceru/awesome-nostr?tab=readme-ov-file#relays

In light of upcoming changes in the NIPs and NIP-12 being merged with NIP-01, we should look to implement NIP-12: https://github.com/nostr-protocol/nips/blob/master/12.md

Functions required to verify event commitment proofs.

For a given sequence (https://commerceblock.readthedocs.io/en/latest/mainstay-con/index.html#proof-of-immutable-sequence) of proofs, Verification comes in 3 stages:

1. Verify the sequence of commitments in the hash chain. This involves taking the latest retrieved proof and the list of saved Events (e.g. retrieved from the DB) and repeating the computation of the hash chain of event_ids and then confirming the slot commitment of hash chain in the latest proof (this then gives the latest event that is fully attested).

2. Verify the proof path. For the latest slot proof, verify that the the commitment is included in the merkle_root this is done by successively concatenating the commitment along the path proof ("ops") as is done here: https://github.com/commerceblock/pymainstay/blob/a84c5f295143c4ac2eed8a3726c3bf1c88399338/mst/verify.py#L158

3. Finally, we need to verify that the merkle_root is included in the specified bitcoin transaction. This requires a connection to a bitcoin-cli. For the specified txid, first getrawtransaction and then get the pay to address. Confirm the address is tweaked with the merkle_root (like https://github.com/commerceblock/pymainstay/blob/a84c5f295143c4ac2eed8a3726c3bf1c88399338/mst/verify.py#L126) and then go back along the tx staychain to check the initial anchor state.

should read ws address from cli and use it

There are 4 errors in the verifycommitment_test.rs file. These should be investigated and resolved to improve the build consistency.

Our implementation of NIP-01 is not very complete, the following list of items is missing (at least).

Filtering is only implemented to match on kind in filter_events (in src/clienthandler.rs), spec says “at least one of the array’s values must match the relevant field in an event for the condition itself to be considered a match” so we should match all filter attributes (ids, authors, kinds, #e, #p, since, until).

The spec says “all conditions of a filter that are specified must match for an event for it to pass the filter, i.e., multiple conditions are interpreted as && conditions”, so when we parse an Event against Filter the event should satisfy the concatenation of all the attributes.

We do not enforce the limit property, this can be done at reception of ClientMessage::Req though here we might need a notion of a store first, see "TODO: replay stored events when there is a store”

There is no implementation of metadata assigned to our NostrClient (in src/clienthandler.rs) as a result of calling setmetadata in the sample.

There is no implementation of recommendation assigned to our NostrClient (in src/clienthandler.rs) as a result of calling recommendserver in the sample.

Our opensubscription command in the sample do not take as argument all the filter attributes (ids, authors, kinds, #e, #p, since, until), neither can accept an array of filters.

Can be splitted in multiple PRs as some of the items might be buffy.

civkitd will need a static config file on the host to discover its default settings and learn where is the nostr event database. We have already clap as a dependency so it can be used to build a parser of a TOML config file.

As an orderbook runner, I need to be able to connect to both clearnet and tor for bitcoin nodes. Tor has not yet been implemented.

A new listener will need to be implemented to allow tor connections. A good starting point is server.rs and bitcoind_client.rs to review and add tor support.

Here are some more contextual and supporting documents
https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md
https://github.com/bitcoin/bitcoin/blob/master/src/torcontrol.cpp

I forked the code and tried building it using cargo build, but it fails. When looking at our Cargo.toml file I see we imported a nostr dependency which references a local path. Are there plans to ship a nostr crate with the project? Or can we use an existing dependency? If it is something I can fix, please let me know. I will like to contribute

If we start to have more "service"-like functionality announced by the relay, NIP11. Note we might tweak the spec here to do it over LN gossips rather than HTTP, or have support for both. https://github.com/nostr-protocol/nips/blob/master/11.md