@did-btcr2/method 0.18.0 → 0.19.0

package/src/core/beacon/cid-aggregate.ts

@@ -1,153 +0,0 @@
-import { RawTransactionV2 } from '@did-btcr2/bitcoin';
-import { DidUpdateInvocation, DidUpdatePayload, MethodError } from '@did-btcr2/common';
-import { DidServiceEndpoint } from '@web5/dids';
-import { Beacon, BeaconService, BeaconSignal } from '../../interfaces/beacon.js';
-import { BeaconSidecarData, CIDAggregateSidecar, SignalsMetadata } from '../../utils/types.js';
-
-/**
- * Implements {@link https://dcdpr.github.io/did-btcr2/#cidaggregate-beacon | 5.2 CIDAggregate Beacon}.
- *
- * A Beacon of the type CIDAggregatoBeacon is a Beacon that publishes Bitcoin transactions containing a Content
- * Identifier (CID) announcing an Aggregated DID Update Bundle. An Aggregated DID Update Bundle is a JSON object that
- * maps did:btcr2 identifiers to CID values for the individual DID Update Payloads. The Aggregated DID Update Bundle CID
- * (bundleCID) SHOULD be resolvable against a Content Addressable Storage (CAS) system such as IPFS, while the CID for
- * the DID Update Payload (payloadCID) MAY be resolvable against a CAS or provided through a Sidecar mechanism. It is
- * RECOMMENDED that this type of Beacon is only included in a DID document if the DID controller is REQUIRED to
- * participate in authorizing Bitcoin transactions from this Beacon. In other words, this Beacon SHOULD identify an
- * n-of-n P2TR Bitcoin address where n is the number of unique DID controllers submitting updates through the Beacon.
- *
- * @class CIDAggregateBeacon
- * @type {CIDAggregateBeacon}
- * @extends {Beacon}
- */
-export class CIDAggregateBeacon extends Beacon {
-  /**
-   * Creates an instance of CIDAggregateBeacon.
-   * @param {BeaconService} service The service of the Beacon.
-   * @param {?BeaconSidecarData} [sidecar] The sidecar data of the Beacon.
-   */
-  constructor(service: BeaconService, sidecar?: BeaconSidecarData<CIDAggregateSidecar>) {
-    super({ ...service, type: 'CIDAggregateBeacon' }, sidecar);
-  }
-  get service(): BeaconService {
-    return {
-      type            : this.type,
-      id              : this.id,
-      serviceEndpoint : this.serviceEndpoint
-    };
-  }
-
-
-  /**
-   * TODO: Finish implementation
-   *
-   * Implements {@link https://dcdpr.github.io/did-btcr2/#establish-cidaggregate-beacon | 5.2.1 Establish CIDAggregate Beacon}.
-   *
-   * To establish a CIDAggregatorBeacon, a cohort of cooperating parties SHOULD generate an n-of-n P2TR Bitcoin address
-   * where each party contributes a public key. Furthermore, each party SHOULD verify that their key is part of the
-   * address and all other keys that are part of the address are keys with controllers able to produce valid signatures.
-   * To establish a Beacon there are two roles. One is the cohort participant, they want to join a Beacon cohort and
-   * submit a request to do so with a key and proof of control over that key. The other is the Beacon coordinator, they
-   * advertise and curate Beacon cohorts by combining Beacon participants into cohorts, verifying proofs of control, and
-   * producing Beacon addresses.
-   *
-   * @param {string} id The identifier of the Beacon.
-   * @param {string} type The type of the Beacon.
-   * @param {DidServiceEndpoint} serviceEndpoint The service endpoint of the Beacon.
-   * @returns {CIDAggregateBeacon} The established CIDAggregate Beacon.
-   */
-  static establish(id: string, type: string, serviceEndpoint: DidServiceEndpoint): CIDAggregateBeacon {
-    return new CIDAggregateBeacon({ id, type, serviceEndpoint });
-  }
-
-
-  /**
-   * TODO: Figure out if this is necessary or not.
-   * @param {string} didUpdatePayload The DID Update Payload to generate the signal for.
-   * @returns {BeaconSignal} The generated signal.
-   * @throws {MethodError} if the signal is invalid.
-   */
-  generateSignal(didUpdatePayload: string): BeaconSignal {
-    throw new MethodError('Method not implemented.', `METHOD_NOT_IMPLEMENTED`, {didUpdatePayload});
-  }
-
-
-  /**
-   * TODO: Finish implementation
-   *
-   * Implements {@link https://dcdpr.github.io/did-btcr2/#process-cidaggregate-beacon-signal | 5.2.3 Process CIDAggregate Beacon Signal}.
-   *
-   * A Beacon Signal from a CIDAggregate Beacon is a Bitcoin transaction that contains the hashBytes of a DID Update
-   * Bundle in its first transaction output. The corresponding DID Update Bundle MUST either be provided through Sidecar
-   * Data or by converting hashBytes into a IPFS v1 Content Identifier and attempting to retrieve it from Content
-   * Addressable Storage. The DID Update Bundle maps from did:btcr2 identifiers to hashes of DID Update payloads
-   * applicable for that identifier. Again this algorithm attempts to retrieve and validate the DID Update Payload
-   * identified for the identifier being resolved. If successful, the DID Update Payload is returned.
-   *
-   * The Process CIDAggregate Beacon Signal algorithm is called by the Process Beacon Signals algorithm as part of the
-   * Read operation.
-   *
-   * It takes as inputs a did:btcr2 identifier, Identifier, a Beacon Signal, tx, and a optional
-   * object, signalSidecarData, containing any sidecar data provided to the resolver for the Beacon Signal identified by
-   * the Bitcoin transaction identifier.
-   *
-   * It returns the DID Update payload announced by the Beacon Signal for the
-   * did:btcr2 identifier being resolved or throws an error.
-   *
-   * @param {RawTransactionV2} signal Bitcoin transaction representing a Beacon Signal.
-   * @param {SignalsMetadata} signalsMetadata Optional sidecar data for the Beacon Signal.
-   * @returns {Promise<DidUpdatePayload | undefined>} The DID Update payload announced by the Beacon Signal.
-   * @throws {DidError} if the signalTx is invalid or the signalsMetadata is invalid.
-   */
-  processSignal(signal: RawTransactionV2, signalsMetadata: SignalsMetadata): Promise<DidUpdateInvocation | undefined> {
-    throw new MethodError('Method not implemented.', `METHOD_NOT_IMPLEMENTED`, {signal, signalsMetadata});
-  }
-
-  /**
-   * TODO: Finish implementation
-   *
-   * Implements {@link https://dcdpr.github.io/did-btcr2/#broadcast-cidaggregate-beacon-signal | 5.2.2 Broadcast CIDAggregate Beacon Signal}.
-   *
-   * The Broadcast CIDAggregate Beacon Signal algorithm involving two roles: a set of cohort participants and a Beacon
-   * coordinator. The Beacon coordinator collects individual DID Update Payload Content Identifiers (CIDs) for specific
-   * did:btcr2 idntifiers and aggregates them into a DID Update Bundle, which is then published to a Content Addressable
-   * Storage (CAS). The CID for the DID Update Bundle is included in a Partially Signed Bitcoin Transaction (PSBT) transaction
-   * output spent from the Beacon’s n-of-n address. Each of the n cohort participants in the Beacon MUST sign the
-   * transaction before it can be broadcast to the network. It is RECOMMENDED that cohort participants keep a copy of
-   * the DID Update Bundle and separately pin it to the CAS.
-   *
-   * @param {DidUpdatePayload} didUpdatePayload The verificationMethod object to be used for signing.
-   * @returns {SignalsMetadata} Successful output of a bitcoin transaction.
-   * @throws {SingletonBeaconError} if the bitcoin address is invalid or unfunded.
-   */
-  broadcastSignal(didUpdatePayload: DidUpdatePayload): Promise<SignalsMetadata> {
-    throw new MethodError('Method not implemented.', `METHOD_NOT_IMPLEMENTED`, didUpdatePayload);
-  }
-
-  /**
-   * TODO: Finish implementation
-   *
-   * 5.2.1.1 Create CIDAggregate Beacon Advertisement
-   * Any entity MAY act in the role of Beacon coordinator, creating a Beacon advertisement that they can broadcast across any medium. A Beacon advertisement specifies the properties of the Beacon that
-   * the coordinator intends to establish, including the Beacon Type, cohort size, update frequency, and response latency. Once the advertisement has been created and broadcast, the coordinator waits
-   * for enough participants to opt in before establishing the Beacon.
-   *
-   * 5.2.1.2 CIDAggregate Beacon Opt-in
-   * DID controllers who wish to participate in a Beacon cohort first find potential Beacon advertisements that meet their needs. This includes checking the Beacon terms and update frequency, etc. If
-   * satisfied, they create a secp256k1 cohort keypair and send an Opt-In request to the endpoint specified in the advertisement.
-   *
-   * 5.2.1.3 Cohort Set
-   * Once a Beacon Aggregator has received enough opt-in responses from participants to satisfy the Beacon properties, they generate the n-of-n P2TR Bitcoin address for the Beacon. The address and all
-   * the cohort public keys the address is constructed from are then sent to all participants in a CohortSet message.
-   *
-   * 5.2.1.4 Add Beacon Service Endpoint to DID Document
-   * A participant receiving a CohortSet message first verifies their cohort key is included in the cohort, then calculates the P2TR Beacon address for themselves and verifies it matches the address
-   * provided. They MAY wait until the Beacon address is funded before adding the Beacon as a service in the DID document. The following is an example of the Beacon service endpoint the DID controller
-   * adds into their DID document, the Beacon address is converted into a URI following BIP21:
-   * {
-   *    "id": "#cidAggregateBeacon",
-   *    "type": "CIDAggregateBeacon",
-   *    "serviceEndpoint": "bitcoin:tb1pfdnyc8vxeca2zpsg365sn308dmrpka4e0n9c5axmp2nptdf7j6ts7eqhr8"
-   * }
-   */
-}

package/src/core/beacon/smt-aggregate.ts

@@ -1,135 +0,0 @@
-import { RawTransactionV2 } from '@did-btcr2/bitcoin';
-import { DidUpdatePayload, MethodError } from '@did-btcr2/common';
-import { DidServiceEndpoint } from '@web5/dids';
-import { Beacon, BeaconService, BeaconSignal } from '../../interfaces/beacon.js';
-import { BeaconSidecarData, SignalsMetadata, SMTAggregateSidecar } from '../../utils/types.js';
-
-/**
- * TODO: Finish implementation
- *
- * Implements {@link https://dcdpr.github.io/did-btcr2/#smtaggregate-beacon | 5.3 SMTAggregate Beacon}.
- *
- * A SMTAggregate Beacon is a Beacon whose Beacon Signals are Bitcoin transactions containing the root of a Sparse
- * Merkle Tree (SMT). The SMT root attests to a set of DID Update Payloads, however, the updates themselves MUST be
- * provided along with a proof of inclusion against the SMT root through a Sidecar mechanism during resolution. Using
- * the SMT root a resolver can then verify the inclusion proof for the given DID Update Payload. If a DID document
- * includes a SMTAggregator Beacon in their set of Beacon services, then they MUST provide proofs for each signal that
- * the Beacon broadcasts. If they did not submit an update to their DID in a signal, then they MUST provide a proof of
- * non-inclusion for that signal.
- *
- * @class SMTAggregateBeacon
- * @type {SMTAggregateBeacon}
- * @extends {Beacon}
- */
-export class SMTAggregateBeacon extends Beacon {
-  /**
-   * Creates an instance of SMTAggregateBeacon.
-   * @param {BeaconService} service The Beacon service.
-   * @param {?BeaconSidecarData} [sidecar] Optional sidecar data.
-   */
-  constructor(service: BeaconService, sidecar?: BeaconSidecarData<SMTAggregateSidecar>) {
-    super({ ...service, type: 'SMTAggregateBeacon' }, sidecar);
-  }
-
-  /**
-   * Get the Beacon service.
-   * @readonly
-   * @type {BeaconService} The Beacon service.
-   */
-  get service(): BeaconService {
-    const service = {
-      type            : this.type,
-      id              : this.id,
-      serviceEndpoint : this.serviceEndpoint
-    };
-    return service;
-  }
-
-  /**
-   * TODO: Figure out if this is necessary or not.
-   * @param {string} didUpdatePayload The DID Update Payload to generate the signal for.
-   * @returns {BeaconSignal} The generated signal.
-   * @throws {MethodError} if the signal is invalid.
-   */
-  public generateSignal(didUpdatePayload: string): BeaconSignal {
-    throw new MethodError('Method not implemented.', `METHOD_NOT_IMPLEMENTED`, {didUpdatePayload});
-  }
-
-  /**
-   * Implements {@link https://dcdpr.github.io/did-btcr2/#establish-beacon | 5.3.1 Establish Beacon}.
-   *
-   * The Establish Beacon algorithm is essentially the same as for the CIDAggregate Beacon in Establish CIDAggregate
-   * Beacon. A cohort of DID controllers need to coordinate to produce a Bitcoin address that will act as the Beacon.
-   * It is RECOMMENDED this is an n-of-n P2TR address, with n being the set of DID controllers in the cohort. Once the
-   * address has been created, and all parties in the cohort acknowledge their intention to participate in that Beacon,
-   * each DID controller SHOULD add the Beacon as a service to their DID document.
-   *
-   * Additionally, the SMTAggregate Beacon cohort participants MUST register the did:btcr2 identifiers they intend use
-   * this Beacon with. This is so the Beacon coordinator can generate the necessary proofs of both inclusion and
-   * non-inclusion for each DID.
-   *
-   * Static, convenience method for establishing a Beacon object.
-   *
-   * @param {string} id The Beacon ID.
-   * @param {string} type The Beacon type.
-   * @param {DidServiceEndpoint} serviceEndpoint The service endpoint.
-   * @returns {Beacon} The Beacon.
-   */
-  public static establish(id: string, type: string, serviceEndpoint: DidServiceEndpoint): SMTAggregateBeacon {
-    return new SMTAggregateBeacon({ id, type, serviceEndpoint });
-  }
-
-  /**
-   *
-   * Implements {@link https://dcdpr.github.io/did-btcr2/#broadcast-smtaggregate-beacon-signal | 5.3.2 Broadcast SMTAggregate Beacon Signal}.
-   *
-   * See {@link Beacon.broadcastSignal | Beacon Interface Method broadcastSignal} for more information.
-   *
-   * To publish a DID Update Payload, the DID controller MUST get a hash of the DID Update Payload included at the leaf
-   * of the Sparse Merkle Tree (SMT) identified by their did:btcr2 identifier and receive an inclusion proof for this
-   * data. If a member of the Beacon cohort does not wish to announce an update in a Beacon Signal, they MUST receive
-   * and verify a proof of non-inclusion for their DID. Upon verifying the non-inclusion proof against the SMT root
-   * contained in the Beacon Signal, they SHOULD accept and authorize the signal following the MuSig2 protocol. Once all
-   * members of the cohort have authorized the signal, it can be broadcast as a transaction to the Bitcoin network. DID
-   * controllers are responsible for persisting their DID updates and proofs, these will need to be provided through a
-   * Sidecar mechanism during a resolution process.
-   *
-   * @param {DidUpdatePayload} didUpdatePayload The DID Update Payload to broadcast.
-   * @returns {Promise<SignalMetadata>} The signal metadata.
-   * @throws {MethodError} if the signal is invalid.
-   */
-  public broadcastSignal(didUpdatePayload: DidUpdatePayload): Promise<SignalsMetadata> {
-    throw new MethodError('Method not implemented.', `METHOD_NOT_IMPLEMENTED`, didUpdatePayload);
-  }
-
-
-  /**
-   * Implements {@link https://dcdpr.github.io/did-btcr2/#process-smtaggregate-beacon-signal | 5.3.3 Process SMTAggregate Beacon Signal}.
-   *
-   * See {@link Beacon.processSignal | Beacon Interface Method processSignal} for more information.
-   *
-   * A Beacon Signal from a SMTAggregate Beacon is a Bitcoin transaction with the first transaction output of the format
-   * [OP_RETURN, OP_PUSH32, <32bytes>]. The 32 bytes of data contained within this transaction output represent the root
-   * of a Sparse Merkle Tree (SMT). This SMT aggregates a set of hashes of DID Update payloads. In order to process
-   * these Beacon Signals, the resolver MUST have been passed Sidecar data for this signal containing either the DID
-   * Update payload object and a SMT proof that the hash of this object is in the SMT at the leaf indexed by the
-   * did:Identifier being resolved. Or theSidecar data:: MUST contain a proof that the leaf indexed by the
-   * did:Identifier is empty, thereby proving that theSMT:: does not contain an update for their identifier.
-   *
-   * The Process SMTAggregate Beacon Signal is called by the Process Beacon Signals algorithm as part of the Read
-   * operation. It takes as inputs a did:btcr2 identifier, Identifier, a Beacon Signal, tx, and a optional object,
-   * signalSidecarData, containing any sidecar data provided to the resolver for the Beacon Signal identified by the
-   * Bitcoin transaction identifier.
-   *
-   * It returns the DID Update payload announced by the Beacon Signal for the did:btcr2 identifier being resolved or
-   * throws an error.
-   *
-   * @param {RawTransactionV2} signal The raw transaction signal.
-   * @param {SignalsMetadata} signalsMetadata The signals metadata.
-   * @returns {Promise<DidUpdatePayload | undefined>} The updated DID document.
-   * @throws {MethodError} if the signal is invalid.
-   */
-  public processSignal(signal: RawTransactionV2, signalsMetadata: SignalsMetadata): Promise<DidUpdatePayload | undefined> {
-    throw new MethodError('Method not implemented.', `METHOD_NOT_IMPLEMENTED`, {signal, signalsMetadata});
-  }
-}

package/src/core/crud/deactivate.ts

@@ -1,13 +0,0 @@
-import { DidBtcr2 } from '../../did-btcr2.js';
-
-/**
- * Implements {@link https://dcdpr.github.io/did-btcr2/#deactivate | 4.4 Deactivate}
- * To deactivate a did:btcr2, the DID controller MUST add the property deactivated with the value true on the DID
- * document. To do this, the DID controller constructs a valid DID Update Payload with a JSON patch that adds this
- * property and announces the payload through a Beacon in their current DID document following the algorithm in Update.
- * Once a did:btcr2 has been deactivated this state is considered permanent and resolution MUST terminate.
- * @class Deactivate
- * @type {Deactivate}
- * @extends {DidBtcr2}
- */
-export class Deactivate extends DidBtcr2 {}