Web5 JS v0.7.6

What's Changed

• Allow overriding of DWN hosts by @michaelneale, @mistermoe, @frankhinek in #93
• Address high severity vulnerability in socket.io-parser by @frankhinek in #98
• Add code coverage checks and badges by @diehuxx, @frankhinek in #99
• Sync fixes by @mistermoe in #103

External API Changes

• Web5.connect() now takes an options object which is documented here.

Full Changelog: v0.7.5...v0.7.6

Web5 JS v0.7.5

What's Changed

• Fix broken links in README and add missing VScode config by @frankhinek in #79
• DID Resolution Cache by @mistermoe in #81
• Fixes #84 Unable to use record.data.blob() for files > 10KB by @frankhinek in #87
• Sync Fixes by @mistermoe in #88

Full Changelog: v0.7.4...v0.7.5

Web5 JS v0.7.4

What's Changed

• Implement initial sync prototype by @mistermoe in #77
• Add support for store: false to web5.dwn.records.create() by @frankhinek in #78

Full Changelog: v0.7.3...v0.7.4

Web5 JS v0.7.3

What's Changed

• dynamic DWN host selection by @mistermoe in #64
• Adjust node count by @mistermoe in #73

The were no changes to external API methods.

Full Changelog: v0.7.2...v0.7.3

Web5 JS v0.7.2

This PR is primarily a hot fix to resolve an issue with Docusaurus not importing the bundled version intended for web browsers. An explicit /browser export was added which will be used to resolve an issue with TBD's Developer Site.

The were no changes to external API methods.

Full Changelog: v0.7.1...v0.7.2

Web5 JS v0.7.1

This is primarily a hot fix release to resolve an incorrect export path for the bundled versions for web browsers.

The only change to external API methods is that the DID is now a required value for the Protocol.send() instance method to be consistent with Record.send(). The release notes for 0.7.0 did not require modification since the DID was being specified in the examples.

What's Changed

• Fix GitHub Actions CI Tests and Update Test Profile Fixtures by @frankhinek in #65 #67
• Fix Browser Exports by @mistermoe in #68

Full Changelog: v0.7.0...v0.7.1

Web5 JS v0.7.0

The TBD open source team is thrilled to announce a new version of Web5 JS, 0.7.0. Web5 JS is a software development kit that empowers everyone to create decentralized web applications (DWAs) that return ownership of data and identity to individuals.

If you were using a previous version of Web5 JS in your project, you can get 0.7.0 through a variety of distribution channels, including:

If your project is a	you can get Web5 JS 0.7.0 with
Node.js package	npm install @tbd54566975/web5
Native web browser app	https://unpkg.com/@tbd54566975/web5@0.7.0/dist/browser.js OR https://cdn.jsdelivr.net/npm/@tbd54566975/web5@0.7.0/dist/browser.mjs

We invite everyone to help us out by testing this release, and please consider reporting any bugs you might come across. Thanks! 🙏

What's in 0.7.0

💡 Summary

The Web5 JS 0.7.0 release is a significant step towards making the creation of decentralized web applications more accessible and convenient. By simplifying the initial setup process, introducing in-browser and cloud agent capabilities, improving protocol definition readability, and refining typical DWN protocol and record operations, we aim to empower developers to innovate with ease and efficiency. The TBD open source team remains committed to continuous improvement and eagerly anticipates your feedback on this release. So, download, test, and let's work together to return ownership of data and identity back to the individuals. Happy coding!

✨ Simplify Getting Started

Previously, the first thing a developer building a decentralized web application using Web5 JS would do is:

const web5 = new Web5();

const did = await web5.did.create('ion');

await web5.did.manager.set(did.id, {
  connected: true,
  endpoint: 'app://dwn', //this points to the user's local DWN
  keys: {
      ['#dwn']: {
        keyPair: did.keys.find(key => key.id === 'dwn').keyPair,
      },
  },
});

With this release, the developer experience has been simplified to:

const { web5, did } = await Web5.connect();

To begin, the developer connects to a Web5 User Agent. A web5-user-agent acts on behalf of a user to manage identity information, public/private data, and interactions with other entities in a decentralized network. These capabilities are enabled by the underlying profile, DID, key, cryptography, and DWN management components that an Agent interacts with.

Web5 JS can be used to build Agents for a variety of deployment environments, including:

• Cloud Instances
• Desktop OS (macOS, Linux, Windows)
• Mobile OS (Android, iOS)
• Web Browsers

However, with the 0.7.0 release the focus is on in-browser and cloud agents first with a fast follow release to enable desktop agents.
Returning to our example, connect() returns a web5 instance and did:

• web5: The web5 instance returned is instantiated with a Web5 User Agent that manages DIDs, keys, an embedded DWN, and persisting the DID / key state to either browser storage or local disk, depending on whether the app is running in a browser or Node.js environment.
• did: The did returned is the automatically generated DID that is currently active in the connected Web5 User Agent.

It is also worth noting is that, previously, most DWAs had to provide a method for saving and loading profile state information (DID, keys, etc.) so that they weren't regenerated on every app launch or page reload. To simplify the developer experience, saving/loading profile state now happens automatically in both web browser and Node.js environments. A security-focused key management solution will be incorporated in a future release that will make this capability even more secure and flexible.

---

✨ Simplify Decentralized Web Node Operations

Before this release, creating a record in an app's DWN, writing the record to someone else's DWN, and then querying to confirm it was written might look like the following:

Note In this example, aliceDid and bobDid are the decentralized identifiers (DIDs) of two individuals, Alice and Bob, who are sending data back and forth using Web5 JS and DWNs they control.

// Create a record in Alice's DWN
const { record: aliceRecord, status } = await web5.dwn.records.create(aliceDid, {
  author: aliceDid,
  data: "Hello Web5",
  message: {
    dataFormat: 'text/plain'
  }
});

// Alice writes the same record to Bob's DWN
const { record: bobRecord } = await web5.dwn.records.createFrom(bobDid, {
  author: aliceDid,
  record: aliceRecord
});

// Alice queries Bob's DWN to confirm the record was written
const { entries } = await web5.dwn.records.query(bobDid, {
  author: aliceDid,
  message: {
    filter: {
      recordId: aliceRecord.id,
  },
});
const firstEntry = entries[0];
console.log(aliceRecord.id === firstEntry.id) // prints "true"

Every method call, whether a create() or query(), required specifying:

• target to direct the record creation or query to
• author who signs and transmits the request

While it makes sense that you should have to specify the DWN to send messages to for processing when it is a DWN you don't control (e.g., Alice sending to Bob), it is rather verbose to have to repeatedly reiterate aliceDid for target and author for every record operation destined for Alice's local DWN.

With 0.7.0, Web5.connect() returns an instance of web5 with a connected did profile already active. As a result, when you call methods like web5.dwn.records.create(), the agent will assume the operation should be performed on the connected DID's DWN unless you tell it otherwise. To revisit the Alice and Bob example, the code to create a record on Alice's DWN and then write it to Bob no longer requires specifying aliceDid as the target and author: to create the record and to send the same record to Bob becomes a one-liner:

// Create a record in Alice's DWN
const { record: aliceRecord } = await web5.dwn.records.create({
  data: "Hello Web5",
  message: {
    dataFormat: 'text/plain',
  },
});

// Alice writes the same record to Bob's DWN
const { status } = await record.send(bobDid);

For queries (and every web5.dwn.*.* method), the same pattern holds: if you want to perform the operation on your DID's DWN then you don't need to specify any additional properties. Alice querying her own DWN for the record created earlier is simply:

const { records } = await web5.dwn.records.query({
  message: {
    filter: {
      recordId: aliceRecord.id,
  },
});

and to query from Bob's DWN, simply add a from: property specifying the DID you wish to query from:

// Alice queries Bob's DWN to confirm the record was written
const { records } = await web5.dwn.records.query({
  from: bobDid,
  message: {
    filter: {
      recordId: aliceRecord.id,
  },
});

The last example to highlight is likely to be less frequently used, but there may be scenarios in which you intentionally do not want to write a record to your agent's DWN until after the record was written to another entity's DWN. In that case, you can use a store: false directive to skip persisting the record. If the record is successfully written to the third-party then you can either choose to never write a local copy or send it to your own remote DWN as a final step. As mentioned, this is likely to be an unusual sequence, but we'd love to hear from anyone who has this scenario in mind for an app they are building.

// Create the record but do NOT save it to Alice's DWN
const { record: aliceRecord } = await web5.dwn.records.create({
  store: false,
  data: "Hello Web5",
  message: {
    dataFormat: 'text/plain',
  },
});

// Alice writes the record to Bob's DWN
const { status } = await record.send(bobDid);
if (status.code === 202) {
  await record.send(aliceDid);
}

Check out the DWN Methods Cheat Sheet at the end of the release notes.

---

✨ Enhancements to DSL for Protocol Definitions

DWeb Nodes are designed to act the substrate upon which a wide variety of decentralized applications and services can be written. With an interface like Records alone, a DWeb Node owner and those they permission can write isolated records, but that alone is not enough to support and facilitate decentralized apps.

Protocols introduces a mechanism for declaratively encoding an app or service’s underlying protocol rules, including segmentation of records, relationships between records, data-level requirements, and constraints on how participants interact with a protocol. With the DWN Protocols mechanism, one can model the underpinning protocols for a vast array of use cases in a way that enables interop-by-default between app implementations that ride on top of them.

While this is a change in the underlying DWN SDK that Web5 JS uses to interact with DWNs, the enhancements to make the protocol definition DSL (Domain-Specific Language) were made during the development of the 0.7.0 release to improve the ease with which designers and developers could both create and interpret protocol definitions.

The prior definition format was:

{
  "labels": {
    "credentialApplicatio...

Web5 JS v0.6.3

This release solely exists to trigger the re-publication of the package to NPMJS.com. The 0.6.2 NPM package contained a corrupted dist/ directory.

Web5 JS v0.6.2

This is primarily a hot fix release to resolve two edge case bugs introduced in the v0.6.0 release. There are no changes to any external API methods.

What's Changed

• Adds automated JSDoc documentation generation by @frankhinek in #47
• Fixes an issue in a Record instance with the record.data.json() and record.data.text() methods by @frankhinek in #51
• Fixes an issue in web5.dwn.records.write() if request included data but the message was missing the dataFormat property by @frankhinek in #51
• Adds test coverage for web5.dwn.records* methods and adds improved testing utilities by @frankhinek in #51
• Updates README documentation by @csuwildcat in #52

Full Changelog: v0.6.0...v0.6.2

Web5 JS v0.6.0

What's Changed

• Refactor DID Connect and add per App DIDs by @frankhinek in #37
• Initial Permissions implementation by @dcrousso and @frankhinek in #37
• Fix delay in socket connections by adding connection delay and switching to sequential strategy by @frankhinek in #39
• Fix main and module paths in package.json by @mistermoe in #36
• Add Record class and DID Manager by @frankhinek and improvements by @dcrousso in #43

Full Changelog: v0.4.0...v0.6.0