Decomposing the System

[ALRubinger]

We've designed a powerful system. It lets users talk to financial institutions (PFIs) and identity providers (VC issuers). Where we once would have had to draw direct, custom connections from the user to PFIs/VC issuers, now the paradigm is inverted. PFIs and VC issuers receive a common data format over a common protocol, and the user can talk to any compliant participant in the system.

It looks a little like this, with some handwaving to simplify the picture:

User > Wallet > User's Identity Hub > PFI Identity Hub > PFI Implementation > PFI's business systems

I sense we're all generally on board with this design. For PFIs and VC Issuers, it provides a clean interface connecting them to users. For users, it's a smooth experience for exchanging value and proving identity.

I'd like us to consider how we may pull this apart. Reasoning: let the system come together in smaller pieces without having to wait on the whole thing to be built end to end. None of this changes the importance of the full system. This is only about our focus and timing. I prefer iterative improvement over Big Bang releases.

In concrete terms, I think this means:

• Identity Platform which may be used independently of tbDEX. Some users may want identity but have no interest in speaking tbDEX message formats or protocols.
• tbDEX message format and protocol which does not rely on the Identity Platform. Some users may wish to transact while leaving identity to traditional methods with their institutions.

If we can decouple these work streams, I believe we may get the following benefits:

• Greater autonomy for component developers
• Ability to release subsets of the system before the whole thing is done

But we have some open questions to get there. Could we talk through:

---

1. What does a tbDEX without Hubs look like? It is a centralized set of services and the client calls upon them directly, like a REST call?
2. Is tbDEX without Hubs necessarily decentralized? What can we do to make it decentralized before Hubs are ready?
3. What use cases can we write down for the Identity Platform user who does not want tbDEX?

---

S,
ALR

[decentralgabe]

(1) This warrants a wider discussion, certainly. My opinion, and I'm willing to be convinced otherwise, is that if we do not start with hubs we're headed down a path that will be difficult to get off of. Changing course a few months later as we add in more diverse usecases may be making "future us" holding a lot of tech debt. I'd love to see us build a minimal hub from which we can build upon in terms of functionality and decentralization (running on different platforms, service providers, languages) from the get go to avoid later headache.

At the same time, I see risk in coupling protocols (tbDex) to specific technology implementations (hubs) and it's a useful exercise to discuss how they can be sufficiently decoupled, and how each can be strengthened by the use of one another.

(2) brings up a really good point that i'd like to get a bit deeper into (either here or another discussion). What is decentralization? Where do we want to be on the spectrum of decentralization for each component of our infrastructure/protocols? Can we start less decentralized and go more decentralized? How can we map/visualize/agree on our decentralization, the pros/cons and areas we may change as we progress?

(3) I'm super interested in this one. I'm not certain, but as soon as we have a wide array of use cases for credentials and their accompanying infrastructure we can move towards building a more robust system and testing our assumptions.

[ALRubinger]

My opinion, and I'm willing to be convinced otherwise, is that if we do not start with hubs we're headed down a path that will be difficult to get off of.

This is critical to what I want to suss out. Can we expand on why starting with hubs makes our life easier later for integration? Is this opinion shared by others?

[decentralgabe]

@csuwildcat and @mistermoe do an excellent job making the case below!

[ALRubinger]

What is decentralization?

I think Moe's seeded us below with a great starting point for navigating that. We can spin into another thread if we'd like.

If there is a spectrum of decentralization, what are the features which make it up? Moe proposed 5.

• Private key self-ownership (noncustodial - for keys)
• User communicates directly with endpoints (PFIs, VC Issuers)
• Endpoint communicate directly with user
• User has copy of all application data (noncustodial, again - for data)
• Standards-based format

There's a nuance to standards-based formats I'll spin off into a new discussion.

[mistermoe]

What does a tbDEX without Hubs look like? It is a centralized set of services and the client calls upon them directly, like a REST call?

Is tbDEX without Hubs necessarily decentralized? What can we do to make it decentralized before Hubs are ready?

I'm going to answer this by starting fully centralized and then introduce means to achieve decentralization incrementally. Keep in mind that decentralization is not binary. It's a spectrum. How much can decentralization can we achieve without hubs?

Here's what I imagine to be fully centralized:

This is very close to the concept of a "marketplace" where:

• PFIs and Issuers must "apply" to become "vendors" on tbDEX (really tbCEX). Generally, there is some process controlled by Block/TBD to become listed as a PFI or Issuer.
• All communication between Alice <-> PFIs and Alice <-> Issuers is mediated by Block/TBD.
• PFIs still run their own "nodes" that expose RESTful APIs. The endpoint paths are all stated within the tbDEX spec doc. So, to send an ASK to all PFIs, a wallet knows that they're always sending a request to something like POST /asks. The only thing that changes between PFIs is the hostname which each PFI provides to us when they apply to become a vendor.

OK, let's start to decentralize. What's the main centralizing aspect here? It's that Block/TBD is the necessary centralized intermediary. We need to remove that and ensure that:

• PFIs and Issuers can be discovered and reached directly.
• There's no gatekeeper or bouncer that Alice has to get through in order for her ASK to reach any PFI.
• There's no single, centralized list of PFIs that everyone refers to in order to find all PFIs.

How can we achieve this? DIDs 💡

A DID can be looked at as a decentralized routing table. Concretely, did:ion:123, when resolved, yields a JSON object (AKA DID Document). This JSON object contains a property, service that is used express ways of communicating with the DID subject. A service can be any type of service the DID subject wants to advertise, including decentralized identity management services for further discovery, authentication, authorization, or interaction. Here's what that might look like for a PFI:

{
    "service": [{
        "id": "pfi1#service1",
        "type": "tbDEX/PFI",
        "serviceEndpoint": "https://tbdex.pfi1.com"
    }]
}

Every PFI has a swagger endpoint like this and they're all running the same API. Wallet developers refer to this PFI API documentation to figure out what endpoints to hit and in what order. The same would have to be the case for Issuers. Again, All of them have to be exposing the same API endpoints for wallet developers to know what endpoints to hit. Different API endpoints per Issuer or PFI would be a nightmare for wallet developers. In order to support a new PFI or Issuer, wallet developer would have to learn and implement support for that PFI's or Issuer's REST API.

Ok, so we're using DIDs, what's the diagram look like now?

Note: I didn't include PFI/Issuer Discovery in this diagram. We're going to assume that discovery happens prior to any tbDEX messages being sent which i'm considering as out-of-band.

Ok. That's progress. We've removed the centralized intermediary. Alice can reach PFIs and Issuers directly. But wait...how do PFIs/Issuers respond to Alice? There are two major points to note before we get into potential approaches:

• Alice is using a wallet app on a mobile phone.
• Responses need to be asynchronous.
  • There's no telling how much time is required for PFIs or Issuers to run proprietary business logic in order to make decisions like: "Can we Issue Alice a DL VC?"

let's walk through a few potential approaches:

Polling

Polling is the simplest approach to get responses back to Alice "asynchronously." The general idea would be:

• Alice sends Request to PFI or Issuer. The response to this request includes the following:
  • Request ID
  • A Signed and Encrypted JWT:
    • Signed using a key referenced within the PFI or Issuer's capabilityDelegation property within their DID Document
    • Encrypted using all of the keys referenced within Alice's keyAgreement property within her DID Document
    • Minimum Payload including

      {
          "sub": "did:ion:alice",
          "iss": "did:ion:pfi",
          "iat": 1645750314,
          "rid": 1
      }

• Alice decodes the JWT and decrypts its payload
• polls the appropriate endpoint for status updates until one is available e.g.

  GET /requests/$id HTTP/1.1
  Host: $pfi_host
  Authorization: Bearer $UNENCRYPTED_JWT
  

Here are some sequence diagrams to illustrate Request/Reply flows:

Apply / Issue VC Flow

sequenceDiagram
    participant A as Alice
    participant W as Wallet
    participant I as Issuer
    
    W ->> I: What VCs can I Apply for?
    I ->> W: Cred Manifest
    W ->> I: Send me the form for VC X
    I ->> W: JSON Form
    W ->> W: Render Form
    
    A ->> W: Fill out form and submit
    W ->> I: Filled out Form
    I ->> W: Request ID + JWT
    loop every 10s
        W ->> I: Do you have a reply for REQ ID?
        I ->> W: REPLY || Still Processing
    end

Loading

ASK / BID Flow

sequenceDiagram

    participant AL as Alice
    participant W as Wallet
    participant A as PFI A
    participant B as PFI B
    participant C as PFI C

    AL ->> W: Fill out ASK form
    W ->> A: ASK
    A ->> W: REQ ID + JWT
    W ->> B: ASK
    B ->> W: REQ ID + JWT
    W ->> C: ASK
    C ->> W: REQ ID + JWT
    
    loop every 10s
        W ->> A: Do you have a reply for REQ ID X?
        A ->> W: REPLY || STILL PROCESSING
    end 
    
    loop every 10s
        W ->> B: Do you have a reply for REQ ID X?
        B ->> W: REPLY || STILL PROCESSING
    end
    
    loop every 10s
        W ->> C: Do you have a reply for REQ ID X?
        C ->> W: REPLY || STILL PROCESSING
    end

Loading

There's two major drawbacks to this approach:

• ❌ No push notifications. You have to open the wallet app to check for responses (AKA BIDs in response to ASKs)
• ❌ Challenging to scale
  • Polling 4-5 PFIs / Issuers may not have much of an impact on data usage or battery life but having to poll hundreds of PFIs would definitely have an impact

Let's evaluate how decentralized this approach is:

Question	Y / N
Are all private keys in the custody of Alice?	✅
Is Alice communicating directly with PFIs / Issuers?	✅
Are PFIs / Issuers communicating directly with Alice?	✅
Is a copy all application data in Alice's possession?	✅
is all application data in a standards-based format?1	⚠️

This approach seems to be sufficiently decentralized. Application data adhering to a standards-based format reduces portability friction. Portability friction however, does not outright prevent someone from accessing the financial utility provided by tbDEX.

I don't think we're willing to give up push notifications given the crucial role they play for UX, so we need to modify this approach in order to support them.

A push notification can only be delivered to a mobile device by the application developer. In this case it's the wallet developer. You can read about how push notifications work for iOS specifically, here. The gist is that the app developer can opt to receive a user's device token which is a unique token specific to a user's device AND the application. Bare minimum, the wallet would need to store a mapping of DID -> Device Token in order to support push notifications. Unless Apple / Google make big changes, this is how PNs will work for the foreseeable future.

So, this means that PFIs / Issuers will have to send a request to some RESTful API hosted by the wallet developer indicating that a reply is ready. Here's how the flow would look:

• Alice sends ASK to the PFI along with a reply_to address.
  • reply_to is fully qualified URL that PFIs can send a message to.
    • e.g. api.somewallet.com/replies
• When a reply is ready, PFI sends a request to the reply_to address containing:

  {
      "from": "did:ion:pfi1"
      "to": "did:ion:alice",
      "rid": 1,
      "description": "some useful info to provide context in PN"
  }

• Wallet receives request. Looks up device token associated to DID and sends a push notification to the respective device.
• Alice sees PN and opens the wallet app.
• Wallet makes request to PFI to "pick up" the reply.
  • This is the same request we were making when we were polling

Here's a diagram illustrating the above flow:

sequenceDiagram
    participant A as Alice
    participant WA as Wallet App
    participant WS as Wallet Server
    participant P as PFI
    
    A ->> WA: Fill out Ask and Hit Submit
    WA ->> PFI: ASK
    PFI ->> WA: Req ID + JWT
    PFI ->> PFI: process
    PFI ->> WS: Reply ready
    WS ->> WA: Push Notification
    A ->> WA: Open App
    WA ->> PFI: Give me the reply for REQ ID
    PFI ->> WA: Reply
    WA ->> WA: Render

Loading

🎉 We now have push notifications and we also don't have to violently poll anymore.🎉

Note: This response is already absurdly long so I'm intentionally leaving out things we'll need to consider like "Wait, can't anyone just Notification bomb any user now?"

Let's evaluate how decentralized this modified approach is in the same way we did earlier:

Question	Y / N
Are all private keys in the custody of Alice?	✅
Is Alice communicating directly with PFIs / Issuers?	✅
Are PFIs / Issuers communicating directly with Alice?	⚠️
Is a copy all application data in Alice's possession?	✅
is all application data in a standards-based format?	⚠️

Alice's reliance on a wallet developer as a means to inform her that a reply is waiting for her opens up room for censorship. A wallet could decide to only inform users when they receive replies from PFIs that they prefer. Moreover, A wallet developer could choose to not inform a user of any replies at all. This, however is not due to the architecture described. It's the unavoidable cost to support push notifications. Any architecture will run into the same potential for censorship. It becomes a trade-off between UX and decentralization.

We already addressed the benefits of data adhering to a standards-based format. The point still stands that this is more a quality of life matter, not a means of restraint.

So, what's lacking here? What do Identity Hubs provide that this approach doesn't?

• Theoretical ease of portability. More simply put, how difficult would it be for Alice to move to another wallet provider with all of her data? By "data" I mean both keys and application data.
  • Porting keys to a different wallet has nothing to do with this architectural choice.
  • Application data is a different story. Application data includes things like preferences (preferred PFIs), fiat receipts, tbDEX message threads, and really anything that there's no defined spec or standard for.
  • Moving from one wallet to another is dependent on whether Alice's current wallet supports an "export" or "eject" in addition to whether the wallet you want to move to can import what your old wallet exported.
  • Assuming that both wallets support hubs, leverage the same schemas, and read/write to Alice's logical hub, then Identity hubs could reduce portability friction
• Multi-device support is dependent on whether Alice's wallet provider has offerings on other platforms (e.g. desktop / browser).
  • Identity Hubs make it so multi-device support is not tied to a vendor you choose on one device. Assuming that Alice's mobile wallet and desktop wallet both support hubs, the providers could be completely unrelated. This doesn't port your private keys from your mobile wallet to your desktop wallet unless you store your private keys in an Identity Hub itself.

Orthogonal to tbDEX specifically, Identity Hubs bring with them a whole world of interoperability potential by allowing individuals to directly access or request access to any data stored in Alice's Identity Hub. this could be anything from Netflix preferences and music playlists to Alice's home address or employment status. Again, having or not having this potential does not directly impact tbDEX as it currently stands. This also doesn't discredit the potential that Identity Hubs could bring to the table if they gain adoption.

The last question that comes to mind then is: Well, if we started by introducing tbDEX without hubs, could we eventually move to a hub-based architecture?

Introducing any change, however small, to a decentralized system is significantly difficult. Despite having incentives to do so, upgrades to blockchain miner/validator software takes months to years to gain widespread adoption. Practically speaking, a full-sweep migration to Identity Hubs for all wallets, PFIs, and Issuers seems unlikely if there's an approach that's already gained widespread use. From this perspective, not using Identity Hubs from the beginning has more of a likelihood to negatively impact the adoption of hubs than anything else. Admittedly, this take is fully speculative.

I intended to lay out two additional non-hub approaches but I've likely already lost 80% of readers by now so I think it's safe to leave those for a different time because the approach discussed above is the simplest and seems to achieve sufficient decentralization.

In summary:

What does a tbDEX without Hubs look like? It is a centralized set of services and the client calls upon them directly, like a REST call?

Kind of. not sure about the 'centralized set' aspect.

Is tbDEX without Hubs necessarily decentralized? What can we do to make it decentralized before Hubs are ready?

I believe you may have meant 'sufficiently decentralized' instead of 'necesarily decentralized'.

If so, IMO, yep absolutely.
If not, I'm not sure how to answer 🙃

What use cases can we write down for the Identity Platform user who does not want tbDEX?

deferring to @csuwildcat for plugs

Footnotes

1. The benefit of all data adhering to a format specified in a standard is ease of portability. ↩

[ALRubinger]

I believe you may have meant 'sufficiently decentralized' instead of 'necesarily decentralized'.

Good call-out. Let me try to nail it down:

• Is tbDEX without Hubs, by definition, centralized on its own?
• What else can bring it elements of decentralization, if not Hubs?
• And is that approach a good first step, or does it add a bunch of work we just want Hubs to replace?

[mistermoe]

1. Nope. I don't think that tbDEX without Hubs, is inherently centralized.
2. the approach I describe in my post which can be largely summarized to: DIDs
3. Hard to say in just a few words. I'll venn diagram it out

[hellendou]

So is that "Reply Ready" hitting another restful API? Why are we not sending events/jobs to a queue to be processed when the Wallet or PFI is ready to process it.

[csuwildcat]

Moe's decomposition of approaches is an important exercise. I noticed there were a few considerations that could be fleshed out further, which leads to the higher-level question of what functionality, components, and system guarantees we must support regardless of what we output. To that end I have put together the following set of ecosystem promises and technical requirements we must deliver on to produce a viable output we can safely, confidently expose to users.

Promises to the Ecosystem

1. There must not exist vendor/provider lock-in for any identifier, credential, or personal/wallet data component of our work. A system is fundamentally centralized if the parts a user is supposed to own and control are effectively inseparable from a controlling entity.
2. Whatever we develop must be based on standard specifications that are in (at very least) a draft state (or equivalent) within an appropriate standard organization. If our work is not based on open standards, it is just another corporate project that happens to have a permissive license.
3. We must 1st class the effort to generally advance the wider Decentralized Identity ecosystem with our work. The goal is to maximize the return on all our goals and investments for every dev hour we spend. We should not attempt to put in an 80% effort to do something isolated when putting in a bit more realizes our other foundational goals and unlocks magnitudes more value.
4. We must not fragment the wider decentralized identity/app ecosystem by introducing one-off conventions for things that already have standards momentum.

Technical Requirements

Absent any prescription for the How, the following table represents the What our deliverables must account for:

Requirement	Description
Multi-Provider Support	Users must be able to use a mixture of different wallet/service providers without being forced to choose one wallet/service instance across all devices and experiences.
Multi-Device Support	Individuals must be able to use their wallet/services across multiple devices, with the same DIDs, credentials, and data present on them all.
Data & State Portability	All DID metadata, credentials, retained messages, and other personal data MUST adhere to a standard format/mechanism that allows different wallets/providers to import/export all elements of data and state required to boot up the user across vendors.
Capability-Based Authorization	Because there exists a need for N parties to contact the user at their endpoint(s) to prompt and facilitate various interactions, we must implement a capability-based authorization model that relies on DIDs, not centralized usernames/accounts.
Transport Agnostic	The system should not force all credential interactions and general DID activities into reliance on a single transport, given the scope of these activities goes beyond tbDex.

Resource Assessment

Moe, Gabe: please reflect on the promises and technical requirements detailed above to assess the approximate development time required for a standardized personal data storage/relay approach vs a 'traditional' use-case-specific server implementation. Please also highlight the timing diff between the them, to the best of your ability.

[csuwildcat]

Portability is not a debatable requirement in the use of these technologies, so it's exclusively a question of how we do it. The implicit reality of a non-Hub route is delivery of a brand new set of standards defining all constituent parts. While I would advise against doing that when we have a standard solution so close at hand, I am willing to prep everyone for what that will require. Remember: this isn't merely an open source effort, it's a standards effort, and the latter is far more rigorous than the former.

[ALRubinger]

Here's what I'm reading so far:

Portability is important to us. To get that, we want open specs or standards. The components are:

Component	Type
DID	W3C Spec, Standard
VC	W3C Spec, Standard
tbDEX Message Format	TBD Open Spec
Wallet vendor extensions	Unspecified

What's the problem here? A compliant Wallet impl would have to conform to the DID and VC standards, and the tbDEX Message Format open spec. And we can't control what other features a Wallet impl mad add which makes it non-portable, in the same way:

• Git is a known standard and the repo contents of Git repos are portable between GitHub and GitLab but not extensions like Issues, Wikis, settings.
• Web browsers implement HTML5 but may have their own extensions they also support, nonstandard.

Seems to me we don't have a problem here to solve WRT portability, no? Let's make the tbDEX Message Format open spec and carry on?

[csuwildcat]

It's not about the objects being from standard, well-recognized schemas, it's about all that needs to go into codifying import/export formats, transmission, etc. of all state and data, the more general credentials mechanisms that will be used outside of tbDEX, and standardization of an async drop-off mechanism. What are we going to do, tell people/businesses who want to use the same creds/data for different things that they need to use some rando dex API to do so, or start Yet Another Random Sever Project just to pipe the data into other scenarios? tbDEX is a family of messages that rides on the rails of the general decentralized identity/protocols platform.

[decentralgabe]

I agree on portability being a requirement. What I'm still wrapping my head around is how we enforce that requirement.

From what I'm hearing @csuwildcat we can take strides to make portability much simpler: standard messages = simpler to have portable messages. Standard import/export formats = simpler to have portable data in a generic manner. Standardization across transports and standardization across anything else we can standardize on makes portability simpler.

Making data types, protocols, transmission, etc. standard is a convincing strategy towards lowering the barrier of portability; however it doesn't guarantee it. By this I mean: an application can send and receive messages in a standard format, store them in a standard format, transmit them in a standardized manner and still refuse to expose import/export in that standard format to an individual.

Protocols can only enforce protocol things. What's between a service provider and an end user is out of our control. Of course, I would not want to use such a service, and I hope there's a clear method to make such a distinction.

My last thought is that creating a hub drastically reduces the barrier to portability because companies don't have to build their own. They still might, but we'd be shipping something that "does the thing" out of the box, and that's a huge win. And if we don't build hubs, we're increasing the burden on everyone to support these standards, and get up and running on tbDex.

[csuwildcat]

Let's ask ourselves some questions to understand the requirements:

1. Alice wants to use Wallet A on Device X and Wallet B on Device Y. The wallets are made by different companies. They need to sync and act on the same set of data, some of which are tbDEX messages, but also general credentials and personal identity data. What is the protocol (serialization, transmission, ingestion, etc.) for keeping these two wallets in sync?
2. Alice wants to use her wallet to apply for or present a credential that is not related to tbDEX currency transactions - how does she do everything required for application, issuance, delivery, and lifecycle management of those credentials? How does she use them outside of tbDEX flows?
3. Alice or a company wants to publish profile info, credentials, and other identity data so all parties can locate it and utilize it - how do they do that outside of tbDEX flows?

There are two things these questions highlight:

1. You'd have to create new specs for the implied mechanisms that must exist to perform these functions (which is a shame, because Hubs already account for them).
2. Once you standardize these new specs that do what Hubs do, I guess they'd all be implemented under the umbrella of a one-off dex messaging server (?). Surely one can see how bizarre that would be, given these functions are part of a generalized platform that needs to work outside of tbDEX flows.

[csuwildcat]

We've already identified multiple things that would need new standards and the same/greater effort if done as a random REST service, but there are a few more that haven't been fully discussed yet: encryption, signing, and authorization.

Various data in the system must be signed and/or encrypted with the DIDs of participants to ensure it is verifiabily linked to a given DID and/or only accessible to designated parties. This signing and encryption model must be message-level and composable so the construction of the objects aren't dictated by random provider formats. If you don't use Hubs you will be required to produce a new standard that provides for all 4 message-level data states: raw, signed, encrypted, signed + encrypted. Hubs of course already defines a data model that meets these requirements (https://identity.foundation/identity-hub/spec/#messages).

Messages, and the data model used, must also incorporate composable authorization based on DID-signed capabilities. The authorization mechanism must integrate into the same data model used for the signing and encryption components. This has already been fleshed out for Hubs and we have PRs imminent.

I could prepare folks for the mountain of effort it will take to secure a standard Working Group item and repeat this work to meet the requirements, but this is simply the wrong course that will harm the larger effort, confuse the community, and cost us a significant amount of additional time, so it's not something I will support.

[ALRubinger]

Appreciate the care and thought you've all put into this so far. We're getting closer. This looks like a good point to check in with the main goals of this discussion and see where we're at:

Our first use case requires currency exchange, decentralization, and data portability. It does not require identity. This is why I encourage us to decompose the system. In my first post, I asked if we could make a:

tbDEX message format and protocol which does not rely on the Identity Platform. Some users may wish to transact while leaving identity to traditional methods with their institutions.

From @csuwildcat, I'm hearing: "nope, that ain't a good idea":

I could prepare folks for the mountain of effort it will take to secure a standard Working Group item and repeat this work to meet the requirements, but this is simply the wrong course...so it's not something I will support.

And I've understood your reasoning is: the Identity Platform should bring decentralization and data portability to tbDEX.

Got it.

And @decentralgabe advocates for our avoiding tech debt by starting with a small hubs model:

I'd love to see us build a minimal hub from which we can build upon in terms of functionality and decentralization (running on different platforms, service providers, languages) from the get go to avoid later headache.

Gabe:

• Is that necessarily an Identity Hub or can it be a tbDEX-only one?
• When people run Hubs in the future, they can choose a Hub impl that's tbDEX or Identity or both?
• Is this still your position, or do you have new thoughts since Moe laid out an alternative approach?

What I've understood from @mistermoe: there are other ways to bring decentralization and data portability to tbDEX, for instance the DIDs and push notification flow. Does this approach make our job tougher later?

That leaves me to balance two competing ideals:

Ideal	Real life impact
1) Modular, extensible architecture	tbDEX use cases may be fulfilled without ID components where they're not needed
2) DRY Principles	We don't waste time or detract from community efforts with duplicative work

Remember: this isn't about whether to make Hubs. We're invested and it's happening. This is about how we focus our near-term efforts. How much we can scope down to deliver smaller things faster?

I hope we all understand why I'm encouraging us to question ourselves. We have use cases for currency exchange but not identity. I don't want to require folks bring in a full identity platform to get that done. That's weird. Like, let's all admit how weird that is, even if it's what we decide to get decentralization and portability. It's super weird.

The Big Question left for us, which will inform how we focus our time in the near term:

1. Can we deliver on currency exchange for our North Star use case before Hubs or other ID components are ready, by investing in tbDEX message format, transport, import/export, and other areas of the system that bring us portability and decentralization?
   1a) ...without our short-term decisions too adversely impacting long-term goals?

@csuwildcat's sentiment has either got to be shared by the team or we evolve it together:

tbDEX is a family of messages that rides on the rails of the general decentralized identity/protocols platform.

Let's commit to an answer on these by Friday, the 4th.

[decentralgabe]

Our first use case requires currency exchange, decentralization, and data portability. It does not require identity.

What? This is the first I've heard about it not requiring identity. Is there a PRD or any documentation that lays out clear requirements? That should be a prerequisite before we begin designing so we are all on the same page and building toward a common goal.

Is that necessarily an Identity Hub or can it be a tbDEX-only one?

I'm not sure what this means. We should not couple technologies based on use-cases; we should be developing generic technologies that can be used to solve specific use-cases.

When people run Hubs in the future, they can choose a Hub impl that's tbDEX or Identity or both?

This isn't clear to me either. What functional differences would exist? Hubs are DID-based systems. Identity, and specifically decentralized identity are core to the specification and applications that hubs enable. Additionally, what benefit is there in prematurely bifurcating the standard?

Is this still your position, or do you have new thoughts since Moe laid out an alternative approach?

I don't see Moe laying out an alternative approach. I see Moe listing out some thinking and describing tradeoffs. If I misinterpreted this, @mistermoe please help me understand your current thinking.

Looking at our problem space more generally I still believe not building hubs right now has four concrete issues:

1. We make it more difficult to change course later if we do build hubs: for PFIs to adopt the standards-based infrastructure and to even get started given our choice of tbDex path-dependence.
2. We increase the barrier to entry for all participants in the ecosystem. Click-button decentralized infrastructure = anyone can participate = a more decentralized system. Having to roll your own = higher barrier to entry = less decentralization.
3. Not considering a multi-transport, multi-hardware, multi-use case protocol similarly impedes decentralization ambitions and makes later standardization more difficult.
4. They will need to be built eventually, either by us or all PFIs (even if they're not spec-compliant hubs, all PFIs will need very similar infra). We'd be delaying the inevitable, and for what benefit?

When you examine the requirements @csuwildcat lays out here #5 (comment) we end up with a piece of technology that is similar to our conceptualization of hubs. If you are suggesting these requirements are not requirements, then let's first discuss and agree on that.

Remember: this isn't about whether to make Hubs. We're invested and it's happening. This is about how we focus our near-term efforts. How much we can scope down to deliver smaller things faster?

My suggestion was to identify the hub capabilities needed for tbDex, and build those first. Not to build a tbDex-specific hub. Still a generic hub, but maybe there are some capabilities we can build on later (like an inbox feature). I'd also like to better understand your position @ALRubinger on the work scope of hubs compared to potential alternatives. To me, we can make meaningful progress on hubs, accomplish tbDex, and build toward a future with a diverse set of use cases at the same time, without taking what I'd consider to be too much time.

tbDEX is a family of messages that rides on the rails of the general decentralized identity/protocols platform.

I'm in 100% agreement with this statement and share Daniel's view on our Decentralized Identity strategy.

[ALRubinger]

What? This is the first I've heard about it not requiring identity. Is there a PRD or any documentation that lays out clear requirements? That should be a prerequisite before we begin designing so we are all on the same page and building toward a common goal.

Sounds like a great working model for a more mature organization. We're not there yet. :)

We haven't yet worked with other teams in the business to form PRDs. A consequence of everyone moving fast is that information changes quickly. I will do everything I can to get the team critical info like this as soon as possible, in public, so we can make decisions together.

Here's the context behind "the first use case not requiring identity":

• There's no regulated mechanism for KYC/AML which uses digital identity
• So that portion will have to continue over traditional channels
• And we can fulfill the currency exchange part over tbDEX and PFI impls

Here's where you give me your helpful bottom line:

@csuwildcat:

tbDEX is a family of messages that rides on the rails of the general decentralized identity/protocols platform.

@decentralgabe:

I'm in 100% agreement with this statement and share Daniel's view on our Decentralized Identity strategy.

...and:

My suggestion was to identify the hub capabilities needed for tbDex, and build those first.

OK. That's an actionable position that answers the primary question about decomposing tbDEX and Identity. From both you and @csuwildcat: a clear "no".

[csuwildcat]

Here's the context behind "the first use case not requiring identity":

• There's no regulated mechanism for KYC/AML which uses digital identity
• So that portion will have to continue over traditional channels
• And we can fulfill the currency exchange part over tbDEX and PFI impls

"OK. That's an actionable position that answers the primary question about decomposing tbDEX and Identity. From both you and @csuwildcat: a clear 'no'."

I think a critical point may not be clear to folks: when we talk about 'decentralized identity' it does not mean we are talking about identity in the narrow human/government proofing scope it is being cast as. Identity is literally everything you say, do, write, express, and transact in the digital world. When we say 'Decentralized Identity' that includes an extensible protocol for transmitting, digesting, and processing signed/encrypted protocol messages/data tied to at least a pseudonymous ID (DIDs). KYC/AML one isolated type of message/cred you might exchange over this layer, but absolutely nothing about this layer cares about or relies on it. tbDEX is a protocol on top of this layer that defines a set of messages encoded with dex-specific properties and values. The same requirements remain regardless of how you approach the work: you need some form of cross-entity resolvable identifiers, you need to authenticate interactions across participants, you need an authorization mechanism to permit activities, you need an async drop-off mechanism for long-running tasks/responses, you need a standard data model that features signed/encrypted/authz'd messages <-- that is what Hubs give you, and you will have to reproduce all that functionality regardless.

I have a proposal: we literally ban use of the term 'identity' in our conversation about this topic and instead call it the 'decentralized data exchange layer', because the term 'identity' seems to be tied to a tiny subset of traditional human/government identity documents that make up 0.000001% of what this decentralized identity layer enables.

[ALRubinger]

This is a very helpful response. You've mentioned these points before, and it's taken me some time to crystalize them.

I understand your position now; thank you.

Looking forward to seeing Moe's perspective on how this impacts our decision regarding Hubs as the method of achieving decentralization and portability.