DEV Community: Matt Hamilton

Why Semantic Search Matters... especially in Barbados!

Matt Hamilton — Tue, 02 Dec 2025 21:31:43 +0000

How Semantic Search Finds Products That Keywords Miss

I've been building this product search engine for Barbados called "Yuh Gettin' Tru?" (Bajan for "Are you finding what you need?"), and I wanted to share something that perfectly illustrates why semantic search matters.

The Problem with Traditional Search

I was testing the site against a local home store called Dwellings. They sell all sorts of home goods - furniture, kitchenware, decor. I searched for "hardwood cutting board" on their website and got... nothing. Zero results.

Now, here's the thing. They absolutely do sell hardwood cutting boards. They have these lovely acacia wood boards with handles. But their product database doesn't call them "hardwood cutting boards" - it calls them "Acacia Cutting Board with Handle".

Traditional keyword search sees "hardwood" and "acacia" as completely different strings. No overlap, no match, no results. The customer leaves, probably assumes the store doesn't stock what they need.

What Semantic Search Does Differently

When you search for "hardwood cutting board" in Yuh Gettin' Tru?, the system understands that you're looking for a cutting board made from hard, durable wood. It doesn't just match keywords - it matches meaning.

The same search returns those acacia cutting boards with a 90% match score. And here's the bit I'm particularly pleased with - it explains why it matched:

"This is a cutting board made of acacia wood, which is a type of hardwood. It is a very good match for the query."

The system knows that acacia is a hardwood. Not because someone manually tagged it, but because the embedding model (sentence-transformers/all-MiniLM-L6-v2) has learned the semantic relationship between these concepts.

How It Works Under the Hood

The technical pipeline is quite satisfying to work on:

Vector embeddings - Each product gets converted into a 384-dimensional vector that captures its semantic meaning. "Acacia cutting board" and "hardwood cutting board" end up quite close in this vector space because they mean similar things.
Similarity search - MongoDB Atlas Vector Search finds the closest matches in milliseconds, regardless of exact wording.
LLM reranking - Gemini Flash takes the top candidates and scores each one for genuine relevance, filtering out false positives and generating those explanations.

The whole process takes about 3-5 seconds, most of which is the LLM reranking. The vector search itself is lightning fast.

Why This Matters for Caribbean Retail

Barbados has a fragmented retail landscape. Dozens of stores, each sourcing goods from different parts of the world - some from the US, some from the UK, some from Asia. This means product terminology varies wildly.

Take "cutlery" versus "flatware". If you're British (or Bajan, since we inherited British English), you call your knives and forks "cutlery". But many retailers here source from American suppliers, and their databases use "flatware" instead. Search for "cutlery" on some store websites and you get nothing. The products exist, they're just labelled differently.

Semantic search understands that cutlery and flatware mean the same thing. It bridges the gap between how customers think about products and how retailers happen to have labelled them.

The Small Things

I think what I enjoy most about this project is how the small technical decisions compound into real user value. Choosing the right embedding model. Adding category extraction from breadcrumbs. Structuring the embedding text with labels like "product:" and "brand:" to give the model more context.

None of these are flashy features. But together, they mean a customer searching for "hardwood cutting board" actually finds the acacia board they're looking for.

The small things. They matter.

Making Services Discoverable with ERC-8004: Trustless Agent Registration with Filecoin Pin

Matt Hamilton — Tue, 04 Nov 2025 21:51:57 +0000

Making Services Discoverable with ERC-8004: Trustless Agent Registration with Filecoin Pin

I've been thinking a lot about agent metadata lately. Not the sexy stuff, not the AI models or the clever algorithms. The boring bit. Where do you put the JSON file that describes what an agent does?

It's one of those problems that seems trivial until you actually try to solve it properly. You can't store it on-chain (too expensive). You can't use regular IPFS pinning (it might disappear). You can't use AWS (defeats the whole point of decentralisation). So what do you do?

This week, I finally got a chance to properly explore this by registering GitHub's MCP server as an ERC-8004 agent with Filecoin Pin. Here's what I learnt.

The Problem

The issue is simple enough to explain: when you register an agent, you need to point to some metadata, a JSON file describing what it does, how to connect to it, what it's capable of. The tokenURI in ERC-8004 parlance.

You can't store this on-chain. A typical agent card is 1-2KB of JSON. On Ethereum mainnet, that's prohibitively expensive. Even on L2s, you're looking at a chunk of change for every agent registration.

So you store it off-chain and reference it. Which raises the obvious question: where?

Generic IPFS pinning services? They can drop your content. No guarantees. Centralised storage like AWS? Single point of failure, ongoing costs, and frankly defeats the point. Store everything on-chain anyway? Not practical.

I needed something that would actually work long-term.

Filecoin Pin

I'd been aware of Filecoin Pin for a while but hadn't actually tried it. The pitch is compelling: you get cryptographic proof that your data is being stored. Daily PDP (Proof of Data Possession) checks. Decentralised across Filecoin's storage network. IPFS compatible so it works with existing tooling.

The key bit is that last part about proof. With generic IPFS pinning, you're trusting that someone, somewhere, is keeping your content around. With Filecoin Pin, you can actually verify it. Daily proofs that storage providers are holding your data.

That matters for agent metadata. If you're building something meant to last years, you need more than hope.

What I Actually Built

For this experiment, I took GitHub's existing MCP server and registered it as an ERC-8004 agent. Not building something new, just making something that already exists discoverable through the registry.

GitHub already runs a public MCP server at https://api.githubcopilot.com/mcp/. It provides repository management, issue tracking, PR tools. The usual GitHub stuff exposed through the Model Context Protocol. It's real, it's running, and anyone can use it.

What it didn't have was an ERC-8004 identity. No way for other agents to discover it. No on-chain registration. No verifiable metadata storage.

So I created an agent card (a JSON file describing the service), stored it on Filecoin Pin, and registered it on the Identity Registry on Base Sepolia. Now it has a verifiable, discoverable identity.

The Agent Card

The agent card is a JSON file that describes the MCP server's capabilities and how to connect to it:

{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "GitHub Integration Agent",
  "description": "AI agent providing GitHub repository, issue, and pull request management capabilities...",
  "endpoints": [
    {
      "name": "MCP",
      "endpoint": "https://api.githubcopilot.com/mcp/",
      "version": "1.0.0",
      "capabilities": {
        "tools": [
          {
            "name": "repository_management",
            "description": "Browse code, search files, analyze commits..."
          },
          {
            "name": "issue_management",
            "description": "Create, update, search, and manage GitHub issues..."
          },
          {
            "name": "pull_request_management",
            "description": "Review PRs, manage approvals, merge conflicts..."
          }
        ]
      }
    }
  ],
  "supportedTrust": ["reputation"]
}

This agent card gets uploaded to Filecoin Pin, which returns a CID (Content Identifier). That CID then gets registered on-chain as ipfs://<CID>/github-agent-card.json, effectively creating a verifiable, discoverable identity for GitHub's existing MCP server.

The Complete Workflow

Here's how the pieces fit together:

1. Upload to Filecoin Pin

filecoin-pin add --auto-fund github-agent-card.json

This uploads your agent card and returns:

Root CID - The IPFS identifier
Dataset ID - For checking PDP proof status
Storage deal confirmation - Proof it's being stored

The --auto-fund flag ensures your storage provider wallet has sufficient USDFC (Filecoin stablecoin) to pay for storage.

2. Register on Base Sepolia

cast send 0x7177a6867296406881E20d6647232314736Dd09A \
  "register(string)" \
  "ipfs://<CID>/github-agent-card.json" \
  --rpc-url https://sepolia.base.org \
  --private-key $PRIVATE_KEY

This mints an ERC-721 NFT representing your agent on the ERC-8004 Identity Registry.

Why Base Sepolia?

Low gas costs (it's an L2)
Official ERC-8004 reference implementation is deployed there
Easy to get testnet ETH from faucets

3. Verify PDP Proofs

filecoin-pin data-set <dataset-id>

This shows you the proof status:

Dataset ID: 933
Root CID: bafybeihhal5hlbylkibniig6j72wdrm7lr4nf6z47natleh2jkyosrg7di
Storage Provider: f01234
Status: Active
Last PDP Proof: 2025-01-15 14:32:10 UTC
Next Proof: 2025-01-16 14:32:10 UTC

Daily proofs mean you can always verify your agent metadata is still being stored. This is the cryptographic guarantee that sets Filecoin Pin apart.

4. Agent Discovery

Now any application can discover and use your agent:

# Query the registry
cast call 0x7177a6867296406881E20d6647232314736Dd09A \
  "tokenURI(uint256)" 55 \
  --rpc-url https://sepolia.base.org

# Returns: ipfs://bafybeihhal5hlbylkibniig6j72wdrm7lr4nf6z47natleh2jkyosrg7di/github-agent-card.json

# Fetch the agent card
curl -s "https://ipfs.io/ipfs/bafybeihhal5hlbylkibniig6j72wdrm7lr4nf6z47natleh2jkyosrg7di/github-agent-card.json" | jq .

The agent card tells them how to connect to the GitHub MCP server and what capabilities are available.

Why This Matters for Builders

This is still very much a work in progress. Everything here is running on testnets, and we're actively figuring out what the production infrastructure should look like. But having said that, the pattern is already useful for making any existing service discoverable as an ERC-8004 agent with verifiable, persistent metadata.

For Agent Builders

You get:

Peace of mind - Your agent metadata won't disappear
Verifiability - Anyone can check that storage is active
Decentralisation - No single point of failure
Standards compliance - Works with ERC-8004 ecosystem

For Agent Users

They get:

Trust - Can verify agents are legitimate and persistent
Discovery - Find agents via on-chain registry
Composability - Combine multiple agents together
Transparency - See full agent capabilities before using

For the Ecosystem

We get:

Infrastructure for the emerging agent economy
Interoperability via ERC-8004 standard
Long-term viability with provable storage
Foundation for reputation and validation systems

Whilst these lists look a bit like marketing bullet points, each of these actually matters. The infrastructure piece is what I find most interesting, because we're finally building the plumbing that makes agent composition practical.

We'd love to have more developers try this out and give us feedback on what works and what doesn't.

Try It Yourself

So if you want to give this a go, I've put together a complete tutorial that walks you through every step:

Register an ERC-8004 Agent with Filecoin Pin Storage

The tutorial includes:

Complete prerequisites and token setup
Step-by-step commands with expected outputs
Screenshot indicators showing what you should see
Troubleshooting for common issues
Example agent card you can customise

Everything you need is in the tutorial. It's designed to take you from zero to a registered agent in about 30-45 minutes. Having said that, if it's your first time working with Filecoin or Base Sepolia, you might want to give yourself a bit more time to get familiar with the faucets and tooling.

What's Next?

Well, this is just the beginning. The ERC-8004 standard includes three registries:

Identity Registry (what I demonstrated here) - Register and discover agents
Reputation Registry (coming) - Build trust through verified actions
Validation Registry (coming) - Third-party verification of agent behaviour

Combining these with provable storage creates the foundation for a real agent economy. I think the reputation piece is going to be particularly interesting, because that's where agents can start to build track records that others can actually verify.

Ideas to Explore

Some things I'm thinking about:

Multi-agent systems - Agents that discover and compose with other agents
Reputation building - Agents that accumulate verified track records
Validator networks - Decentralised verification of agent behaviour
Agent marketplaces - Discover and use agents based on capabilities and reputation
Cross-chain agents - Agents that operate across multiple networks

There's probably a lot more that I haven't thought of yet. If any of this sounds like something you're working on, I'd love to hear about it.

The Bigger Picture

I think we're at an inflection point. AI agents are becoming capable enough to act autonomously, but they need decentralised infrastructure to be truly trustless.

By solving the storage problem with Filecoin Pin and the identity problem with ERC-8004, we're enabling a new category of applications:

Autonomous trading agents with verifiable track records
Code review agents that build reputation over time
Data analysis agents that can be audited and verified
Coordination agents that compose multiple specialised agents
Personal assistants that users actually own and control

The key insight? Agents aren't just smart contracts. They're long-lived entities that need persistent, verifiable infrastructure. It has been a challenge working out what that infrastructure looks like, but I think the combination of ERC-8004 and Filecoin Pin gets us pretty close.

Getting Involved

The ERC-8004 ecosystem is just getting started, and we need builders to shape it.

If you want to try this out:

Follow the tutorial to register your first agent
Join the ERC-8004 discussions
Check out the reference implementation
Explore Filecoin Pin documentation

Some things you could build:

Register your existing services as ERC-8004 agents
Build agent discovery tools
Develop reputation systems
Create validator networks

The infrastructure is ready. The standard is here. So if any of this sounds like it would be useful for what you're building, then get in touch and let's chat!

Resources

Tutorial: Register an ERC-8004 Agent with Filecoin Pin
ERC-8004 Specification: https://eips.ethereum.org/EIPS/eip-8004
Filecoin Pin CLI: https://docs.filecoin.io/builder-cookbook/filecoin-pin/filecoin-pin-cli
Base Sepolia Faucet: https://www.alchemy.com/faucets/base-sepolia
Example Agent: View on Basescan

Building "Yuh Hear Dem": A Parliamentary AI with Google's ADK and a Lesson in Agentic Design

Matt Hamilton — Thu, 19 Jun 2025 01:01:54 +0000

Democracy thrives on transparency, but the raw data of governance—hours of parliamentary video, dense transcripts, and complex legislation—is often inaccessible to the very citizens it’s meant to serve. This was the challenge that sparked "Yuh Hear Dem," our submission for the Google Agent Development Kit (ADK) Hackathon. The project began as a father-daughter mentoring journey into AI and evolved into a powerful tool for civic engagement in Barbados. It combines deep experience in backend AI architecture with a fresh perspective on user experience, guided by principles from the world of education. This blend allowed us to build a system that is not only technically sophisticated but also genuinely accessible, transforming the way citizens can interact with their government.

This post details our technical journey, from the initial data pipeline to a crucial architectural pivot, all powered by Google's Agent Development Kit (ADK), Gemini, and a Knowledge Graph backend.

The Problem: From Hours of Video to Actionable Insight

Parliamentary sessions in Barbados, like in many places, are published as long-form YouTube videos. Finding what a specific minister said about a particular topic, like the "sugar tax," requires manually scrubbing through hours of footage. This creates a significant barrier to civic engagement.

Our goal was to transform this unstructured data into a structured, queryable format, allowing any citizen to ask a natural language question and get a direct, source-verified answer.

The Solution: An AI-Powered Parliamentary Research Assistant

"Yuh Hear Dem" (Bajan dialect for "Did you hear them?") is a conversational agent that allows users to query parliamentary data. A user can ask, "What has been discussed about the sugar tax?" and receive a concise summary, direct quotes from MPs, and links to the exact moments in the source videos.

The system is built on a sophisticated Retrieval-Augmented Generation (RAG) pipeline that combines the semantic power of vector search with the structured precision of a knowledge graph.

The Technical Architecture: A Three-Stage Pipeline

Our system is built on a robust data processing and retrieval pipeline.

1. Ingest, Clean, Extract

The foundation of our system is a structured knowledge base built from raw, messy transcripts.

Ingest: We start by ingesting the full YouTube transcripts from hundreds of parliamentary session videos—over 1,200 hours of content.
Clean: The raw transcripts are often riddled with grammatical errors and misattributions. We use Gemini to clean and structure this text, correcting grammar, identifying speakers, and aligning the text with accurate video timestamps.
Extract: With clean, timestamped text, we use Gemini again to perform entity and relationship extraction. It identifies people, topics, bills, and the connections between them (e.g., "Minister X spoke about Bill Y"). This structured data, including over 33,000 nodes and 86,000 statements, is stored in MongoDB Atlas.

This process creates a rich, interconnected Knowledge Graph that forms the backbone of our agent's "brain."

2. Hybrid Retrieval with GraphRAG

When a user asks a question, the agent doesn't just rely on a simple semantic search. It uses a hybrid retrieval strategy:

Vector Search: We run a vector search over MongoDB Atlas embeddings to find semantically similar transcript segments. This is great for broad, topic-based queries.
Knowledge Graph Search: We traverse the entities and relationships in our knowledge graph to find precise connections (e.g., Minister -> Topic -> Session). This excels at specific, factual queries.

The results are combined and ranked using a hybrid scoring model (GraphRAG), giving us the best of both worlds. Critically, every piece of information is grounded in video timestamps, allowing us to generate direct links to the source.

3. The Agent Architecture Evolution: A Lesson in Pragmatism

Our journey with ADK taught us a valuable lesson about the current state of multi-agent frameworks.

The Original Vision: A Multi-Agent Pipeline

# Root Conversational Agent
ConversationalAgent(
    model="gemini-2.0-flash",
    sub_agents=[ResearchPipeline]
)

# Sequential Research Pipeline
ResearchPipeline(SequentialAgent):
├── ResearcherAgent(LlmAgent)
│   ├── Tools: [hybrid_search_turtle, authority_search_turtle, topic_search_turtle]
│   └── Role: Parliamentary data collection via MCP tools
│
├── ProvenanceAgent(BaseAgent) 
│   ├── Custom Implementation: Video source enrichment
│   └── Role: Enrich entities with YouTube timestamps & transcripts
│
└── WriterAgent(LlmAgent)
    ├── Dynamic Instruction: Receives enriched turtle data
    └── Role: Synthesize findings into cited responses

Initially, we designed a classic multi-agent system using a SequentialAgent. The idea was to have a clear separation of concerns:

ConversationalAgent: The main entry point.
ResearchPipeline (SequentialAgent):
- ResearcherAgent: Collects data from our knowledge graph.
- ProvenanceAgent: Enriches the data with video sources and timestamps.
- WriterAgent: Synthesizes the final response.

The Roadblock: Session State Management

We quickly hit a wall. We found that ctx.session.state was not being reliably shared between the agents in our SequentialAgent pipeline. The ResearcherAgent would fetch data, but by the time the flow reached the ProvenanceAgent or WriterAgent, the state was often empty or corrupted.

# What SHOULD have worked:
ctx.session.state["turtle_results"] = raw_turtle_data  # ResearcherAgent
enriched_turtle = ctx.session.state.get("turtle_results", [])  # ProvenanceAgent ❌

# What we encountered:
# - Session state not reliably shared between agents in SequentialAgent
# - Context loss during agent handoffs  
# - Empty/corrupted state in downstream agents
# - Related to: https://github.com/google/adk-python/issues/1119

This appears to be a known challenge, which we tracked in GitHub Issue #1119. This roadblock became a critical learning moment: while the theory of multi-agent systems is powerful, the practical implementation can be fraught with state management complexities.

The Pivot: A Robust Single-Agent Solution

To solve this, we refactored our architecture into a single intelligent agent with a set of specialized function tools. This approach proved to be far more reliable and easier to debug.

The agent maintains context reliably, and the tools are called synchronously, ensuring data is passed correctly.

# Refactored Single-Agent Solution
self.agent = LlmAgent(
    name="YuhHearDem",
    model="gemini-2.5-flash-preview-05-20",
    planner=BuiltInPlanner(),
    tools=[
        FunctionTool(search_parliament_hybrid), # Was: ResearcherAgent
        FunctionTool(clear_session_graph),      # Memory management
        FunctionTool(get_session_graph_stats),  # Session insights
        FunctionTool(visualize_knowledge_graph) # Was: Custom visualization
    ]
)

This pragmatic pivot allowed us to achieve our desired modularity—with each tool handling a specific task—without the overhead and unreliability of inter-agent state management.

The User Experience: Making AI Accessible

Technology is only as good as its interface. Our focus on educational design was instrumental here. The frontend was built to make the agent's powerful capabilities accessible to everyone.

Key design principles included:

Progressive Disclosure: Information is presented in expandable cards, preventing cognitive overload. Users see a high-level summary first and can expand for details.
Visual Learning: We used D3.js to create interactive knowledge graphs, helping users visually understand the relationships between speakers, topics, and sessions.
Contextual Guidance: The agent uses the knowledge graph to generate relevant follow-up questions, guiding users on natural exploration paths.

Conclusion and What's Next

"Yuh Hear Dem" is more than just a technical demo; it's a functioning tool for enhancing democratic transparency. Our journey taught us several key lessons:

The Power of Hybrid RAG: Combining knowledge graphs and vector search provides superior retrieval accuracy.
ADK's Strengths: While multi-agent state sharing needs maturing, ADK’s single-agent with function tools model is incredibly robust for building complex, reliable AI systems.
Pragmatism Over Purity: A simpler, more reliable architecture is often better than a theoretically "purer" but fragile one.
Human-Centered Design is Key: An intuitive UI, grounded in learning principles, is essential for making powerful AI accessible and useful.

We invite you to explore the project yourself.

Live Site: https://yuhheardem.com
Git Repo: https://github.com/KatieM00/YuhHearDem
Hackathon Submission: https://devpost.com/software/yuh-hear-dem-adk

Our next steps involve expanding the data sources to include official legislative documents and exploring a return to a multi-agent architecture as the ADK framework evolves. For now, we're proud to have built a tool that helps citizens hear what really matters.

Lift as You Climb

Matt Hamilton — Tue, 26 Jul 2022 17:34:14 +0000

It was Sunday the 7th of June 2020. The first wave of the Covid-19 pandemic had hit and everywhere was in strict lockdown. I can't remember the exact specifics, but I think I was probably sat on the couch in my house in the UK at the time, perusing Twitter on my phone. I stumbled across a tweet from a Developer Advocate at Microsoft, Brandon. I'm not sure I was even following him at the time, but it was probably retweeted by someone I was following.

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

I went upstairs to my “home office” that I had set up in the spare bedroom. I had started a new role as a Developer Advocate at IBM a few months prior. I'd only visited the office in London once, just before the lockdowns came into effect. As a team whose main role was in-person meetups and events in the UK, we were trying to re-orient ourselves to producing online content. As a part of that, I had recently started Twitch streaming myself. I'd not used Twitch before, but become aware of it via some other colleagues at IBM that were using it for live-coding and education. I loved the idea (and it terrified me!) that you could just broadcast yourself coding and other people might drop in the chat to keep you company, offer assistance, chat nonsense, etc.

Anyway, I joined PJ's channel and he was there learning the very basics of, I think, HTML at the time. Maybe C#. Brandon was there too assisting him. I think there was no more than 3-4 people in the chat. But it felt great to be able to help someone start learning the basics. Every so often PJ would divert into something about literature (he was an English teacher after all) and talk about some paragraph of a book, or some poet I'd never heard of. But it was enjoyable. Listening to his passion about literature, and trying to channel that into learning something new.

I started following PJ on Twitter, as well as Brandon and another Developer Advocate friend of theirs Chloe. Together they created a bunch of silly little bots on Twitter, e.g. the Shania bot ("Let's go girls!"). A bot that begged Mountain Dew for sponsorship (at least I think that one was a bot). Chloe was also from a non-programming background, having originally come from theatre arts and stage school into DevRel. They did some fantastically entertaining shows online and started a Podcast called 8-bits.

PJ eventually managed to get a role in DevRel and is now an Education evangelist at Gitlab.

This is all great Matt, but so what?

It is just over two years since that tweet at the top, and stumbling across PJ and his journey into DevRel, and Chloe and her journey from theatre arts to DevRel.

A few days ago I was interviewing for a company for a senior developer relations role. I had four different interviews, covering different aspects such as my technical knowledge or my thoughts on developer advocacy, building and leading teams, etc.

One specific question I was asked in the last interview was:

"Do you think a developer advocate needs to have a software development / technical background?".

And some neurons somewhere in the recesses of my brain fired and I remembered PJ, and Chloe and their origins in high school english teaching and stage acting.

"No." I replied. And I went on to explain that the most important aspect, in my view, for developer relations is the ability to relate to and empathise with developers. Yes, of course, one of the most obvious ways is to have a development or technical background yourself. But actually, those coming into tech from other backgrounds are learning themselves. They have very fresh experience of having to learn the new terminology, functionality, etc of a product and explain it to others. They bring different skills, and different experiences to the table.

I remember myself when I first started learning AI and machine learning. Whilst I was a developer, I had no experience yet in machine learning. "Is that a regression problem or a classification problem?". I had no idea. I didn't even understand the terminology to describe what I was trying to learn. What is a tensor? What is a logit? So when I moved into doing DevRel for machine learning, I was able to think "What would I like to have known when I started in machine learning that would have made it easier for me?".

Another question I was asked in the interview:

"Can you give an example of where you have helped another developer progress?"

Again, I remembered another event that came from a random encounter. We were running an internal hackathon at Ripple, and a developer, Ami, from a different part of the company, that I'd never come across presented a fantastic hackathon project they were working on. I had recently been accepted as a speaker at Python Web Conference 2022, and the topic I was going to speak on aligned very much with what Ami developed in the hackathon. I approached Ami after the hackathon, and asked if she would like to co-present a talk with me at the conference. She was a fantastic developer, but I could see she would make a really good developer advocate as well. She had never spoken at a conference before, but agreed to do so. I contacted the conference organisers and let them know I'd now be co-presenting with a colleague.

The talk went fantastically! I talked about the general topic, and Ami gave a live-coding demo. A pretty amazing feat for someone's first conference talk!

Around that time I left Ripple, but Ami wanted to stay in touch and asked me to be her mentor. I was honoured, and glad to be able to help in any way I could. I hope one day she makes the move full-time into DevRel!

So this brings me back to the title of this post, "Lift as you climb". This was a saying I first heard from another developer advocate, Cassidy Williams. As you learn and progress, help bring others along with you too. In that post she talks about the importance of communities and mentorship:

“I wouldn’t be where I am today if it wasn’t for the community around me,” Cassidy points out. “You can do pretty well on your own in tech but you can really succeed if you have a community that you help that then helps you in return.”

And so I'd like to take this time to thank all those random people I've interacted with over the years that have got me to where I am now. Many of you may not have even realised how you have helped.

Oh... and I got the job! ;)

Header Photo by Sylvain Mauroux on Unsplash

XRPL Grants Wave 3 Theme: Contributing to Open Source

Matt Hamilton — Fri, 04 Mar 2022 15:34:47 +0000

Applications for Wave 3 are now open!

The official theme for this wave is “Contributing to Open Source.” The Program aims to support the independent, open-source ecosystem development around the XRP Ledger (XRPL). Making “Contributing to Open Source” the focus area of Wave 3 encourages projects that not only expand and enhance the resources available for XRPL developers, but that also continue to grow and strengthen the XRPL community. Types of projects may include:

Creating and open-sourcing a new project
Contributing to an existing open-source project
Adding XRP or XRP Ledger support to a project
Integrating the XRP Ledger with existing APIs, SDKs, and technologies that simplify deployment and integration
Building libraries for the XRP Ledger
Opening PRs for other projects to support the XRP Ledger

Projects applications for Wave 3 will be accepted form March 4 - 28, 2022, and applicants can view and submit their applications online. For all information about applying visit www.xrplgrants.org.

Wave 3 Timeline

Applications Open: March 4 - 28, 2022
Finalist Interviews: May/June 2022
Grantees Announced: July 2022

All applications for Wave 3 will be carefully reviewed by an expert panel of judges from respected institutions and companies from around the world. Select project teams will then be invited to participate and present in a 30-minute interview with members of the grants team and the judging committee.

Since the XRPL Grants program launched in May 2021, more than 50 projects have been funded internationally. View all the awarded projects.

Join a Live Q&A

We invite anyone interested in learning more about applying for an XRPL Grant to attend our official Q&A on the RippleXDev Twitch channel on Tuesday, March 15, 2022 at 11 AM PT (18:00 UTC).

Have more questions about applying?

Answers to commonly asked questions are available on the FAQ page. The XRPL Developers Discord is also a great place to connect with the community, including past funding recipients.

Debunking the Myths — What Is XRPL

Matt Hamilton — Thu, 16 Sep 2021 17:09:35 +0000

Facts & Fiction: Debunking XRP Ledger Misconceptions

As someone who’s been deeply ingrained in the software development community for 20 years, I’ve come to realize that misinformation propels hearsay unlike anything else. There are a number of falsehoods circling the XRP Ledger (XRPL) that I encounter on a regular basis including the misconception that it’s centralized, that there are hidden fees, that it’s private and used only by banks — and it's time to set the record straight. If you’re a developer interested in building on the XRP Ledger, or you simply want to learn more about the network, keep reading. I’m breaking down the facts and debunking the biggest misconceptions about XRPL.

MYTH: The XRP Ledger is Centralized. Based on my experience as a developer and my conversations with fellow devs, this is perhaps the most rampant falsehood — and here’s why. In a centralized blockchain, a single authority governs the entire network, controls validation, controls updates to the ledger, and creates a single point of failure (which theoretically leaves the entire network vulnerable to an attack).

TRUTH: The XRP Ledger is Decentralized. The XRPL delivers powerful utility to developers on a public, decentralized blockchain. Validation occurs via a consensus process where independent nodes are managed by a wide range of participants — not by a singular controlling entity. Amendments to the XRPL can be proposed by any participant and require 80% quorum approval for two consecutive weeks by the validator community. And once confirmed, transactions cannot be reversed or altered.

These are all hallmarks of decentralized ledgers. If there’s one takeaway I want you to remember, it’s this: Ripple is a contributor to the network, but only one contributor among many. As of writing, Ripple run around 5% of the approximately 900 nodes on the XRP Ledger, and six of the approximately 150 validator nodes. Ripple follows the same protocols and its rights are the same as those of any other contributor.

Final Myths to Debunk

MYTH: New XRP Can Be Added to the Ledger. According to this myth, a single authority can make unilateral changes to the fundamental, underlying code, which leaves the Ledger open to hackers who could create new XRP.

TRUTH: Even if a bad actor attempted to add unauthorized XRP to the Ledger, the consensus protocol ensures no single authority can execute on this. More than 66 million ledgers have been successfully closed since the XRP Ledger was first conceived with 100 billion XRP created at the inception of the Ledger, and no additional XRP has ever been added into the system.

MYTH: XRPL Has Hidden Fees. Fees, including transaction costs and reserve fees are returned to Ripple after being implemented into the Ledger, or rewarded to validators after being implemented into the XRP Ledger.

TRUTH: Just like other public blockchains, transaction fees are applied on the XRP Ledger, although they are far lower than most (just fractions of a cent on XRPL). Unlike other blockchains, however, the fee is neither returned to a central authority or paid as a reward to validators or any other party. It is, in fact, irreversibly destroyed. Because fees rise in-step with the load on the network, this protects the network from spam, malicious behavior and DDoS attacks. Furthermore, XRP transactions on the Ledger are settled almost instantaneously (only 3-5 seconds to confirm completion vs. 10+ minutes for other blockchains, or multiple days for banks to send cross-border fiat funds to other banks). The XRPL consensus protocol bridges the gap, saving substantial time and transaction costs.

MYTH: Blockchains Can’t Be Decentralized, Scalable and Secure. Improvement in one of these aspects must negatively impact one of the other two. We must sacrifice one to optimize the others, right? Not so fast–here’s the truth.

TRUTH: The Blockchain Trilemma is a model to conceptualize the challenges that all blockchains face, stating that the platforms cannot be truly decentralized, scalable and secure all at once. The truth is, the XRP Ledger was the first and is one of only a few blockchains able to run a decentralized, on-chain, limit order book exchange in near real-time. It can sustain a maximum throughput of up to 1,500 transactions per second (scalable), is managed by a range of diverse participants who collectively confirm transactions and approve proposed amendments (decentralized) and utilizes consensus protocol that protects against attacks and failure modes (security). And XRPL does all this in a very sustainable way. In fact it is the world’s first major, global, carbon-neutral blockchain.

In Conclusion…

Developers need to find the best blockchain for their project requirements. Any misunderstanding around how the tech works hinders that process.

By diving into the nuts and bolts of how the XRPL operates, we’ve been able to debunk several myths and misconceptions about the ledger as well as review some of the advantages that make it ideal for a wide variety of projects. Hopefully, this overview will help you to look beyond the unfounded myths circulating about the XRPL to discover another viable tool for your needs.

For more information, head to XRPL.org, where you can find plenty of background information, documentation, updates on ongoing projects and an extensive FAQ.

Any other misconceptions you’ve seen that I didn’t address? Let us know in the comments right here.

A Vision for Federated Sidechains on the XRP Ledger

Matt Hamilton — Mon, 07 Jun 2021 19:38:55 +0000

Today, RippleX is rolling out a community page on DEV aimed at engaging the growing XRP Ledger Community.

Our inaugural post was written by David Schwartz, CTO at Ripple and one of the original architects of the XRP Ledger, and introduces his vision for Federated Sidechains.

Developers around the world are invited to share ideas, provide feedback, ask questions and join the discussion. Together, we look forward to building trust and utility for the XRP Ledger.

Over the last nine years, the XRP community has been committed to advancing the innovation and forward progress of the XRP Ledger (XRPL) to dramatically increase its decentralization, performance, and feature set.

Among the most-requested features we have heard from developers and contributors to the XRP Ledger is smart contract capabilities brought about by the exponential growth in decentralized finance (DeFi). In fact, the number of DeFi developers has grown 110% since 2019, and that number is projected to grow well beyond 2021. However, we at Ripple have long advocated against features that would compromise the XRP Ledger's highly efficient focus on payments.

Today, we are proposing a strategy that enables the best of both worlds: Federated Sidechains for the XRP Ledger. This will enable developers to implement new features, such as native smart contracts that interoperate seamlessly with XRP and the XRP Ledger, while also allowing the XRP Ledger to maintain its existing, "lean and efficient" feature set.

Federated Sidechains allow for experimentation and specialization, so developers can enjoy the power of the XRPL on a sidechain that acts as its own blockchain. For example, imagine the potential to branch out into new functionality by slimming down the XRPL's features to a specific subset for a particular use case—or even creating a private, parallel network for a permissioned blockchain. Federated Sidechains could very well make this a reality.

How It Works

In order to understand the vision for Federated Sidechains, it is first important to define a federator: a piece of software that connects to at least two instances of the XRPL software. The federator software means anyone who wanted to could run a sidechain to the XRP Ledger. On one side, the federator is connected to XRP Ledger Mainnet. On the other side, it connects to one or more sidechains. The federator would be run only by parties who operate validators on at least one sidechain.

The vision is that each sidechain would function as its own blockchain. They’d have their own ledger and transactions just as the XRP Ledger does. What makes them sidechains is the federation system which allows XRP and issued tokens to move from one chain to another.

Federated Sidechains could use XRP as their primary asset. In that case, people could use the federation system to move XRP from XRPL to the sidechain. Then, the moved XRP could be used on the sidechain just as it is on the main chain. Anyone could move XRP from either chain to the other.

Alternatively, sidechains could use their own native asset, so people with accounts on both ledgers could move XRP to and from the issued asset on the sidechain.

Functionality:

Federated assets imported onto XRPL itself would trade on the XRPL’s integrated decentralized exchange (DEX). XRP imported onto sidechains would be used for liquidity on their integrated DEX as well.

This strategy requires three things:

Building a new piece of software, or the “federator.”
Making two trivial changes to the operation of the live XRP Ledger network.
Adding new features to the XRPL server software to allow it to operate in a sidechain. However, these features would not be enabled on XRPL itself. (The current recommendation is to fork the XRPL software so that new versions of the sidechain software could come out without having to make new versions of the XRPL software and to reduce the risk of harming XRPL.)

Each sidechain would have a "trust" account on the XRPL Mainnet. This account can hold assets on the XRPL on behalf of users of the sidechain. The account would use a multisign or threshold key with the signers being the validators of the sidechain. Each sidechain validator operator registers a signing key that signs transactions on XRPL; thus, the validators of the sidechain can collectively create transactions to manage the sidechain's Mainnet account.

The XRP Ledger Mainnet has one native asset, XRP, and an unlimited number of issued tokens that can represent anything else but don't have the same status as XRP. It wouldn't make sense for each sidechain to start with a whole new set of 100 billion XRP, so instead, sidechains have two options for their native asset: either have a new native asset for the sidechain, or set aside some real XRP for use on the sidechain. If the sidechain uses XRP as its native asset, then the chain’s account on the Mainnet holds the sidechain's total amount of XRP "in trust" for use in the sidechain. If the sidechain creates a different native asset, that asset can be issued on XRPL Mainnet by the sidechain's Mainnet account.

The sidechain can hold other assets and tokens issued natively on the XRPL Mainnet; just like with XRP, the sidechain's Mainnet account holds the total amount in use on the sidechain. The ownership of that asset within the sidechain can change as a result of transactions and events in the sidechain that the XRPL Mainnet never needs to see. Whenever an asset—XRP or otherwise—needs to move "out of" the sidechain, the sidechain's Mainnet account sends that amount of XRP to its intended recipient on the Mainnet. This could even be another sidechain's account, allowing assets to cross from one sidechain through the Mainnet to any other sidechain. Conversely, to send funds "into" a sidechain, you would send funds to that sidechain's Mainnet account.

Someone who establishes a new sidechain should pick a set of initial validators and have them negotiate appropriate threshold or multi-signing keys. They would then create the sidechain’s XRPL Mainnet account and set it up so that only the sidechain validators' collective signing power can control that account. If the sidechain's validators change, then the Mainnet account should change its keys to match the new list of trusted validators. (Note: The XRP Ledger's native multi-signing lists are limited to 8 keys or fewer, but threshold keys can support as many signers as necessary for each of the sidechain's validators to be included).

Advantages

With this software, anyone can choose to run a sidechain to the XRP Ledger. For developers, it unlocks new use cases like native DeFi capabilities and smart contracts. Developers can also build and launch blockchain features that are “baked” into these sidechains; in the future, successful features could even be ported to the XRPL Mainnet.

The developers managing a sidechain also have the freedom to decide how their chains work. They would choose their own validators for their sidechain and could change the system’s rules as they need (with the cooperation of their sidechain's validators). For example, a sidechain could operate without transaction fees or reserve requirements, it could operate without its own copy of the XRP Ledger's decentralized exchange, or it could add new transaction types and functionality for storing large chunks of data on-ledger. The possibilities are limitless: a sidechain can be strictly permissioned or (nearly) permissionless, centralized or (mostly) decentralized. You could even run a sidechain temporarily while letting it manage real value and gracefully shut it down after it has served its purpose.

Immediate advantages of Federated Sidechains for developers include:

Horizontal scaling: Sidechains can have their own fee system, their own reserve system, and their own transaction capacity. Someone who wants to create a system with thousands of users that can hold XRP has a better option than being the custodian or putting all the accounts on XRPL directly.

Low risk: The XRP Ledger doesn't need to change at all. Even the changes that would be helpful are quite minimal.

Low effort: Anyone who needs or wants to experiment with a blockchain can get started with a complete system ready out of the box, based on powerful, stable, and sustainable XRP Ledger technology.

Long roadmap: New features can be added over a long period of time-based on feedback on what people find interesting. This would be a continuous stream of new features and capabilities.

Changes to the XRP Ledger

Succeeding in this vision requires a few changes to the XRPL software that wouldn’t be used on XRPL itself in order to support the sidechain features. The primary change to the software would be to support the unique node list (UNL) being stored in the ledger. Pseudo-transactions to change the UNL would be needed. A “hint” UNL would need to be supported to avoid the chicken and egg problem of needing the UNL to get the ledger and the ledger to get the UNL.

Support for the coordination of creating threshold and/or multisign keys and signing XRPL transactions introduced by the federator is also necessary. Some API enhancements would likely be needed to handle pseudo-transactions introduced by the federator or federator-federator communication through the peer network.

The XRP Ledger mainnet could also use a flag to indicate whether an issued asset was permitted to federate or not. Some asset issuers, for example, might insist that all holders of their assets be directly represented on the main chain for regulatory purposes while others could allow their assets to freely trade on sidechains. (It's always possible to privately allocate some of your own resources to others, with or without a sidechain to automate the process, but the legal responsibilities of doing so can vary based on jurisdiction and circumstances.)

Sidechains would have a special entry in their ledgers that tracks the last sidechain transaction that has been executed on the main chain and the last main chain transaction that has been executed on the sidechain.

When federators see a new transaction on the sidechain that affects the main chain, they coordinate the submission of that transaction to the main chain. When federators see a new transaction on the main chain that affects the sidechain, they coordinate the submission of that transaction to the main chain.

Making these changes is probably the biggest part of this effort because even though they won’t be enabled on XRPL, there is still risk associated with changing the software. For example, some existing code may need to be moved or adjusted which carries the risk of inadvertently changing behavior.

The outlined strategy is a starting point to gather feedback from the XRP Ledger community. We invite developers and contributors to the community to comment below. Let’s build a roadmap for innovative, new use cases together.

My Setup for Streaming Livecoding

Matt Hamilton — Fri, 18 Dec 2020 12:47:52 +0000

This is a video showcasing the setup I have for streaming live-coding sessions.

A 1080p version of this video is available here

In this video I cover three main areas:

What I want to achieve and why?

You've no doubt seen plenty of live-streamed videos with a screen capture taking up much of the screen and a small disconnected head in the bottom corner of the presenter talking away. My goal in this setup is to make my session much more engaging. One of the main advantages of streaming live-coding is the audience gets to not only see what you produce but how you go about it. What are your thought processes? What mistakes you make. How you go about solving a problem.

Also, as a developer presenting, I have to speak my mind out loud for the audience as I go along, and this helps me to reflect on my own understanding. Similar in fashion to "rubber duck" debugging.

In this setup, I try to achieve a much more engaging format by orienting the camera, the screen, and myself in such a way that my eye line follows the code. It is much more engaging for the audience that my eyes actually look towards the line of code I'm working on and talking about. It gives them a much better feeling of actually being there with me, looking over my shoulder as I'm coding.

I want to try and replicate a feeling a bit like the big transparent lightboards you see. These have a presenter behind a glass panel drawing on the panel with fluorescent markers and a camera on the other side. However, they require physically a lot of space and setup so not suitable to do in a home-office environment.

Physical Setup

I have my camera (Logitech c920) mounted at eye-level to the side of my monitor in such a way that the geometry of my eyes, the screen, and the camera produce the effect that I am looking sideways slightly, towards the code.

I have some home-made light panels that I use and have a pipe-frame on my desk that my monitor, lights, and cameras are all mounted to. This idea was taken from another developer advocate, Cassie. This means that I can raise my sit-stand desk to standing and everything goes up with it and is still at eye level.

I have an external USB microphone (AKG Perception 120) mounted on an arm that I can position just out of shot.

OBS Setup

I use OBS - Open Broadcaster Software to do my streaming. It allows you to create scenes with multiple input sources, such as screen capture and webcam feeds.

I have two monitors, the built-in screen on my Macbook and an external 1080p monitor above it. I arrange my screens such that what I am presenting (a terminal, a web browser, slides, etc) are all arranged on the lower screen and each full screen on a separate space. I can then use four fingers to swipe on the touchpad to move between them.

I have OBS and anything I don't want the audience to see on the top screen. So that includes my Slack workspaces, email, the Twitch channel management page, etc.

When presenting I am looking at the top screen, at the OBS preview which means my head is up and I'm not just looking down with the audience just seeing the top of my head. It also means I see the preview of the effect of myself behind the code when I point at the code, which means I can accurately look and point at the parts I'm talking about.

Anyway, enjoy the video and I hope it gives you some ideas on making your streaming more engaging.

Issuing Assets on the XRP Ledger for Ethereum Developers

Matt Hamilton — Tue, 08 Dec 2020 21:36:46 +0000

For many people, when they think of issuing tokens on a cryptocurrency blockchain, or representing a fiat currency as a stable coin, the first thing that comes to mind is Ethereum. Ethereum is a global, open-source platform for decentralized applications. It has been used for issuing tokens for ICOs; for stablecoins, such as USDT; and even other cryptocurrencies, such as wrapped BTC.

But many people might not be so aware that there is a blockchain that was created pretty much for this exact purpose and does it extremely well – the XRP Ledger. Many people may be aware of XRP, the native token of the XRP Ledger, but might not be so aware of the features the XRP Ledger offers for issuing currencies or that the XRP Ledger has a decentralized exchange built right in. This can offer a better solution to issuing currencies than using ERC-20 tokens.

But first, let's go back a bit and look at the history and origins of the XRP Ledger, as this will help you to understand some of the functionality and ethos behind it.

History

The development of the XRP Ledger was started in 2011, when three Bitcoin developers David Schwartz, Jed McCaleb, and Arthur Britto set about creating an alternative to Bitcoin. Their view was to create something more efficient than Bitcoin, and that focussed specifically on digital payments. The XRP Ledger launched in mid-2012 and later that year they went on to form a company, Ripple, along with Chris Larsen to further develop and their ideas. The full history of the XRP Ledger and Ripple the company subsequently formed by the developers is detailed on the XRP Ledger website.

The following year, a young Russian developer who was traveling the world, visited San Francisco and stayed with Ripple CTO Stefan Thomas for a few weeks. They spent time discussing the future of cryptocurrencies, and the concept of smart contracts. That developer? Vitalik Buterin.

Vitalik and Stefan took their ideas for smart contracts in radically different directions. Vitalik went on to create a completely new blockchain, Ethereum, in which smart contracts were implemented at layer 1 of the protocol as a core element of the blockchain, along with its own programming language (Solidity) and virtual machine to run the code on. Stefan went on to work on Codius, which was an off-chain smart contract system that could sit alongside the XRP Ledger, keeping the XRP Ledger simpler and enabling Codius to work with any programming language. Work on Codius was paused when it was realized that a cryptocurrency-agnostic way of paying smart contracts would be needed. Focus was shifted to Interledger, which amongst other things, allowed smart contracts to be paid by a variety of cryptocurrencies.

So now you know the history, what features of the XRP Ledger might you be interested in as an Ethereum developer? How do they compare? When would you use each one?

To illustrate this, I'm going to use the example of representing a commodity, coffee, in a tokenized form. We are going to imagine a token that represents 1kg of green (un-roasted) coffee beans. Let's look at some of the features of the XRP Ledger that may be of use for the use-case of issuing and trading an asset such as this on the XRP Ledger.

Issued Currencies (IOUs)

On Ethereum, if you wanted to represent an asset, such as a coffee token, then you would need to create an ERC-20 token to do so. This involves creating a smart contract, or adapting an existing one, to create your specific named token. The XRP Ledger was specifically designed to be able to handle multiple currencies, or assets as a core function. These are termed Issued Currencies or IOUs on the ledger. To issue a token, all we need to do is pick a currency code to use. For this example, I'm going to use XCF. The XRP Ledger support standard three-character codes intended for use with ISO 4217, or an extended non-standard code which is represented as a 160-bit hexadecimal string. For this example, to keep things simple I will use the former.

An advantage of this feature is that it is much simpler and easier to issue currencies on the XRP Ledger than it is on the Ethereum blockchain. Whilst you don't have the full power and flexibility of smart contracts to create complex custom financial instruments, it is less prone to accidental security issues. You are not using a general-purpose smart contract language just to issue a token, so there is less scope for error and less attack surface.

Trust Lines

Remember, Issued Currencies are sometimes called IOUs. That is because they represent an IOU for some currency, commodity, stock, bond, etc that is not able to be stored directly on the XRP Ledger. You cannot physically store actual coffee beans on a blockchain. So you represent that coffee in tokenized form as an IOU.

Transfers of these IOUs are accounted for on the ledger via a structure called a Trust Line and represent a liability from one side and an asset from another.

If I am a coffee seller and I issue my XCF token on the ledger, then the operation of me sending you 1000 XCF is recorded in the trust line between us as being a 1000 XCF asset to you and a 1000 XCF liability to me.

A trust line has a limit set that represents the maximum amount of an asset an issuer can owe you. As there is no way for a blockchain to enforce the physical settlement of the coffee, a trust line models explicitly the trust you are giving that issuer. If I send you 1000 XCF then you are trusting that I have 1000kg of coffee somewhere that you can redeem those tokens for from me at some later date. You can set the limit on the trust line to whatever you feel comfortable with based on how much you trust me.

One particularly important feature on the XRP Ledger from a compliance point of view is the ability for IOU issuers to 'freeze' the trust line. If, say, my coffee warehouse burned down, then from a regulatory point of view, I'd need to be able to prevent those IOUs for the coffee (that no longer physically exist) from being redeemed. You wouldn't want the holder of those 'bad' IOUs to be able to sell them on. An individual trust line to a holder can be frozen, or all trust lines for that IOU can be frozen globally. This feature can be disabled by an issuer if required. Note, that as this only operates on trust lines and IOUs, it cannot ever be used on XRP itself – XRP cannot be frozen by anyone as it is the native asset of the ledger, and not an IOU. Only the issuer of an IOU can freeze the trust line.

Decentralized Exchange

So, we have a token, XCF, that represents our coffee. How do we go about trading that token? How do you, as a buyer, buy 1000 XCF off me? The XRP Ledger has a built-in decentralized exchange. Due to the XRP Ledger using a deterministic consensus mechanism it was the first and is one of only a few blockchains able to run a decentralized, fair, on-chain, limit order book exchange in near real-time.

Offers to buy or sell XCF can be submitted to the XRP Ledger and will sit on the order books awaiting crossing offers to form a trade. Just like on a traditional, centralized, exchange you can create market or limit orders. You can specify additional options such as whether your order should be post-only or immediate fill-or-kill.

However, the DEX on the XRP Ledger has two particular features that really make it unique. Auto-bridging and Rippling.

Auto-bridging

Let's say in our example you want to buy 1000 XCF, but you want to pay with USD. You hold some USD IOUs that have been issued by someone else on the XRP Ledger (e.g. Bitstamp). So you place an offer on the DEX for 1000 XCF and you are willing to pay $2.25 per XCF. If there is a corresponding seller who has a matching offer to sell at least 1000 XCF for $2.25 then the trade will execute immediately.

But what if there is someone willing to buy USD for XRP and someone else willing to sell XCF for XRP? The XRP Ledger will auto-bridge those two offers and complete the trade in a single atomic operation. In fact, the XRP Ledger will path-find amongst all the order books to find the best price for you automatically from all the offers. So it could potentially be that you want to buy Coffee with USD, and the actual trade is USD -> XRP -> Coffee.

This feature, vastly increases the potential liquidity on the exchange, as you don't need to have the exact offers on the order books, if you have offers between your asset and XRP, then you have a common bridge asset rather than needing to place orders for every possible combination of assets/currencies.

This also applies to making payments on the XRP Ledger. You can say "I want to send a payment of 1000 XCF but I want to fund it with EUR" and the XRP Ledger will consult the DEX for you and make the appropriate trades automatically to deliver the value in the desired currency.

Rippling

Rippling is the process of moving debt obligations between entities. Much of this functionality was derived from the original RipplePay project that pre-dates Bitcoin or XRP. This can be used in two main ways:

If Alice owes Bob $20 and Alice owes Charlie $10, then Bob can pay Charlie by instructing Alice to pay Charlie from some of the money she owes Bob. This can be used to create a social credit system.

Imagine I am in a cafe and that cafe only accepts cash, and I want to buy a meal for $20, but only have a debit card on me. A third person, Carol, in the cafe wants to buy an iTunes voucher but has cash and no debit card to pay online. If this was represented on the XRP Ledger then: I would be able to use my debit card to buy Carol a $20 iTunes voucher online. In return she'd give me $20 cash. I then use that $20 cash to pay the cafe for my meal. This all works on the basis that $20 in value can be represented in various forms and by different 'issuers' e.g. the Federal Reserve (cash), Apple (iTunes voucher), Chase Bank (debit card). The debts can then be rippled between the different issuers.

More details of this strategy can be found at a great blog post by Richard Gendal Brown (where the above image was taken from)

The Future of the XRP Ledger

Like most technology in this space, the XRP Ledger and its uses are continually evolving. Two specific examples that might be of interest to Ethereum developers are:

Hooks

Hooks are an extension being built for the XRP Ledger by XRPL Labs that enable small snippets of code to run on any transaction. The code is written in any language that compiles down to WASM and executed on a WASM virtual machine on the blockchain. Hooks can accept or block transactions, keep internal state, or even emit new transactions. For example, a user can add a hook to their XRP Ledger account that donates 1% of every incoming payment to a charity. As hooks can keep state, they can also be used to receive data from oracles that can then be acted upon by other hooks.

Flare

Flare is an upcoming example of a hybrid of using the benefits of the speed, low latency, and scalability of XRP and the XRP Ledger with a smart contract blockchain that uses the Ethereum Virtual Machine. It would allow a bi-direction bridge between the Ethereum and XRP ecosystems.

Scalability and Fees

One of the main benefits of the XRP Ledger though is the scalability and low fees. Each transaction on the XRP Ledger deterministically settled in just 3-4 seconds, so you don't have to wait for a number of confirmations to be sure the transaction is final. Also, the fees are very low, usually just 12 drops (a drop is 1 millionth of an XRP). At the time of writing that is just 8 thousandths of a cent.

Hopefully, this post has highlighted some of the features built into the XRP Ledger that might be of interest to Ethereum developers when looking for ways to handle issuing currencies, commodities, and assets in a secure, efficient, and decentralized manner.

You can find out more about the XRP Ledger at XRPL.org. There is also a suite of higher-level APIs that also incorporate Interledger and PayID available at RippleX.io.

Why I Stream Live Coding on Twitch

Matt Hamilton — Tue, 17 Nov 2020 20:38:04 +0000

I was recently asked to present a talk at the IBM Technical Consulting Group (aka the Totally Cool Geeks) about live streaming technical sessions. This was part of the 2H2020 two-day event they had running. The section of the day I was speaking in was around the topic of social media and digital eminence. With permission of those involved, I have published the recording of the session above.

I broadcast a weekly show on the IBM Developer Twitch channel called "ML for Everyone" in which I try to give some real world examples of how to use machine learning and AI in projects. Much of the material I use for examples comes from open source projects, side projects, and hackathons that I'm involved in.

In the talk, I detail a little bit about my setup both in terms of hardware and software to produce the effect I use on my Twitch streams. I plan to blog in more detail the exact details of the setup in some more technical posts, but what I really wanted to touch on is "why?".

Why do I stream live coding sessions on Twitch? The goal of what I am doing as a Developer Advocate is to built a relationship and empathy with developers. It is my role to understand how our products and services work and how they fit into the wider world of cloud, AI, app modernisation, etc. from a developer point of view. As part of that, I need to both understand exactly the frustrations a developer is feeling, and also to inspire developers to build great things. I am to educate them on the tools available, both from IBM and the wider ecosystem.

How many times have you seen a demo of some API, service, software or library and it looks so easy – and yet you try it yourself and it doesn't work? The examples have been chosen to exactly fit the problem. The libraries have been pre-installed. That little tweak that is needed has already been done. The point of the live coding sessions I do is that they are exactly that – they are live. They are unrehearsed. You will see the mistakes I make. You will see me google basic stuff like where to import a library from that I use every day but can never remember.

Why?

Because we are human.

All developers suffer some form of imposter syndrome at some time. You only see the takes where it works. You only see the rehearsed presentations in which it all goes well. You don't see the bad bits. You don't see the mistakes. The head scratching. The development dead ends.

In the video, I reference an academic paper recently published: Towards Supporting Programming Education at Scale via Live Streaming by Yan Chen, Walter S. Lasecki, Tao Dong which interviewed a number of Twitch streamers and developers on their views on the process. The main overriding comment is that you get to "look over the shoulder" of someone and see exactly how they go about writing code. You get to see and hear their thought processes. You get to learn why they did what they did, why they wrote that line of code that way. You get to see the lines of code they deleted before they finished.

So the entire setup of my Twitch streaming is to try and connect with developers. To try and break the formal presentation style used so often in educational videos. To try and connect to them. And to that end, to be able to actually visually reach into the code and point to what I'm talking about.

The talk is about 10 minutes long, with another 5 of questions after.

What Role do You see Developer Advocacy having in Developer Happiness?

Matt Hamilton — Wed, 11 Nov 2020 13:29:04 +0000

A colleague of mine, Naiyarah, just pointed me towards a report was just published about the happiness of developers around the globe. It is a very comprehensive report and looks at various breakdowns of developers happiness.

Much of the initial part follows the World Happiness Report and talks of things like work/life balance, healthcare, safety, political stability, etc.

But the latter half of the report then dives deep into the lives of developers specifically and looks at autonomy, tooling, workplaces, etc.

It was interesting to see that the particular lump of world I happen to be on, the UK, has the highest rating of happiness with respect to online communities.

And that got me thinking... as a developer advocate, my job is to help developers to learn about, access, and utilise technology. To build community. To listen to developers and their experiences and feed that back to the product teams.

But what contributes to happiness? What things can developer advocates, or developer relations people do specifically to help improve developers happiness?

Comment below if you have any specific ideas.

Exploring Bias in Crime Data

Matt Hamilton — Fri, 23 Oct 2020 16:04:24 +0000

I was joined this week by my colleague Margriet Groenendijk to look through some crime data to do a bit of an exploration and see what we could see in the way of biases in the data.

A 1080p version of this video is on Cinnamon

This is the recording from my ML for Everyone show that broadcasts every Tuesday at 2pm UK time on the IBM Developer Twitch channel.

We didn't know really what we were looking for, but wanted to see if some of the commonly heard views of biases in policing were visible in the data. This is a hugely political and emotive area at the moment. So much so that IBM has just launched Call for Code for Racial Justice to encourage tech projects to combat racism.

The data we used was taken from the UK police open data website: https://data.police.uk/

Margriet has a python notebook that we were using for the session:

IBMDeveloperUK / Data-Science-Lunch-and-Learn

Resources for weekly Data Science Lunch & Learns

Every Monday: Data Science Lunch & Learn

Online at lunch time on Crowdcast

Content

Many of the events use a Jupyter notebook to go through example code. We will mainly use Watson Studio to run these, but you can run them on any platform. To follow along in Watson Studio sign up for a free IBM Cloud account and create a Watson Studio service as described in these instructions.

Upcoming events

You?

We are busy planning new events and creating new content and material. Suggestions on topics and speakers are always welcome! Let us know by creating an issue in this repo

Coming soon

Trusted AI - learn about fairness and explainability
Data exploration with Python - series using various datasets
Deep learning series

Past events

29th March 2021: Update on COVID data analysis

Presenter: Damiaan Zwietering - twitter
Find all…

View on GitHub

We were specifically looking at "Stop and Search" data reported by the police force in the area I live in, Avon and Somerset Police.

The first thing we immediately found is that the data in itself can sometimes be confusing. For example ethnicity is broken down both by 'self reported' and 'officer reported'. Which in and of itself could be significant.

There are many different ways this data could be interpreted. And we'd need a lot more knowledge of the specific terms in the reporting to be able to draw any rigorous conclusions. But we wanted still to see what we could see.

One specific area we chose was the 'outcomes' of a stop and search versus the officer reported race. ie. if you suspected a bias in policing you might expect to see a higher prevalence of stop and searches carried out for one race for stops in which no action was subsequently taken.

We found that if you are classed as Black or Asian that the probability of the outcome being no action was 25% versus 30% for white people stopped. Of course we have to be aware of correlation versus causation here as there could be two plausible explanations for these numbers:

That BAME people stopped are 'let off' with no action more often.
That police officers are more likely to stop a BAME person for no offence.

So this was just a very superficial look at the data, but hopefully shows how you can use python notebooks, and the pandas library to explore and visualise the data.

If you want to learn more, then please drop by the IBM Developer Europe Twitch stream on Tuesdays from 2-3pm UK time, or have a look at the Data Science Lunch and Learn series we run on the IBM Developer Europe Crowdcast channel.