Interoperability And The Open Web

Why Systems Must Talk To Each Other

Every decentralized system you have studied so far lives inside its own boundary. A blockchain agrees on its own ledger. A storage network keeps its own files. A DAO counts votes inside its own contracts. Useful applications need more than that. A lending contract needs a price from the outside world. A user wants to move value from one chain to another. A person on one social server wants to follow a friend on a different one.

Interoperability is the ability of independent systems to exchange data or value using shared rules. In week 1 you compared centralized and decentralized designs. A central platform solves interoperability by owning everything. Decentralized systems must solve it with open standards and careful trust choices.

This week covers four areas: oracles, cross-chain messaging, federated and relay-based social protocols, and local-first software. Each answers the same question in a different setting: how do independent parties cooperate without a single owner?

Oracles And The Oracle Problem

A smart contract can only read what is on its own chain. It cannot open a web page, ask a weather service, or check a stock price. An oracle is a service that brings outside data onto the chain so contracts can use it.

The oracle problem is the trust gap this creates. A blockchain protects its data with consensus from many nodes. If one server pushes a price onto the chain, the contract inherits the weakness of that one server. A wrong or manipulated number can drain a lending pool.

Designers narrow the gap in several ways. Decentralized oracle networks, such as Chainlink, collect data from many independent nodes and publish an aggregate, often the median, so that a few bad reporters cannot move the result. Some designs use prices from on-chain markets and average them over time to resist short manipulation. Others add dispute periods, where anyone may challenge a reported value by posting a bond, as optimistic oracles do. A fourth idea uses signed data from the source itself, so the contract verifies a signature from the original publisher.

When you design with an oracle, ask three questions. Who reports the data? What does it cost to make them lie? How long does the contract wait before acting on a value? These questions turn a vague worry into a concrete budget.

How An Oracle Feeds A Contract

1. Data source publishes
2. Several nodes read it
3. Nodes sign their reports
4. Reports are aggregated
5. Contract reads the result

Using many independent sources narrows, but does not remove, the oracle problem.

Cross-Chain Messaging

Many chains exist, each with its own users, assets, and applications. A cross-chain message lets a contract on chain A cause something on chain B, such as unlocking tokens or casting a vote. A bridge is a system that carries such messages, often together with assets.

The core difficulty is that chain B cannot directly see chain A. Someone must tell chain B what happened, and chain B must decide whether to believe it. The designs differ in who they trust. An external verifier set, where a group of signers attests to events on chain A, is simple but depends on that group. A light client approach runs a small verifier of chain A's consensus inside chain B, which relies on the cryptography and consensus of the source chain. Optimistic designs accept messages by default and allow watchers to prove fraud during a challenge window. Zero-knowledge designs, building on week 7, prove the source chain's state transition with a succinct proof.

Bridges have been frequent targets of large theft, often because a small signer group or a contract bug guarded very large sums. For a builder, a few habits help. Move only the value you need. Prefer designs with clear, public trust assumptions. Limit how much any one bridge can hold. Keep a plan for what happens if a bridge fails.

• External verifiers: fast, trust a signer group.
• Light clients: trust the source chain's own consensus.
• Optimistic bridges: trust watchers during a challenge window.
• Zero-knowledge bridges: trust a proof.

Federated Protocols: ActivityPub And Mastodon

Not all decentralization uses a blockchain. Federation is another model. Many independent servers, each run by a different person or group, speak a common protocol and exchange messages. Email works this way: a Gmail user can write to a user on any other email server.

ActivityPub is a web standard published by the W3C in 2018 for federated social networking. Each user has an actor with an inbox and an outbox. When Ana on one server posts a note, her server delivers it to the inboxes of her followers, even if they live on other servers. Mastodon is the best known software that uses ActivityPub, and the wider network of such servers is called the fediverse. Other projects, such as PeerTube for video and Pixelfed for photos, share the same protocol.

Federation gives choice. A user can pick a server whose moderation rules they like and move to another one later. It also has limits. Your account belongs to your server, so a server shutting down can cut you off unless you migrate. Moderation is local, which fits communities with different norms and makes global rules difficult. Identity is tied to the server name, which links back to week 6 and the question of who really owns an identity.

Nostr: Keys And Relays

Nostr, short for Notes and Other Stuff Transmitted by Relays, is a protocol that makes identity independent from servers. A user's identity is a key pair. The public key is the account. Everything the user publishes is an event, a small JSON object that includes the content, a timestamp, and a signature made with the private key.

Servers are called relays. They store events and pass them to clients that ask. Relays do not own accounts, so a user can publish to several relays at once, and if one relay drops them, their identity and followers remain. A client verifies the signature on every event it receives, so a relay cannot forge posts. It can, however, refuse to store or show some posts, which is why users choose several relays.

Compare the two models. ActivityPub ties identity to a server and gives each server strong moderation power. Nostr ties identity to a key and treats servers as simple pipes, which gives the user portability and puts the burden of key safety on the user. Neither is universally better, and builders pick the model that fits their community.

Local-First Software

Local-first software is a design approach described in 2019 by Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. The idea is that your data lives primarily on your own devices. The app works without a connection, and the network is used to sync copies between devices and collaborators, not to hold the only copy.

The authors list seven ideals: fast, multi-device, offline, collaborative, long lasting, private by default, and under the user's control. Meeting them all is hard, because two people may edit the same document while offline. The technical answer is often a CRDT, a conflict-free replicated data type. A CRDT is a data structure designed so that copies edited separately can be merged automatically into the same result, in any order. Libraries such as Automerge and Yjs offer this.

Local-first ideas fit the rest of this course. Data stays with its owner, as in the identity and storage weeks. Sync can run over peer-to-peer links from week 3. Encryption keeps relays and servers from reading content. For a community tool such as a shared calendar or notes app, a local-first design keeps it usable during outages and lets members leave with their data.

CRDT Merge

1. Two devices edit offline
2. Each keeps its own log
3. They exchange changes when online
4. A merge rule orders them the same way
5. Both reach the same state

No central server decides who wins.

Choosing An Approach

No single approach fits every project, so this table of questions helps. If the application needs trusted outside facts, use an oracle and budget the cost of lying. If it needs value to move between networks, pick a bridge with public assumptions and small limits. If it needs social features with moderation by community, consider federation. If it needs portable identity and simple servers, consider key-based relays. If it needs privacy and offline use, start local-first.

Open standards sit under all of these. A protocol with a public specification lets many teams build clients, which reduces dependence on a single company. When you evaluate a project, read the specification, count the independent implementations, and test whether you can leave with your data. Those three checks reveal how open a system really is.

• Read the specification.
• Count independent implementations.
• Test whether you can export and leave.

Choosing An Approach

Approach	Who you trust	Good fit
Oracle network	Data providers and quorum	Prices, weather
Bridge	Validators or light clients	Moving assets between chains
Federation	Your server operator	Social feeds
Nostr	Your key and relays	Portable identity and posts
Local-first	Your own device	Notes, documents

Every approach hides a trust choice somewhere. Find it first. Source: Course synthesis

Key Terms

Interoperability

The ability of independent systems to exchange data or value through shared rules.

Oracle

A service that brings outside data onto a blockchain for contracts to use.

Oracle problem

The trust gap created when a secure chain depends on data from outside sources.

Bridge

A system that carries messages or assets between blockchains.

Federation

A model where many independent servers exchange messages using a common protocol.

ActivityPub

A W3C standard for federated social networking that powers Mastodon.

Relay

A Nostr server that stores and forwards signed events without owning accounts.

Local-first software

Software that keeps primary data on the user's devices and syncs through the network.

CRDT

A data structure whose separately edited copies merge automatically into the same result.

Exercise: Sign And Verify A Nostr-Style Event

1. Install Python 3 and the cryptography library with pip install cryptography.
2. Generate an Ed25519 key pair. Note that real Nostr uses secp256k1 Schnorr signatures, and Ed25519 keeps this exercise simple.
3. Create a JSON event with fields pubkey (hex of your public key), created_at, kind set to 1, and content set to a short note.
4. Serialize the event with sorted keys, sign the bytes with your private key, and add the signature in hex as a field named sig.
5. Write a verify function that rebuilds the bytes without sig and checks the signature with the public key.
6. Change one letter in content and confirm verification fails. Write two sentences on why relays cannot forge posts.

Further Reading

• ActivityPub, W3C Recommendation, Christine Lemmer-Webber, Jessica Tallon, and others, W3C, 2018
• Local-first software: You own your data, in spite of the cloud, Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, Mark McGranaghan, Onward! 2019
• Nostr protocol specifications (NIPs), github.com/nostr-protocol/nips
• Chainlink documentation: data feeds and architecture, Chainlink Labs, docs.chain.link
• Designing Data-Intensive Applications (chapter on replication), Martin Kleppmann, O'Reilly, 2017