DEV Community: TBD

What is Web5?

Angie Jones — Thu, 14 Nov 2024 21:13:57 +0000

Web 5 is a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols.

In the current web model, users do not own their data or identity. They are given accounts by companies and their data is held captive in app silos. To create a new class of decentralized apps and protocols that put individuals at the center, we must empower them with self-owned identity and restore control over their data.

Components of Web 5

There are three main pillars of the decentralized web platform, all of which are based on open standards.

Decentralized Identifiers

The identifiers we know and use today are owned by the government, a company, an organization, or some other intermediary. For example, our email addresses and social media handles are identifiers associated with us but are owned and controlled by the service providers. These companies have the right to ban, disable, or delete these identifiers and we have little to no control over this.

So before we can realize truly decentralized applications, we need decentralized identifiers that users own and control. This removes the dependency on centralized entities to authenticate and represent us.

Decentralized Identifiers (DIDs) are a W3C standard. They have a standardized structure that essentially links to you and your information.

They are a long string of text that consists of three parts:

the URI scheme identifier, which is did
the identifier for a DID method
the DID method-specific identifier

DIDs are the only component of Web5 that touch a blockchain, which is generally limited to anchoring the keys/endpoints linked to the ID.

That being said, anchoring DIDs on Bitcoin (or any blockchain) is not a requirement. In fact, what's great about having the standardized formatting for DIDs is that they can be anchored anywhere or not anchored at all and this still works, although with varying levels of decentralization.

Here are examples of DIDs on the Bitcoin blockchain, the Ethereum blockchain, and the web. Notice they all use the same format: scheme, DID method, and DID method-specific identifier.

did:btcr:xyv2-xzpq-q9wa-p7t
did:ens:some.eth
did:web:example.com

Because personal data is not stored on the blockchain, the DID essentially acts as a URI that associates the subject of the DID (the person, company, or object being identified) with a DID document that lives off-chain.

DID Documents are JSON files stored in decentralized storage systems such as IPFS, and describe how to interact with the DID subject. The DID Document contains things like the DID subject's public keys, authentication and verification methods, and service endpoints that reference the locations of the subject’s data.

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:ion:EiClkZMDxPKqC9c-umQfTkR8",
  "verificationMethod": [
    {
      "id": "did:ion:EiClkZMDxPKqC9c-umQfTkR8",
      "type": "Secp256k1VerificationKey2018",
      "controller": "did:ion:EiClkZMDxPKqC9c-umQfTkR8"
    }
  ],
  "authentication": ["did:ion:EiClkZMDxPKqC9c-umQfTkR8"]
}

Verifiable Credentials

Verifiable Credentials are a fully ratified W3C standard that work hand in hand with Decentralized Identifiers to enable trustless interactions - meaning two parties do not need to trust one another to engage, but claims made about a DID subject can be verified.

For example, Alice needs to prove she has a bank account at Acme Bank. Acme Bank issues a cryptographically signed Verifiable Credential which would be stored in Alice's identity wallet.

The credential contains the issuer as Acme and the subject as Alice, as well as the claims, which are Alice's account number and full name.

Upon request for proof of banking, Alice presents the Verifiable Credential that's cryptographically signed by both Alice as well as her bank.

This is an easy, machine-readable way to share credentials across the web. The Verifier does not know or trust Alice, but they do consider Acme trustworthy, and they have essentially vouched for Alice therefore distributing trust.

Decentralized Web Nodes

Today, centralized entities act as our data stores. Applications hold all of our content and preferences on their servers.

Decentralized Web Nodes (DWNs) change this by allowing us to decouple our data from the applications that we use, and instead host our data ourselves in our own personal data stores.

BlueSky is a good example; it's a decentralized social media app. With BlueSky, your tweets and your connections aren't stored with the application. They are stored with you. So you can present your content on any decentralized social media app you want, not just BlueSky.

Your DWNs can hold both public and encrypted data. For example, in the case of a decentralized social media app, you'd want data like your posts and your connections to be public but things like your DMs to be private.

Your decentralized web nodes do not live on the blockchain. You can host your web nodes anywhere (your phone, computer, etc) and can replicate them across your devices and clouds and all data will be synced.

While self-hosting your DWNs provides a means for decentralizing your data, we recognize some users will be more comfortable with others hosting their web nodes for convenience sake. We envision there will be vendors offering to host your web nodes for you. The good part about that is you can encrypt any private data so unlike today where cloud hosts can scan everything that you host there, you can still maintain some privacy even if you have your web nodes hosted by intermediaries.

Your DWNs are associated with your Decentralized Identifiers and are listed in a DID document.

Notice the serviceEndpoint section of the DID doc specifies service endpoints and provides URIs to the decentralized web nodes.

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:web:example.com:u:alice",
  "service": [
    {
      "id": "#dwn",
      "type": "DecentralizedWebNode",
      "serviceEndpoint": {
        "nodes": ["https://dwn.example.com", "00:11:22:33:FF:EE"]
      }
    }
  ],
  "verificationMethod": [
    {
      "id": "did:web:example.com:u:alice",
      "type": "Secp256k1VerificationKey2018",
      "controller": "did:web:example.com:u:alice"
    }
  ],
  "authentication": ["did:web:example.com:u:alice"]
}

Given an application has the address to your DWN, they can send you a request for data.

This represents a request from an application to obtain all objects within a DWN that follow the SocialMediaPosting schema:

    POST https://dwn.example.com/
    BODY {
      "requestId": "c5784162-84af-4aab-aff5-f1f8438dfc3d",
      "target": "did:example:123",
      "messages": [
        {
          "descriptor": {
            "method": "CollectionsQuery",
            "schema": "https://schema.org/SocialMediaPosting"
          }
        },
        {...}
      ]
    }

The data within DWNs are JSON objects that follow a universal standard, thus making it possible for any application to discover and process the data given its semantic type.

If this data is public, those objects will be automatically returned to the application, and if the data is private, the node owner would need to grant the application access to that data.

Identity Wallets

Obviously all of this is pretty complicated, especially for non-technical users. So we need a simplistic, easy to use interface that will allow people to access and manage their identity.

A well designed identity wallet would provide ways to manage the data stored in decentralized web nodes, the decentralized IDs and the context in which they should be used, verifiable credentials, and authorizations.

Decentralized Web Apps

Web 5 enables developers to build decentralized web applications (DWAs) on top of it and it’s all open source! You're free to use it as your foundation and focus your attention on what you really care about, your app. Web5 brings to DWAs what cloud and application servers bring to enterprise apps. It does the hard part. It brings decentralization. By building your apps on top of Web 5, you get decentralization and identity and data management as part of the platform.

This is definitely a fundamental change in how we exchange data, but it's not a total overhaul of the web we already know. This works like Progressive Web Apps, but you'd add the decentralized web node SDK and then applications are free to really go serverless because the data isn't stored with them.

The sky's the limit to what you can build on top of this platform, but here are some cool basic examples.

Music Applications

No one likes recreating their music playlists over and over again for different apps. With Web 5, you wouldn't have to do that.

In this example, Groove has access to write to Alice's decentralized web node and adds a new entry.

Tidal has access to read from Alice's DWN, so can read the new entry that was added by Groove, and now Alice has her playlist readily available on both apps.

With the continuous utilization of the data across apps, not only do Groove and Tidal get access to Alice's data, but they use it to improve her user experience, thus creating a stronger experience than Alice could have ever gotten had she not used this tech.

Travel Applications

Your travel preferences, tickets, and reservations are scattered across so many different hotels, airlines, rental car agencies and travel apps, making it really difficult to coordinate. Heaven forbid there's any hiccup in the system such as a delayed flight. You end up trying to get in touch with the car rental place to let them know you'll be late for your reservation, and if it's really late, you'd want to call the hotel to ask them not to give away your room. All while you're hustling and bustling at the airport.

Web 5 can help unify these various app experiences.

If Alice gives the hotel, the airline, and the rental car agency access to the Reservation and Trip objects in her DWN, they can react and adjust accordingly to any changes made.

These are just a few applications that can be realized by building on top of Web 5. There's so many more possibilities once the web is truly decentralized the way it was always intended to be.

California DMV Hackathon Win: Privacy-Preserving Age Verification

Angie Jones — Thu, 14 Nov 2024 19:07:33 +0000

At the recent California DMV Hackathon, the Block team, represented by members from Square and TBD, won the Best Privacy & Security Design award for building a prototype of an instant age verification system. This solution utilizes mobile drivers’ licenses (mDLs) to provide secure, privacy-centric transactions for age-restricted purchases with Square’s Point of Sale (POS) system.

In this post, we’ll explore the core technical components behind our solution, which centered on using TruAge technology to enable seamless, secure age verification.

How TruAge QR Code Verification Works

At the heart of our prototype is the ability to scan and verify a TruAge Age Token QR code. These QR codes contain a verifiable credential (VC) that confirms a person’s legal age without exposing unnecessary personal information. Here’s a breakdown of how we approached verifying these credentials in our solution.

Decoding the QR Code Payload

The first step in the verification process was reading the QR code provided by the customer. TruAge QR codes follow a standard format which encodes the verifiable presentation (VP) in a compact CBOR format.

Our team implemented a scanner using our open source web5-swift SDK that reads the QR code and decodes the CBOR-encoded payload. This CBOR format is efficient, allowing the verifiable presentation to be transmitted and processed quickly, minimizing any delays at the point of sale.
Converting CBOR to JSON

Once we decoded the CBOR data, the next step was to parse it into a JSON-based verifiable presentation using the W3C Verifiable Credentials (VC) Data Model v1.1. This model is critical to ensuring interoperability across different platforms and services, as it standardizes how credentials are represented and exchanged in a decentralized manner.
Validating the Issuer’s DID

After converting the data into a verifiable format, we needed to validate the digital signature on the credential. We retrieved the issuer’s Decentralized Identifier (DID) from the TruAge server, which provided us access to a sandbox environment containing their list of authorized DIDs.

Using DIDs, we were able to validate the cryptographic signature to ensure that the credential was issued by a trusted TruAge provider. This validation step is critical for ensuring that the credential has not been tampered with and is issued by a legitimate authority.
Credential Content Verification

Once the issuer’s signature was validated, the next step was to check the contents of the verifiable credential itself. In this case, we looked for proof that the individual was over 21 and verified that the credential had not expired.

This lightweight verification process ensures that businesses can quickly and easily confirm a customer’s legal age, while protecting their privacy by not exposing sensitive information like birthdates or addresses.

Building the Integration: Web5 and TruAge Libraries

To bring this solution to life, we used a few key technologies:

iOS: Our team developed the iOS implementation using the web5-swift library, which allowed us to efficiently handle the scanning, decoding, and parsing of the TruAge QR codes on Apple devices.
Android: For Android, we modified the TruAge library provided by Digital Bazaar to make it compatible with our solution. This involved adapting the library for seamless integration with our QR code parsing and validation logic.

Privacy and Security at the Forefront

Our approach ensures that personal information is protected at every stage of the transaction. By focusing solely on verifying the specific data point needed (in this case, whether someone is over 21), we avoid collecting or storing any unnecessary information. This is a win for both businesses and consumers, as it minimizes risk while maintaining a smooth user experience.

By integrating this technology into Square’s Retail POS system, we not only enhanced security but also brought innovative, privacy-preserving solutions to small businesses that need to comply with age verification laws. This prototype has the potential to extend to many other use cases, from secure employee onboarding to identity verification for suppliers and customers.

How Decentralized Apps Can Make Everyday Tasks Easy

Tania Chakraborty — Wed, 30 Oct 2024 13:15:00 +0000

Whenever I explore technology that's new to me, whether it be learning how decentralized apps work or what an open source tool does, it's seeing the technology in action that helps me understand whether or not it can impact me and my every day life. This is why every month at TBD, what better way to learn about our technology in action than from innovators using TBD's technologies today.

As our open source projects continue to develop, our community members contribute to the global effort of decentralizing the web with their independent projects. Here are the latest contributions from them.

Ariton

Developed by Sondre Bjellås (@sondreb), Ariton is a Web5 community SuperApp. It acts as a decentralized platform for building and managing communities! Ariton runs on any device with the ability to add any Mini Apps (or features) you want, like chat, groups, events, notes and more. Built on free and open standards, your identity and data is always in your full control. Currently in prototype stage, you can learn more and try it out here.

Kin AI

Kin AI is a personalized Web5 AI companion that offers guidance, coaching, and emotional support! Kin helps you piece together your problems and how to solve them in a way that seamlessly fits how you want it to. All your data stays on your device, and no one can access it without your specific permission. Live in beta, you can get early access on the App or Play store.

BlockCore Wallet

Also developed by Sondre (mentioned above), BlockCore Wallet is a non-custodial Web5 wallet in your browser that supports DIDs (decentralized identifiers), tokens, crypto currencies and more! You can add different accounts, send/receive payments, and even use an address book to quickly send multiple payments to one contact. You can learn more and try it out yourself in the BlockCore Wallet Guide.

Share Your Open Source Project

Amazing projects, right? Really helps visualize how decentralized apps can bring ownership and value to your everyday life in ways you may not have imagined.

Have a cool open source project that incorporates TBD's decentralized technologies? We'd love to hear about it! Head over and share your work with us in Discord in our #share-what-you-do channel for a chance to have your project featured on our dev site.

Why Broken Links Are Costing You Brand Deals (And How to Fix It)

Ebony Louis — Tue, 29 Oct 2024 19:56:45 +0000

Have you ever watched a creator’s video and thought, "Where did she get that top?" or "I need that protein powder"? You scroll through the comments, only to see the infamous "link in my bio" comment. You rush to click the link, and you're hit with-page not found 😒. I remember once being so desperate that I took a screenshot of the item and reverse-searched it on Google Images. I found something similar but not what I wanted. SO frustrating. Eventually, I gave up and kept on scrolling.

Now, imagine how many potential sales that creator lost because a third-party platform’s server was down. Their metrics won't even reflect those missed opportunities, making it harder to secure brand deals. Who actually has time for that? That’s when I realized I could use Decentralized Identifiers (DIDs) to create my own decentralized link hub utilizing service endpoints. With this setup, all my links and contact info are stored in one place—owned and controlled by me. Even if a service that houses all my links goes down, my links will always be accessible because they’re not reliant on any external platforms to display them. I’m sharing this in hopes that fellow creators won’t miss out on potential brand deals, and I won't have to cry over a top I never got to buy.

Before I show you exactly how you can create your own decentralized link hub, lets answer some of the questions you're probably asking yourself.

What are Decentralized Identifiers (DIDs)?

So, what exactly is a Decentralized Identifier, or DID? Think of it as your username—the one source of truth for everything you do online—except this one is owned and controlled entirely by you. It’s a unique "address", thats verifiable and doesn’t rely on any central authority like Facebook, Google, or any other service. Instead, DIDs give you the freedom to manage your own identity online, without needing to trust a single platform to store or validate your information.

In the context of a decentralized link hub, your DID becomes the hub for all your important links. It’s not tied to any third-party service, which means you never have to worry about followers scrolling simply because your link page isn't working. When you update your links, you only need to do it once, as they're tied to your DID—so they stay consistent across all your social platforms, giving you full control. When you update your links, they stay up-to-date across the web because again they’re tied to your DID—giving you full control.

How are Service Endpoints going to help me?

Now, let’s cover what service endpoints are. These might sound technical, but they’re actually pretty simple—think of them like your digital address/phone book. Remember those huge yellow books you used to sit on at the hair salon? They were filled with phone numbers and addresses, making it easy to find and contact people. Well, service endpoints are kind of like that, except they’re the digital "addresses" for different parts of your online identity. These could be links to your Instagram profile, website, direct messages, or even your affiliate links.

These endpoints live in your DID document. So instead of relying on centralized services like Linktree, your DID acts as the home for all your important links. So when someone resolves your DID, they can access the service endpoints that you’ve decided to share.

You can also easily update and delete these links anytime you need to again without relying on any third-party platform to keep those connections working.

The fix: let's create a decentralized Link Hub

If you’re more of a visual learner, check out my YouTube short where I show you exactly how. For this example we're going to create a DID with two service endpoints. One pointing to my LinkedIn and the other pointing to my X profile.

Step 1: Import web5/dids package

import {DidDht} from '@web5/dids'

Step 2: Create DID with service endpoints

const myBearerDid = await DidDht.create({
    options:{
        publish: true,
        services: [
            {
                id: 'LinkedIn',
                type: 'professional',
                serviceEndpoint: 'https://www.linkedin.com/in/ebonylouis'
            },
            {
                id: 'X',
                type: 'personal',
                serviceEndpoint: 'https://x.com/EbonyJLouis'
            }
        ]
    }
});

Now that we've created your DID with service endpoints leading to your LinkedIn and X profiles.

Step 3: Lets print our entire DID also know as a BearerDid to see our DID document where these service endpoints can be found:

console.log(myBearerDid)

It is important to never share your full BearerDID, it contains private keys that only you should have access to. The holder of these keys can perform private key operations, like signing data. Check out this Key Management Guide to learn how to properly manage your DID keys.

Output:

my bearerDid BearerDid {
  uri: 'did:dht:auontpd44i6rrzrmwry7hsbq8p5seqo7xyz8tnr7fdygsmhykoey',
  document: {
    id: 'did:dht:auontpd44i6rrzrmwry7hsbq8p5seqo7xyz8tnr7fdygsmhykoey',
    verificationMethod: [ [Object] ],
    authentication: [
      'did:dht:auontpd44i6rrzrmwry7hsbq8p5seqo7xyz8tnr7fdygsmhykoey#0'
    ],
    assertionMethod: [
      'did:dht:auontpd44i6rrzrmwry7hsbq8p5seqo7xyz8tnr7fdygsmhykoey#0'
    ],
    capabilityDelegation: [
      'did:dht:auontpd44i6rrzrmwry7hsbq8p5seqo7xyz8tnr7fdygsmhykoey#0'
    ],
    capabilityInvocation: [
      'did:dht:auontpd44i6rrzrmwry7hsbq8p5seqo7xyz8tnr7fdygsmhykoey#0'
    ],
    service: [ [Object], [Object] ]
  },
  metadata: { published: true, versionId: '1729705713' },
  keyManager: LocalKeyManager {
    _algorithmInstances: Map(1) {
      [class EdDsaAlgorithm extends CryptoAlgorithm] => EdDsaAlgorithm {}
    },
    _keyStore: MemoryStore { store: [Map] }
  }
}

This output contains your DID string(uri) thats your "username" along with the services array and some authentication and verification methods. To learn more refer to this DID Document Guide.

Step 4: Now lets look closely at just our serviceEndpoint array:

console.log("personal link hub", myBearerDid.document.service || "No Services Found");

Output:

decentralized link hub [
  {
    id: 'did:dht:xihb478dd7w9cyj33b6g5cjriuw6drwaxrx9ppf3bwn839pmhi6y#LinkedIn',
    type: 'professional',
    serviceEndpoint: 'https://www.linkedin.com/in/ebonylouis'
  },
  {
    id: 'did:dht:xihb478dd7w9cyj33b6g5cjriuw6drwaxrx9ppf3bwn839pmhi6y#X',
    type: 'personal',
    serviceEndpoint: 'https://x.com/EbonyJLouis'
  }
]

How do I share these links?

Now that your DID is in your bio, how do your followers access your links? It's simple- they just need to resolve your DID to see a full list of your shared links:

The resolving of your DID will differ depending on the DID method used to create the DID. In this example we are using the DHT DID method:

// DID in your bio
const didDhtUri = 'did:dht:xihb478dd7w9cyj33b6g5cjriuw6drwaxrx9ppf3bwn839pmhi6y'

// resolve the DID
const resolvedDhtDid = await DidDht.resolve(didDhtUri);

// access the DID Document's service links
const dhtDidDocument = resolvedDhtDid.didDocument.service;

console.log(dhtDidDocument)

Output:

[
  {
    id: 'did:dht:xihb478dd7w9cyj33b6g5cjriuw6drwaxrx9ppf3bwn839pmhi6y#LinkedIn#LinkedIn',
    type: 'professional',
    serviceEndpoint: [ 'https://www.linkedin.com/in/ebonylouis' ]
  },
  {
    id: 'did:dht:xihb478dd7w9cyj33b6g5cjriuw6drwaxrx9ppf3bwn839pmhi6y#LinkedIn#X',
    type: 'personal',
    serviceEndpoint: [ 'https://x.com/EbonyJLouis' ]
  }
]

As you can see, we’ve succesfully set up our service endpoints to point to both my LinkedIn and X accounts. Now it’s your turn to secure the bag, create your own decentralized Link hub! And if you tweet about it, don’t forget to tag me.

To learn more about Decentralized Identity check out TBD's Docs.

How Verifiable Credentials Can Help Combat Fake Online Reviews

Angie Jones — Tue, 22 Oct 2024 20:30:08 +0000

The Federal Trade Commission’s (FTC) has introduced a new rule banning fake online reviews. This rule, which penalizes businesses and individuals involved in the sale or purchase of fake reviews, represents a much needed step in promoting trust online. But while enforcement is crucial, there's still a challenge of identifying which reviews are legitimate. This is where Verifiable Credentials (VCs) can provide a solution.

The Problem with Fake Reviews

Fake reviews have been an issue for years, distorting consumer choices. As FTC Chair Lina Khan pointed out, these reviews “pollute the marketplace and divert business away from honest competitors.”

Let's face it, with pretty much every social networking site turning into an online shopping mall, many purchasing decisions are influenced by online reviews. I, personally, do most of my shopping online and I rely very heavily on reviews. I often question which ones are actually real, and if I'm not sure, I often shy away from making the purchase at all - which isn't good for me or the business.

The new FTC rule aims to crack down on this problem by prohibiting reviews from people who don’t exist, those who have no real experience with the product, or those misrepresenting their experience. It also bans businesses from creating or selling fake reviews. While these measures are great, enforcing them effectively presents challenges, especially with AI-generated content.

How Can Verifiable Credentials Help

Verifiable Credentials are digital certificates that prove specific facts about an individual or entity. These credentials are cryptographically signed, making them tamper-proof, and they can be independently verified without relying on a central authority. In the context of online reviews, VCs can establish authenticity.

Here’s how it could work:

When a customer purchases a product or uses a service, the business can issue a VC to confirm their legitimate experience. This can even be attached to their receipt. This credential could serve as proof that the individual has transacted with the business, preventing fake reviews from people with no real experience.

A review platform could require users to attach a VC that verifies they have purchased or used the product before submitting a review. This would eliminate fake reviews from non-customers and ensure that only those with firsthand experience can provide feedback.

Since VCs are cryptographically signed, they cannot be altered or faked. This ensures the integrity of the review content and prevents businesses from modifying or fabricating reviews to boost their reputations.

Benefits for Businesses and Consumers

Consumers would no longer have to second guess the authenticity of reviews. They can trust that every review is tied to a verified, real customer.
By adopting VCs, businesses can ensure they remain compliant with the new FTC rule. They would have a verifiable record that shows they only accept reviews from legitimate customers, protecting themselves from potential penalties.
Early adopters of VCs in their review systems could set themselves apart from competitors. Businesses that champion transparency and fairness by using VCs can build stronger relationships with their customers, enhancing brand loyalty.
Using VCs can automate the verification process, reducing the need for manual review moderation. As AI continues to be used in generating content, including reviews, this automation is key to keeping platforms efficient while maintaining high standards of trust.

Trust But Verify

The FTC’s new rule is a step in the right direction, but to truly tackle the problem of fake reviews, the marketplace needs more than just enforcement. It needs technology that ensures transparency and trust. Verifiable Credentials can provide that assurance, giving businesses and consumers the tools they need to foster a fair, competitive, and honest marketplace. As online commerce continues to grow, adopting VCs could be the key to making reviews a trustworthy resource once again.

If you'd like to get started with Verifiable Credentials, check out our free, open source SDKs!

Known Customer Credential Hackathon

Angie Jones — Fri, 11 Oct 2024 17:34:05 +0000

tbDEX is an open messaging protocol that enables liquidity seekers to connect with liquidity providers. This means that as a liquidity provider, your business can be the backend supplier in several payment applications.

Performing KYC on repeat customers every time they attempt to transact with you from a different payment app would be a pain. To avoid this, you will use the Web5 SDK to issue a Known Customer Credential (KCC) to a customer, Alice, who you have already completed KYC on. You will store the JWT representing the KCC in Alice’s Decentralized Web Node so that she can present it to your business from any payment app.

Challenge

Create a Decentralized Identifier (DID) and DWN to use as the Issuer.
- Bonus: Use the DIF community DWN instance hosted by Google Cloud.
Issue Alice a KCC that includes evidence. Note that for this challenge, you do not need to implement an actual identity verification flow.
Install the VC Protocol onto your DWN so that you can communicate with Alice’s DWN.
Obtain permission to write to Alice’s DWN by sending a GET request to:

  https://vc-to-dwn.tbddev.org/authorize?issuerDid=${issuerDidUri}

Store the VC JWT of the KCC as a private record in Alice’s DWN.

Submit

To enter a submission for this hackathon, provide the DWN Record ID of the KCC.

Resources

Alice’s DID: did:dht:rr1w5z9hdjtt76e6zmqmyyxc5cfnwjype6prz45m6z1qsbm8yjao
web5/credentials SDK
web5/api SDK
How to create a DID and DWN with Web5.connect()
Obtain Bearer DID - required to sign KCC
Known Customer Credential Schema
How to issue a VC with Web5
Example of issuing a KCC with Web5
Example of issued KCC
How to install a DWN Protocol
How to store a VC in a DWN

Contact Us

If you have any questions or need any help, please reach out to us in our #kcc-hackathon channel on Discord.

TBD x Hacktoberfest

Tania Chakraborty — Tue, 08 Oct 2024 20:50:39 +0000

With October blazing through, we're greeted by pumpkin spices, the aroma of fall leaves drifting in the rain, and of course, the much-anticipated Hacktoberfest. Whether you're a seasoned contributor or new to open source, there's something for everyone.

🎉 We're Participating in Hacktoberfest 2024!

We have several projects with a variety of issues that we'd love your contributions for! For each issue that's merged, you'll earn points towards the TBD Hacktoberfest Leaderboard. Winners will receive exclusive TBD Hacktoberfest 2024 swag!

We're kicking off Hacktoberfest with more events:

October 10: Twitter Space - Hacktoberfest Rust Projects
October 10: Exploring an AI-Powered GitHub Action

Be sure to add them to your calendar.

📌 What is Hacktoberfest?

Hacktoberfest is a month-long (October) celebration of open source software. It's sponsored by DigitalOcean, GitHub, and other partners. Check out Hacktoberfest's official site for more details and to register. Registration is from September 23 - October 31.

📂 Dive into TBD's Participating Projects

We included a wide variety of projects and issues for Hacktoberfest 2024. Each of our participating repos has a Hacktoberfest Project Hub, which contains all issues you can pick up with the hacktoberfest label. For easy reference, repos with multiple projects will have multiple project hubs.

Explore our participating repos below and see where you can make an impact:

developer.tbd.website
- Languages: MDX, JavaScript, CSS, Markdown
- Project Description: Docusaurus instance powering the TBD Developer Website (this site).
- Links: Hacktoberfest Project Hub | Contributing Guide
web5-js
- Language: TypeScript
- Description: The monorepo for the Web5 JS TypeScript implementation. It features libraries for building applications with decentralized identifiers (DIDs), verifiable credentials (VCs), and presentation exchange (PEX).
- Links: Hacktoberfest Project Hub: Protocol Explorer | Hacktoberfest Project Hub: General | Contributing Guide
web5-rs
- Language: Rust
- Description: This monorepo houses the core components of the Web5 platform containing the core Rust code with Kotlin bindings. It features libraries for building applications with decentralized identifiers (DIDs), verifiable credentials (VCs), and presentation exchange (PEX).
- Links: Hacktoberfest Project Hub | Contributing Guide
dwn-sdk-js
- Language: TypeScript
- Description: Decentralized Web Node (DWN) Reference implementation.
- Links: Hacktoberfest Project Hub | Contributing Guide
DWA Starter
- Language: JavaScript
- Description: Decentralized Web App (DWA) starter collection.
- Links: Hacktoberfest Project Hub: VanillaJS | Hacktoberfest Project Hub: Vue | Contributing Guide
DIDPay
- Languages: Dart
- Description: Mobile app that provides a way for individuals to interact with PFIs via tbDEX.
- Links: Hacktoberfest Project Hub | Contributing Guide
DID DHT
- Language: Go
- Description: The did:dht method and server implementation.
- Links: Hacktoberfest Project Hub | Contributing Guide
DCX
- Languages: TypeScript, JavaScript
- Description: A Web5 Protocol for Decentralized Credential Exchange.
- Links: Hacktoberfest Project Hub | Contributing Guide
Goose Plugins
- Language: Python
- Description: Plugins for Goose, an AI developer agent that operates from your command line.
- Links: Hacktoberfest Project Hub | Contributing Guide
Fllw, Aliased
- Languages: TypeScript, JavaScript
- Description: A reference app for building Decentralized Web Apps.
- Links: Hacktoberfest Task: Fllw | Hacktoberfest Task: Aliased

Hot Tip
Not a coder? No worries! developer.tbd.website has tons of non-code related issues up for grabs.

📝 Guide to TBD x Hacktoberfest 2024

✅ Topic Check: Contribute to projects that have the hacktoberfest label. This ensures your PR counts towards the official Hacktoberfest prizes.
🏷️ Label Insights:

Start with an issue labeled hacktoberfest and comment ".take" to assign yourself the issue.
After submitting a PR and having it approved, the PR will be labeled hacktoberfest-accepted and you'll receive points on our leaderboard and credit towards the global Hacktoberfest 🎉
If your PR is marked with a spam or invalid label, re-evaluate your contribution to make it count.

🥇 Code and Conduct: Adhere to our code of conduct and ensure your PR aligns with the repository's goals.
🫶 Community Support: Engage with fellow contributors on our Discord for tips for success from participants!
🆘 Seek Help: If in doubt, don't stress! Connect with the maintainers by commenting on the issue or chat with them directly in the #🎃┃hacktoberfest channel on Discord.

🎁 Leaderboard, Prizes and Excitement

Be among the top 10 with the most points to snag custom swag with this year's exclusive TBD x Hacktoberfest 2024 design! To earn your place in the leaderboard, we have created a points system that is explained below. As you have issues merged, you will automatically be granted points.

💯 Point System

Weight	Points Awarded	Description
🐭 Small	5 points	For smaller issues that take limited time to complete and/or don't require any product knowledge.
🐰 Medium	10 points	For average issues that take additional time to complete and/or require some product knowledge.
🐂 Large	15 points	For meaty issues that take a significant amount of time to complete and/or possibly require deep product knowledge.

🏆 Prizes

The top 10 contributors with the most points will be awarded TBD x Hacktoberfest 2024 swag from our TBD shop.
The top 3 contributors in our top 10 will be awarded very limited customized TBD x Hacktoberfest 2024 swag with your github username on it. Stay tuned to our Discord for the reveal!

Keep an eye on your progress via our Leaderboard.

🎙️ Livestreams & Office Hours

Dive into our jam-packed Hacktoberfest schedule! Whether you're just here for fun or are focused on learning everything you can, we've got you covered:

Every Tuesday, Community Office Hours - Join us every Tuesday at 1pm ET for the month of October, where we will go over PR reviews, live Q&A, and more. This event occurs on Discord.
Twitter Space: Hacktoberfest Rust Projects - Join Staff Developer Advocate @blackgirlbytes & Software Engineer @kendallweihe this Thursday at 12pm ET, where you can learn about our core Rust SDK with Kotlin bindings and contributions we're seeking for this project. This event will be live on our Twitter.
Exploring an AI-powered GitHub Action - Join Head of Engineering Michael Neale & Staff Developer Advocate @blackgirlbytes this Thursday at 5pm ET, to learn more about an AI-powered action made by Goose, an AI developer agent that operates from your command line.

Live Events Calendar - Keep tabs on our Discord or developer.tbd.website for our future events & sneak peeks - we're always cooking up something new!

📚 Resources for First-Time Contributors

📖 How to Contribute on GitHub
🛠 Git Cheatsheet
🔍 Projects Participating in Hacktoberfest

Happy hacking and cheers to Hacktoberfest 2024! 🎉

How Web5 and Bluesky are Building the Next Layer of the Web - A Comparative Analysis

Rizèl Scarlett — Tue, 27 Aug 2024 15:54:12 +0000

As companies increasingly commodify our personal data and privacy breaches make headlines, many technologists are creating user-centered frameworks that empower individuals to control their digital identities and personal information. This concept, known as Self-Sovereign Identity (SSI), enables users to decide what data they share and with whom. While blockchain technology is a popular choice for implementing SSI, companies like TBD are exploring (and even creating) alternative technologies to achieve these goals.

My Perspective on the State of SSI

Our efforts at TBD are part of a larger movement. In fact, there’s a consortium of tech giants and startups working together through the Decentralized Identity Foundation to establish open standards and best practices for SSI, focusing on:

Digital Identity
Interoperability
Data Ownership
Reliable digital verification methods

The SSI industry is making tangible progress, especially in government sectors, as our technological solutions support the advent of Mobile Driver's Licenses.

However, one of my concerns with our industry is every company is implementing varied proprietary methods. Despite aiming to solve similar problems, companies are developing their own unique DID methods, wallets, and tooling. This fragmentation raises questions for me:

Can we achieve widespread adoption with disparate systems?
Will the multitude of competing mechanisms overwhelm both users and developers?
Will our various systems eventually work in tandem?

In November 2023, I began investigating the answers to these questions through a livestream series where I interviewed SSI experts from different companies. After conducting approximately 30 interviews, these questions remain unanswered. However, I’ve gained more in-depth knowledge about:

Key players in the SSI space
Various technical approaches to implementing SSI
Real-world applications of SSI

Interviewing Bluesky

I most recently interviewed Dan Abramov, creator of Redux and React core team member, about his work at Bluesky and the development of Bluesky's underlying technology – Authenticated Transfer Protocol, or AT Proto for short. I learned that while TBD’s Web5 and Bluesky’s AT Proto share the vision of a decentralized and user-centric web, their approaches and underlying technologies offer a fascinating contrast. I'll examine these parallel approaches in hopes that TBD, Bluesky, and the broader community can gain valuable insights into building infrastructure for the decentralized web.

Building the Next Layer of the Web

Similarities

The web as we know it today consists of physical, network, transport, application, and data layers. Instead of replacing the existing architecture altogether, AT Proto and Web5 aim to add a new layer enabling data to exist beyond individual applications. Both provide tools for developers to build apps within their respective ecosystems.

Bluesky actually serves as a reference implementation to inspire developers and showcase AT Proto's potential.

Differences

AT Proto focuses on decentralized social media, while Web5 enables developers to build any type of application, from financial tools to social media to health management. For example, I developed a fertility tracking app during a hackathon to demonstrate personal health data ownership. Additionally, at TBD, we use components of the Web5 SDK to build the tbDEX SDK, an open financial protocol that can move value anywhere around the world more efficiently and cost-effectively than traditional financial systems.

Data Portability

Similarities

A common frustration with traditional web applications is that users often lose access to their data when a platform shuts down. Even if a user can export their data—say as a CSV file—it becomes static, no longer live or interactive.This data is essentially lost for most users, especially non-technical ones, as it's difficult to rebuild the ecosystem that once surrounded it. For example, moving from one social media app to another means users lose their followers, viral posts, and reputation and have to start from scratch.

Web5 and AT Proto enable users to take their data from one application to another. For example, if a user leaves Bluesky, which operates on AT Proto, they can migrate their data to another AT Proto-compatible app without losing their social connections or posts. Similarly, if an app built with Web5 were to shut down, a user could bring their data to another Web5 app.

Differences

Data portability on these platforms varies due to different data management approaches. AT Proto uses a federated model where each app operates a Personal Data Server (PDS). The PDS, typically managed by the app provider, stores all user data in a repository tied to the user’s identity. Users can move their repository—containing posts, social graphs, and more—between apps within the AT Proto ecosystem by connecting it to another PDS.

In contrast, Web5 depends on Decentralized Web Nodes (DWNs), which are personal data stores fully controlled by the user. To switch apps, users point the new application to their DWN and specify the types of data users of the app can access.

Use of W3C Standards for Authentication

Similarities

Both AT Proto and Web5 leverage the W3C standard called Decentralized Identifiers (DIDs), which are globally unique alphanumeric identifiers that can move with you across different applications. This enables users to maintain their identities consistently across platforms.

While DIDs are often associated with blockchain technology, both Web5 and AT Proto implement a blockchain-less approach. For instance, Bluesky uses a custom DID method called did:plc (DID Placeholder), while Web5 employs did:dht (DID Distributed Hash Table), which anchors DIDs on BitTorrent instead of a blockchain. Learn more about TBD’s DID method here.

Differences

Many developers have told me that the way AT Proto handles authentication is what attracted them to the Bluesky, but many of them don’t even realize that they’re using DIDs under the hood. On Bluesky, users can use one of their existing domain names as their username. Bluesky verifies ownership by performing a DNS lookup to make sure the domain belongs to the user. Once verified, the domain is linked to a DID, and the user is marked as verified on their account.

Web5 also uses DIDs for authentication but in a different way. DIDs eliminate the need for usernames and passwords. Instead, you can log in directly with your DID. This is possible because, in the Web5 ecosystem, every DID has cryptographic keys that securely prove ownership.

Permission Management

Similarities

Both AT Proto and Web5 offer permission management systems, but there are key differences in who can manage these permissions.

Differences

AT Proto takes an application-centric approach to permission management. Permissions are defined by applications using schemas called lexicons, which dictate the rules that the PDS follows. As a result, the extent of control users have over their data depends on the permissions set by the application.

Permission management is where Web5 shines. Users define access controls through JSON schemas called Protocols, specifying who can access specific data stored in their DWN. This is why building a fertility tracking app with Web5 was ideal for me: I could explicitly deny social media apps, marketing platforms, and retailers access to my personal health data, while allowing only my healthcare provider and partner to access it.

Special URLs for Data Access

Similarities

Most web users are familiar with URLs, which serve as web addresses to retrieve data online. Similarly, AT Proto and Web5 use their specialized URLs to access data within their ecosystems.

Differences

In AT Proto, special URLs start with the prefix at:// and point to data in a user's PDS.

Example: at://alice.com/app.bsky.feed.post/1234 might reference a specific post in a user's social media feed.

In Web5, Decentralized Resource Locators (DRLs) start with the prefix https://dweb and link to data stored in a DWN.

Example: https://dweb/${did}/read/records/${recordId} allows a user to fetch a specific record from a DWN.

Learn More

While I've described some core differences between Web5 and AT Proto, there are more interesting features to explore, including how Bluesky implements algorithmic choice, how Web5 uses W3C's Verifiable Credentials to prove digital identity, and how both platforms refer to individual data pieces as "records." These topics deserve their own deep dives. For now, I encourage you to continue exploring via:

🎥 Watch: My interview with Dan Abramov explaining Bluesky’s implementation

📚 Learn: Check out my SSI expert interview series called tbdTV

🤝 Join: Build with us and join our discussions on Discord.

Simplifying Cross-Platform Payments with DAPs

Rizèl Scarlett — Wed, 31 Jul 2024 16:47:53 +0000

"Dap me up!" is a colloquial term followed by a gesture used in Western cultures to greet people or express solidarity. At TBD, we're adding a new meaning to this phrase with Decentralized Agnostic Paytags (DAPs), an open source approach designed to simplify peer-to-peer payments across various applications.

Solving an Awkward Issue

Peer-to-peer (P2P) payment applications have existed since the late '90s, starting with tools like PayPal. With the rise of smartphones, innovative mobile apps like Venmo, Zelle, and Block's very own Cash App have made it easier to exchange funds directly from our phones.

However, a persistent issue remains: the sender and recipient must use the same app to complete a transaction. People have personal and valid reasons for choosing their preferred payment apps.

This situation creates an uncomfortable, unspoken battle when you need to pay a friend after dinner or a contractor for a service, only to discover that you use CashApp while they use Venmo. Now, you both face the dilemma of deciding who will download a new app, set up a new account, and link it to their bank account.

Instead, P2P payment apps can use DAPs—agnostic unique identifiers stored in a registry—to identify and route payments to the correct destination across different platforms. This allows you and the recipient to financially "dap each other up" regardless of which apps you prefer.

Introducing Decentralized Agnostic Paytags (DAPs)

A DAP is a user-friendly handle for payments, structured as @local-handle/domain.

Here's an example: I love the handle blackgirlbytes. If I registered that handle on Cash App's DAP registry, my DAP would be @blackgirlbytes/cash.app. Similarly, if I registered that handle on DIDPay's DAP registry, my handle would be @blackgirlbytes/didpay.me.

Each DAP links to a Decentralized Identifier (DID) to help identify who you are, regardless of the platform. While your DID includes cryptographic keys for identity protection, it also contains your money address—a unique identifier that directs different payment systems where to send your funds.

Get Started with DAPs

The DAP ecosystem has two key actors: the payment platform that offers DAPs and the users who own the DAPs.

For Organizations: Any organization can enable users to create a DAP on their platform by setting up a DAP registry associated with their domain. This registry serves two main functions:

It allows users to sign up for DAPs.
It maps users' DAPs with their DID and money address.

For Users: Once a DAP registry is available on your preferred platform, you can sign up for a DAP using your chosen handle.

If you're eager to experiment with DAPs but your preferred payment platform hasn't implemented a DAPs registry yet, you can obtain a DAP via our static DAP registry.

Keep Up to Date

DAPs debuted during a company-wide Hackathon at Block, where TBD, Cash App, and Square teams collaborated to bring this vision to life. As the DAP implementation continues to evolve, here are a few ways you can stay involved:

Join the TBD Discord
Read the DAP specification
Contribute to the open source SDKs:
- dap-js
- dap-go
- dap-kt
- dap-dart
Create a DAP in our static DAP registry

Watch the video below to learn more

7 Unexpected Ways Verifiable Credentials are Used Today

Rizèl Scarlett — Wed, 24 Jul 2024 20:57:43 +0000

"Verifiable Credentials seem niche. Only a small group of technologists would be interested in this," a conference attendee declared after I enthusiastically described my company's work in the Global Payments and Self-Sovereign Identity (SSI) ecosystem.

This comment gave me pause. Less than a year ago, I first encountered Verifiable Credentials (VCs) - a W3C standard for digital credentials that state specific facts about individuals, organizations, or entities. My initial reaction was similar to the conference attendee’s response. However, after interviewing SSI builders on a weekly livestream, my perspective changed dramatically.

While VCs are relatively new and primarily explored by SSI enthusiasts, their benefits extend far beyond this group. Many of the services and products you use today already rely on them – even if you don't realize it.

From healthcare to content creation, finance to travel, VCs are changing how we share and verify information. Here's a look at seven real-world applications of VCs that may surprise you:

Mobile Driver’s Licenses
The Pharmaceutical Supply Chain
Content Creation and Generative AI
Music Copyright
Loan Applications
Online Marketplaces and Catfishing
Native Tribes
Learn More

1. Mobile Driver’s Licenses

If you often misplace your wallet like me, there's good news — your state may support the use of Mobile Driver's Licenses (mDLs). Louisiana was the first state to implement mDLs in 2018. Since then, mDLs have been gaining traction across the United States. With mDLs, residents of participating states can store a digital version of their driver's license on their smartphones. This allows users to leave their physical ID at home and use their phones for identification in various situations, including travel, age-restricted services, voting, and law enforcement interactions.

VCs are the technology behind mDLs because they offer features like revocation, authentication, expiration, and tamper evidence. If you use an mDL, you're using VCs!

Source: https://lawallet.com/

2. The Pharmaceutical Supply Chain

Dr. Carsten Stöcker, CEO of Spherity, introduced me to a fascinating application of VCs in the pharmaceutical industry. Pharmacies often trade medicines with each other to maintain their stock, but this exchange requires complex verification processes. They must verify the legitimacy of three key elements:

the medicine,
the organization they're trading with,
the provider making the trade

Caro.vc, a Spherity company, employs VCs to simplify this process and reduce errors. Their solution allows pharmacies to quickly and securely verify all these elements, ensuring the integrity of the pharmaceutical supply chain.

To learn more about this use case, check out this discussion between Dr. Carsten Stocker and the Developer Relations Team at TBD:

3. Content Creation and Generative AI

Content creation has played a considerable role in our online lives for the past few years. For some, it has become a career, launching individuals into fame. However, whether you're an artist, seamstress, or photographer, people often steal and claim work that you made.

Additionally, a new form of content creation has hit the scene: generative AI. While many use it for productivity, others exploit it to spread misinformation or generate false images and videos in the likeness of others.

Organizations like Adobe, BBC, Microsoft, Sony, and Nikon formed the Content Authenticity Initiative and the Coalition for Content Provenance and Authenticity to address these issues. These groups developed Content Credentials, which use VCs to tackle the challenges of content theft and misuse of AI-generated content, aiming to protect creators’ rights.

Source: https://contentauthenticity.org/blog/community-story-wrapt

Click this link to read the case study, view the above image, view the above image, and view the image's content credentials.

4. Music Copyright

Musical artists typically don't own their masters, meaning they lack full control over their recordings when signing a record deal. Today, more musical artists are opting to own their masters to regain control over the distribution of their work. Cole Davis describes the publishing and distribution of music as a "music supply chain" and observed a disjointed process involving agreements through text messages, scattered emails between lawyers, and inconsistent procedures.

To address these issues, Davis built Switchcord, using VCs to provide cryptographic proof of who was involved in creating a song, when it happened, and what contracts were signed. This ensures all participants receive proper credit and compensation, preventing false claims.

To learn more about this use case, check out this discussion between Cole Davis and the Developer Relations Team at TBD:

5. Loan Applications

The U.S. credit system requires residents to accumulate debt as a prerequisite for obtaining loans, leading to more debt. Recent data from the Federal Reserve Bank of New York underscores this systemic issue, revealing that 1 in 5 applicants for mortgages, car loans, or other loans were rejected — the highest rate in five years.

FormFree is addressing this problem using the Web5 SDK to provide VCs for loan borrowers through their Passport product. Their approach involves creating an anonymized, tamper-proof credit profile as a VCs for lenders to review and make offers, aiming to put power back in the hands of the borrower.

To learn more about this use case, check out this discussion between the FormFree team and the Developer Relations Team at TBD:

6. Online Marketplaces and Catfishing

Unfortunately, online marketplace scams are common. From purchasing a car to renting a home or adopting a pet, you can buy and sell almost anything online. However, there's no foolproof mechanism to ensure the seller is trustworthy.

With the rise of social media, catfishing — where a person pretends to be someone they're not while online dating — has also increased dramatically. While many believe they're not susceptible, 23% of online dating participants reported being catfished, and 41% of catfish victims are between the ages of 18 and 34.

Jeffrey Schwartz created Dentity to reduce the frequency of scams and catfishing incidents. Dentity uses VCs to verify individuals on any platform, from dating apps to online marketplaces.

To learn more about this use case, check out this discussion between Jeffrey and the Developer Relations Team at TBD:

7. Native Tribes

Special Economic Zones (SEZs) are designated areas within a country that operate under different business and trade laws than the rest of the nation. These zones typically offer incentives like tax breaks and simplified regulations. The Catawba Indian Nation established their own SEZ called the Catawba Digital Economic Zone, with the goal of driving economic development, attracting businesses, and creating opportunities for tribal members.

The Catawba Digital Economic Zone is using the Web5 SDK to grant VCs to members. These VCs allow users to prove their identity and achieve regulatory compliance within the zone.

To learn more about this use case, check out this discussion between the Catawba Digital Economic Zone Team and the Developer Relations Team at TBD:

Learn More

Verifiable Credentials are making a tangible difference by solving real problems for real people - simplifying loan applications, protecting artists' rights, ensuring pharmaceutical safety, and supporting tribal sovereignty.

If you have ideas for building apps with VCs, check out these resources:

Hundreds of developers across Africa learn to speak tbDEX

Adewale Abati — Mon, 01 Jul 2024 10:28:00 +0000

Following the successful launch of tbDEX 1.0 in Rio de Janeiro, TBD embarked on a roadshow across Africa, visiting Accra, Nairobi, and Cape Town.
Our mission was to engage with local developers and share tbDEX, an open source protocol for global payments.

Recognizing that many African countries face significant barriers to participating in the global economy, we aimed to support the vibrant and growing developer communities in these regions.
These communities are already tackling these challenges head-on, and we wanted to contribute by providing open source tools to build robust payment applications.

The roadshow featured full-day, hands-on workshops in Accra and Nairobi, where hundreds of developers gathered to learn how to utilize tbDEX.
The excitement was palpable as participants built wallet applications using the tbDEX SDK.
The enthusiasm and curiosity among the developers were evident, and the success of these workshops was widely shared across LinkedIn and Twitter.

// Detect dark theme var iframe = document.getElementById('tweet-1794038435218387164-439'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1794038435218387164&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1794018057012072690-593'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1794018057012072690&theme=dark" }

Angie Jones, Head of Developer Relations, and Adewale Abati, Staff Developer Advocate, led the workshops, demonstrating the capabilities of developers eager to integrate advanced payment solutions.
Co-sponsored by Yellow Card and Circle, these sessions saw developers integrating wallet applications with tbDEX in just one day.

In addition to the workshops, TBD actively participated in notable conferences across Africa.
At the 3iAfrica conference in Accra, Mike Brock, CEO of TBD, delivered an insightful session titled "Trust Reimagined in the Digital Assets World," discussing the economic principles behind digital assets and their impact on trust and value exchange in business.
Angie Jones hosted a roundtable discussion on tbDEX as an open protocol for global money movement."

The team also made a stop at Joy 99.7 FM radio station in Ghana, where Mike and Angie discussed how digital identity can enhance payment systems.

The journey continued to the ID4Africa conference in Cape Town, where TBD engaged with local stakeholders to gain deeper insights into the challenges surrounding digital identity.

Overall, the roadshow was a significant step in connecting with developer communities across Africa.
We were inspired by the talent and determination we encountered and look forward to seeing the innovative solutions that will emerge from these collaborations.

Get Started with tbDEX

With tbDEX, anyone can dive into building innovative payment solutions without needing permission.
This open source tool empowers developers to start building immediately.
We welcome your feedback and contributions to make tbDEX even more robust and versatile.
Join us in breaking down barriers and building the future of global payments today.

9 Things You Didn't Know About Decentralized Identifiers

Rizèl Scarlett — Fri, 19 Apr 2024 12:46:51 +0000

Remember your first username? If you were anything like me in the early 2000s—too young to surf the web but excited about the possibilities of connecting with the rest of the world—your username probably makes you cringe today.

Self-expression is the main driver for my internet usage. Over the years, I've created various usernames representing different parts of me at distinct periods of my life. From Millsberry to Myspace, each new website meant a new profile, leading to a fragmented experience. The most annoying part is that there's no connection between my profiles or "identities", so I have to remember all my passwords or rely on a password manager. Unfortunately, password managers are susceptible to security breaches.

This fragmentation of identity on the web poses a significant challenge: How do we manage these scattered identities efficiently and securely?

Many organizations are working hard to answer this question. Some are going passwordless via passkeys. Others, like the Open Researcher and Contributor ID (ORCID), implemented digital identifiers to associate publications, research, and open source contributions with a particular researcher.

Companies focused on advancing identity tech and self-sovereign identity are embracing Decentralized Identifiers (DIDs) as a solution. DIDs are globally unique, alphanumeric, immutable strings representing who you are across the decentralized web.

Speaking of DIDs -- did you know that Decentralized Identifiers are one of the pillars of Web5?

In this post, we'll explore nine more things you may not have known about Decentralized Identifiers.

1. DIDs are a W3C Standard

In 1994, Tim Berners Lee, the creator of the World Wide Web, founded the World Wide Web Consortium (W3C). The W3C is made up of groups of people focused on setting the best practices and standards for building the web. For example, the W3C develops and maintains standards for HTML, CSS, Web Accessibility, and Web Security. In July 2022, The W3C officially published standards for Decentralized Identifiers. This way, technologists would have blueprint for building and managing digital identities as we make the shift towards controlling your own identity on the internet.

2. DIDs can represent more than just humans

While DIDs represent people across the web, they can also represent organizations such as manufacturers, businesses, or government agencies. Technologists are exploring using DIDs to represent IoT devices like smart hubs, smart thermostats, or autonomous cars, allowing you to maintain control over your data usage! Here's a taboo but realistic use case that might make you blush— DIDs can even represent sex tech devices! 😳

3. It's nearly impossible for someone to steal your DID

A common question people often ask me is, "Can someone steal my DID?" DIDs are alphanumeric strings, so they may give people the impression that DIDs are top-secret passwords or API keys. But that's not the case; you can share your DID with anyone without compromising your safety. It's nearly impossible for someone to steal your DID and pretend to be you because DIDs are all cryptographically signed.

What does 'cryptographically signed' mean?

Cryptographically signed means that each DID has a unique digital fingerprint generated by a fancy, complicated algorithm. Two keys—a public key and a private key—make up the digital fingerprint. Your public key shows other people that the DID legitimately belongs to you, but the private key needs to remain private. The private key is like your master key. Someone can only steal your DID, tamper with your DID, or impersonate you if they have access to your private key. Fortunately, it's not easy to access your private key because it is protected by encryption and multiple layers of security. Some DID methods even support key rotation meaning you can update your cryptographic keys to reduce the risk of compromise.

Store your DID in an authenticated digital wallet

In addition to all these security algorithms that protect your DID from being stolen, users typically store their DIDs in an authenticated digital wallet (similar to how your Apple Wallet or Google Wallet stores your debit card information). Storing your DID in a digital wallet provides an additional layer of security because you often have to use a form of authentication like Face ID or a passcode to access items stored in the wallet.

4. Your DID is more than a string

While your DID is a string, it's part of a larger JSON object called a DID document. In addition to the DID string, the DID document includes metadata like:

Cryptographic keys to prove ownership
Rules about how your DID can be used, managed, or modified

Below is an example of a DID document:

{

  "@context": [

    "https://www.w3.org/ns/did/v1",

    "https://w3id.org/security/suites/ed25519-2020/v1"

  ]

  "id": "did:example:123456789abcdefghi",

  "verificationMethod": [{

    "id": "did:example:123456789abcdefghi#key-1",

    "type": "Ed25519VerificationKey2020", 

    "controller": "did:example:123456789abcdefghi",

    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"

  }, ...],

  "authentication": [

    "#key-1"

  ]

}

Source: https://www.w3.org/TR/did-core/#example-an-example-of-a-relative-did-url

Learn more about DID documents here.

5. Every DID has a DID method

Let's examine the anatomy of a DID method.

Every DID:

Starts with the schema did:
Followed by a word or acronym representing the did method
Then, ends with a did method-specific identifier in the form of an alphanumeric string

A schema and a DID method together may look like did:web or did:jwk.

What are DID methods?

DID methods define the rules for creating, managing, and deactivating DIDs.

6. There are over 100 DID methods

Anyone can create a DID method. Companies, individuals, or communities may create a custom DID method to fit a specific use case or live on a specific type of ledger. However, to ensure the DID method is recognized, interoperable, and meets the correct standards, it's strongly recommended to include the DID method on the W3C DID Spec Registry.

7. TBD created its own DID method

We (TBD) created our own DID method called DID:DHT. DHT stands for Distributed Hash Table indicating the use of Mainline DHT. You can learn more about DID:DHT via the spec and this blog post written by TBD’s Director of Open Standards, Gabe Cohen.

At TBD, we colloquially call DID:DHT, DID THAT.

8. You don't have to use blockchain; we use BitTorrent

When I hear the words, "decentralized" or "immutable", I immediately think of blockchain and cryptocurrency. I don't think that train of thought is in the minority.

For instance, to ensure DIDs have no central authority and that individual users can own them, folks typically anchor DIDs on an immutable ledger.

What does anchoring a DID mean?

Anchoring a DID means recording DID transactions on a distributed ledger.

DID:DHT uses BitTorrent; not blockchain

At TBD, we actually took a blockchain-less approach. We anchored DID:DHT to BitTorrent. As mentioned above, DID:DHT uses a Mainline DHT, which is a distributed hash table used by the BitTorrent protocol.

9. You can create a DID with the Web5 SDK

You can use the Web5 SDK to create a DID!

`Web5.connect()`

You can generate a DID using the Web5.connect() method with the following steps:

Install the web5/api package

npm install @web5/api

Import the package

import { Web5 } from '@web5/api';

Call Web5.connect()

const { web5, did: myDid } = await Web5.connect();
console.log(myDid)

More ways to create a DID

Check out the documentation to learn more ways to create a DID in various languages including JavaScript, Kotlin, and Swift.

Learn more about Decentralized Identifiers

Have a question? Ask it in our Discord; we're happy to help!
Eager to start building? Follow the guides in our documentation.
Curious about the entire ecosystem? Watch our YouTube videos.