by Marla Natoli

We're hard at work building solutions that simplify data aggregation, verifiability, and collaboration and are excited to share a sneak peek into our ongoing work with WeatherXM. Learn more about what we're up to in our recent blog post: here.

by Andrew Hill

The objective was to understand the intricacies of the DNS chain of trust, starting from a specific TXT record on a domain to the root zone. The process involved collecting necessary data and understanding the verification steps. The code is documented here.

Problem: The challenge was to accumulate all required data, and then ensure every element in the chain of trust was verified accurately and that independent of the data provided, if it resolved to a known root, a recipient could believe it was true.

Discoveries:

1. Accumulating data was straightforward but required meticulous attention to each DNS record and corresponding signatures.

2. Verification steps were logical but needed precise execution, especially when verifying signatures.

Challenges:

1. Ensuring accurate verification required understanding DNSSEC specifications.

2. Verifying the final parent's DS record signature and ensuring it was signed by the root was a tough nut to crack, which required a thorough understanding of the DNSSEC validation process."

Final Outcome:

• The code used for this experiment is available on this gist, feel free to run it yourself.

• We discovered that a simple chain of trust was fairly compact, as reflected in the JSON output of our chain data, making it easily storable and transferable.

• We attempted writing the code in various languages but found Python to have good tooling, making it fast.

• One crucial piece of information missing from our data payload was the timestamp of collection, which is necessary for future verification purposes.

by Dan Buchholz

The Tableland SDK was designed with full Cloudflare D1 API conformance in mind. Recently, Cloudflare updated the D1Database APIs with a couple of small but breaking changes. This required a minor refactor to the @tableland/sdk that, primarily, changed the response on the Database class exec method. Before, it would return a meta object that contained data like count, duration, and txn information. After the refactor, these had to move up a layer in order to conform with the API, so these are now top-level returns vs. nested in object. It feels almost the same as before. For example, instead of a pattern for mutating queries with like await meta.txn?.wait(), it now looks like await txn?.wait(). Again, this is only for the exec method; all others work with the existing meta pattern.

A couple of other small refactors included dropping a createTable method and RunSQLParams type, which weren't being used anymore after we changed our Tableland Registry contract methods some months ago. We also added a @tableland/node-helpers package to handle table alias functionality for developers using Node.js, and we pulled this out of the SDK (where it previously was before) to satisfy non-Node.js environment issues in that library.

These changes aren't published, yet, but will be in the near future with @tableland/[email protected] and @tableland/[email protected]!

by Jim Kosem

Platform Design is not a term that comes up often in user experience design or in conversations around developer tools, yet should be in both. While crafting a presentation to be made during IPFS Connect Istanbul, and thinking about design and what it means for developers, but what it means for data tools and decentralisation.

The main premise is that when designing for developer tools, especially developer tools for apps that are especially niche or complex for end users, that the design thinking needs to be quite wide and loose. The designer and the developers together need to think not in terms of classic user centred-design with defined end users, but about the platform. That means that the tools and interactions they design and build take place in a large playing field of sorts where a lot more things than a limited set of interactions and tasks. This means that thinking about designing tools to build tools means designers and developers don't just need to think about the length of width of the playing field, but need to think about how and where that field ends and not dictating how the play happens, but setting up the rules.

• We’re sponsoring the Rebuild Ownership 2.0: Internet Privacy hackathon, kicking off on November 9 and running through December 10. Only a few days left to sign up, and we’ll be giving out a $1k prize to the top winner!

• We’ll also be at Devconnect / LabWeek in Istanbul, starting on November 13. Both Carson Farmer and Jim Kosem will be there, so keep an eye out for them there or dive into our Discord if you’d like to connect & meet up IRL!

Want to dive deeper, ask questions, or just nerd out with us? Jump into our weekly research office hours. Or, for hands-on technical support, you can join our weekly developer office hours.

And if you’d like to discuss any of these topics in more detail, comment on the issue over in GitHub!