tbDEX PFI 🤝 FTL

[KendallWeihe]

This is a large PR, apologies for that. Going to make an attempt to make it digestible here in the description, so please read carefully before proceeding.

Why?

The elevator pitch here goes something like: Build a tbDEX PFI (by building a HTTP API), using FTL, for three reasons:

1. Provide usable feedback for both tbDEX & FTL
2. Useful as a developer integration tool
3. Because it's cool 😎

---

What?

• bin/ initializing FTL dependencies (Hermit & thangs)
• ftl-module-pfi/ the actual PFI implementation, using FTL
• integration-sample/ a NodeJS app for development purposes, which acts as "Alice" in the tbDEX flow

---

Where?

I'm not sure we want to merge this in. I'm sure we'll want this, but I'm not sure we want it here in the tbdex-pfi-exemplar code repo. If we yank it out, and place it somewhere else, the only dependency we'll need to duplicate over, is the items under the db/ directory; otherwise, everything is self contained within the ftl/ repo.

---

If you want to get your hands dirty, then follow the README -- it's crude, but should provide enough to get off-zero.

[Note]: if you want to do this prior-to us cutting a 0.7.0-beta tbdex-kt release then you'll need to gradle publishToMavenLocal in tbdex-kt such that this project can pull from your local JARs.

---

Current Limitations

• This PFI uses the native FTL HTTP bindings (by using the @Ingress feature), but it isn't fully compatible with the spec. The reason being, we can't currently expose types within FTL interfaces which aren't defined within a ftl.* namespace; ergo, what's built in the tbdex-kt's protocol package can't be used in an FTL verb. So, instead, the current solution is to stringify the data over the HTTP API layer.
  • Notice, the integration-sample NodeJS project. This project is intended to be "Alice" in the tbDEX flow. Notice how we're not currently using the @tbdex/http-client package, because the way we're forced to stringify the data over the HTTP API. Instead, we're directly making the fetch() HTTP request.
  • For example, on this line, you'll see something like const offerings = JSON.parse(body.offerings) 👉 we're having to parse the stringified JSON within the HTTP body in the client code
  • For this same reason, everything is currently housed within a single FTL Module, instead of broken up into many modules. Because, we use the various tbdex-kt and web5-kt types as parameters all over the place, and we can't use those over an FTL context.call(...)
  • We have ongoing discussions about how we're going to resolve this with the FTL tech
• DID private keys are currently hardcoded, but who cares, it's a sample
• Ideally, we use some middleware exposed from the tbdex-kt's httpserver package to perform validations... I think there have been some things merged there, but we're not up to date with the latest from that package

---

Before merging

• [x] We need to cut a new tbdex-kt release (0.7.0-beta) and update the pom.xml such that we're pulling tbDEX dependency from the remote, rather than local
• [ ] Decide if we want to house this code in this repo?

[KendallWeihe]

what mains makes maintaining it cleaner?

Intuitively, I would bet keeping git repos language-specific would be the wise move. Which means, we should have separate tbdex-pfi-exemplar-js and tbdex-pfi-exemplar-ftl repos.

[michaelneale]

@KendallWeihe yeah that is the pattern we use elsewhere

[michaelneale]

@KendallWeihe I would almost call this tbdex-pfi-examplar-kt - and make the focus on that? FTL is the "detail" on how to run it perhaps? can that work?

[KendallWeihe]

call this tbdex-pfi-examplar-kt

Yeah totally agree

[michaelneale]

had any more thoughts on this @KendallWeihe or should close it/move it?

[KendallWeihe]

had any more thoughts on this @KendallWeihe or should close it/move it?

oops, still lingering

closing for now, can use for reference down the road, thanks!