Implement a delete method and state on the @web5/api Record class

[LiranCohen]

This PR Allows a Record class to include a deleted state based on a RecordsDeleteMessage being applied to it.

We update the RecordModel to reflect the immutable properties that a record may contain, as well as the optional mutable properties that are only relevant to a record that is in a non-deleted state.

When a record is in a deleted state, it derives the immutable properties from the initialWrite of that record.

Currently when dealing with a remote DWN, the user cannot be notified of a deleted state through a Query, however when Subscriptions are brought up to the API a user could receive a message from the remote which signals that the record has been deleted, more useful scenario testing will be implemented when record.subscribe() feature is added.

• Implements a delete() method on the Record class that behaves similarly to update().
• Implements a deleted property on the Record class to indicate if the record is in a deleted state.

[changeset-bot]

🦋 Changeset detected

Latest commit: f8469f1

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@web5/api	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

TBDocs Report

✅ No errors or warnings

@web5/api

• Project entry file: packages/api/src/index.ts

@web5/crypto

• Project entry file: packages/crypto/src/index.ts

@web5/crypto-aws-kms

• Project entry file: packages/crypto-aws-kms/src/index.ts

@web5/dids

• Project entry file: packages/dids/src/index.ts

@web5/credentials

• Project entry file: packages/credentials/src/index.ts

---

TBDocs Report Updated at 2024-05-30T13:38:18Z f8469f1

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.92%. Comparing base (2fc32ba) to head (f8469f1).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #635      +/-   ##
==========================================
+ Coverage   90.81%   90.92%   +0.11%     
==========================================
  Files         119      119              
  Lines       30101    30258     +157     
  Branches     2243     2276      +33     
==========================================
+ Hits        27337    27513     +176     
+ Misses       2729     2710      -19     
  Partials       35       35              

Components	Coverage Δ
agent	80.85% <ø> (ø)
api	95.28% <100.00%> (+1.27%)	⬆️
common	98.68% <ø> (ø)
credentials	94.88% <ø> (ø)
crypto	93.81% <ø> (ø)
dids	97.32% <ø> (ø)
identity-agent	96.70% <ø> (ø)
crypto-aws-kms	100.00% <ø> (ø)
proxy-agent	96.70% <ø> (ø)
user-agent	96.70% <ø> (ø)

[frankhinek]

@LiranCohen worth noting that this exact functionality was removed in a prior PR:

#327

Relevant section:

Removes the record.delete() instance method from Record objects. This method is the only one that is a duplicate of the identically named web5.dwn.records.* method and introduces unintuitive and error prone behavior when the record was initially retrieved from a remote DWN. Another class of issues is then introduced depending on whether that record already exists locally. In order to remove this "foot gun" and keep the DWN Records API provided by @web5/api free of duplicates that behavior differently depending on unintuitive context, the instance method was removed.

It's been a while but @csuwildcat, @angiejones , and @blackgirlbytes might recall some other context of the motivation for removing this.

[LiranCohen]

RE the previous "foot gun", we now account for the initialWrite within the Record class and can store/import the state of a deleted record even if it did not already exist locally.

I was thinking in a subsequent PR to remove the web5.dwn.records.delete() method as I figured that would warrant it's own discussion. But since it was brought up maybe the discussion can happen here (and functionality can still be removed in a subsequent PR to keep things smaller and reviews easier).

Are there any cases where you see it valid to be able to issue a delete while ONLY knowing the recordId of the record you're looking to delete without having that record class already on hand? If that is the case maybe we do leave both (although I agree there is some confusion there). Def worth a discussion.

Worth noting that this functionality is useful for the upcoming dwn.records.subscribe() method, as you could be subscribed to a set of records and receive the deleted state for a record you have previously received a write/update state for.

Additionally there have been discussions of allowing query() to optionally return deleted states, where this would also become useful.

[LiranCohen]

@frankhinek I spoke to both @blackgirlbytes and @csuwildcat regarding this feature and I think we are all on the same page.

@csuwildcat suggested we keep both of the delete methods as someone might want to issue a delete without having the record in hand. I don't have a strong opinion about that, and we can always remove the dwn.records.delete() method if it causes confusion and we don't think that case is necessary.

Was there anything else with the implementation itself that needed attention?

[frankhinek]

🚀 Ship it!

[thehenrytsai]

Rubber stamp. 🚀