←Blog
/
engineeringprotocolproptechopen-source

What if the MLS ran on AT Protocol? A proposal for a distributed, open real estate listings standard

The real estate industry's listing infrastructure is broken by design. AT Protocol, ActivityPub, and W3C open standards offer a path to something better — federated, agent-owned, and economically fair. Here's what that stack looks like.

What if the MLS ran on AT Protocol?

A proposal for a distributed, open real estate listings standard

The MLS — Multiple Listing Service — is one of the most valuable data networks in the world. In the United States alone, it powers trillions of dollars in annual real estate transactions. In Latin America, the equivalent infrastructure is a patchwork of private portals: Fincaraíz, Metrocuadrado, Properati, Inmuebles24. Each one is a walled garden. Each one charges agents to publish. Each one owns the data.

Nobody designed this to be extractive. It just ended up that way, because nobody designed it at all.

This post is a proposal — not a whitepaper, not a spec, but a working hypothesis I want to put in front of engineers and proptech builders who think about this problem. The core claim: the right substrate for a real estate listings network already exists. It's called AT Protocol, and it's designed for exactly this kind of federated, portable, high-stakes public data.

The problem with how listings work today

When a real estate agent in Bogotá lists an apartment on Fincaraíz, they upload photos, fill in fields (price, area, estrato, bathrooms), and publish. That listing now lives on Fincaraíz's servers. If the agent wants it on Metrocuadrado, they do it again. Ciencuadras? Again.

The data is not theirs anymore. The leads that come from it flow through the portal's systems. The portal decides what data to expose via API — if any. When the agent switches CRMs, they don't bring their listing history. When a portal changes its pricing model, the agent has no leverage.

This is not a Latin American problem. The US MLS system is older, more formalized, and in many ways worse — controlled by NAR, fragmented into 580+ regional silos, with data licensing rules that have historically blocked innovation. Zillow's entire ascent was built on fighting this structure (and partially losing to it).

The core failure is architectural: listings are treated as content assets owned by the platform that hosts them, rather than as records in a shared public ledger that agents control.

This was already tried. It failed for the wrong reasons.

In 2013, two developers in Vancouver — Kyle Campbell and Joshua Lopour — founded a startup called Retsly. Their premise was simple and correct: the MLS ecosystem in the US had over 900 regional systems, each using different software, different field names, different data formats. Integrating with even a fraction of them was consuming entire engineering teams. Zurple, a real estate tech company, reported that four years into operations they had only connected to 130 of the 900+ MLS boards — and were still spending a full engineering quarter per year just maintaining those connections.

Retsly built the normalization layer. A single RESTful API on top of the MLS chaos. Feed it your MLS credentials; get back clean, consistent data. They also included an open-source SDK and, critically, a compliance management layer so that per-MLS data licensing rules were handled by the platform rather than by each developer downstream. The goal was explicit: let a thousand real estate apps bloom without each one re-solving the integration problem from scratch.

It worked well enough that Zillow acquired them in July 2014 — just 13 months after founding, with only $540K raised. Zillow's CEO Spencer Rascoff framed the deal as enabling developers to build "software that works across MLS boundaries and without the overhead of dealing with local data formats." The real estate developer community was cautiously optimistic. Here was a well-funded platform willing to commoditize the MLS integration layer.

That optimism was misplaced. Over the following two years, Retsly was absorbed into Zillow's internal ecosystem, used primarily to power Zillow's own Tech Connect partner program. In 2017, Zillow merged Retsly with Bridge Interactive (another MLS tooling acquisition) under the Bridge Interactive brand. The open-developer promise quietly narrowed into a B2B offering for MLSs and large brokers already deep in Zillow's orbit. By 2018, when Zillow acquired Bridge Interactive outright, the Retsly API was a footnote in a press release.

The lesson isn't that Retsly was a bad idea. It's that a normalization layer built on top of proprietary data is only as open as its owner allows it to be. Retsly didn't own the MLS data. The 900+ MLS boards could revoke access at will. Zillow had every incentive to use the technology to deepen platform lock-in rather than genuinely open the ecosystem. The structural problem was never the API. It was the ownership model underneath it — which is exactly why a protocol-level solution, one where data ownership is inverted from the start, is different in kind, not just degree.

What AT Protocol gets right

AT Protocol (the protocol underlying Bluesky) was designed to solve a structurally similar problem in social networking: how do you build a network where users own their data, can move between hosts, and still interact with everyone else?

The key primitives are four. DIDs (Decentralized Identifiers): every actor has a globally unique, self-sovereign identifier that isn't tied to any specific host — your identity travels with you. Lexicons: a schema definition system that describes the shape of records; the schema is public, versioned, and extensible. Personal Data Servers (PDS): your data lives in a repo you control, hosted by a PDS of your choice — when you move hosts, your data moves with you. The Firehose: the AppView layer can index the entire network by subscribing to a stream of events, enabling search and feeds without querying every PDS directly.

Now read those four primitives again, but replace "social post" with "property listing."

A sketch of re.estate.listing

Here's what a Lexicon for a real estate listing record might look like:

{
  "lexicon": 1,
  "id": "re.estate.listing",
  "defs": {
    "main": {
      "type": "record",
      "description": "A real estate listing published by a licensed agent or agency.",
      "key": "tid",
      "record": {
        "type": "object",
        "required": ["propertyType", "offerType", "price", "currency", "area", "location", "publishedAt"],
        "properties": {
          "propertyType": {
            "type": "string",
            "knownValues": ["apartment", "house", "office", "warehouse", "lot", "commercial"]
          },
          "offerType": {
            "type": "string",
            "knownValues": ["sale", "rent"]
          },
          "price": { "type": "integer" },
          "currency": { "type": "string" },
          "area": {
            "type": "object",
            "properties": {
              "built": { "type": "number" },
              "private": { "type": "number" },
              "total": { "type": "number" },
              "unit": { "type": "string", "knownValues": ["m2", "ft2"] }
            }
          },
          "bedrooms": { "type": "integer" },
          "bathrooms": { "type": "number" },
          "location": {
            "type": "object",
            "properties": {
              "country": { "type": "string" },
              "city": { "type": "string" },
              "neighborhood": { "type": "string" },
              "lat": { "type": "number" },
              "lng": { "type": "number" }
            }
          },
          "photos": {
            "type": "array",
            "items": { "type": "blob" }
          },
          "description": { "type": "string", "maxLength": 2000 },
          "status": {
            "type": "string",
            "knownValues": ["available", "reserved", "sold", "rented"]
          },
          "publishedAt": { "type": "string", "format": "datetime" },
          "expiresAt": { "type": "string", "format": "datetime" },
          "agent": { "type": "ref", "ref": "re.estate.agent" },
          "extensions": {
            "type": "object",
            "description": "Market-specific extensions. Not part of the core schema."
          }
        }
      }
    }
  }
}

The extensions field is where Colombia-specific data goes: estrato, matrícula inmobiliaria, adminFee, VIS. Mexico gets its own. Spain gets its own. The core record is portable; the extensions are opt-in. An agent publishes this record to their PDS. Their DID is the identifier. The record gets a TID (timestamp-based ID) that makes it globally unique and cryptographically tied to their repo. That's the listing. It belongs to the agent. Forever.

The incumbent standard: Schema.org JSON-LD

Before arguing for something new, it's worth being honest about what already exists. Schema.org — the vocabulary maintained by Google, Microsoft, Yahoo, and Yandex — defines a RealEstateListing type. It's been there since 2020 and is the closest thing we have to a shared semantic standard for property listings on the web.

Here's what a well-formed Schema.org listing looks like in practice:

{
  "@context": "https://schema.org",
  "@type": "RealEstateListing",
  "name": "Apartamento en El Poblado — 3 habitaciones",
  "description": "Apartamento de 85m² en El Poblado, Medellín. Estrato 5, 3 habitaciones, 2 baños, parqueadero cubierto.",
  "url": "https://miinmobiliaria.com/inmuebles/el-poblado-apto-3hab",
  "datePosted": "2026-04-14",
  "offers": {
    "@type": "Offer",
    "price": 1850000,
    "priceCurrency": "COP",
    "availability": "https://schema.org/InStock",
    "businessFunction": "https://purl.org/goodrelations/v1#LeaseOut"
  },
  "about": {
    "@type": "Apartment",
    "floorSize": { "@type": "QuantitativeValue", "value": 85, "unitCode": "MTK" },
    "numberOfRooms": 3,
    "numberOfBathroomsTotal": 2,
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "Calle 10 #43E-50",
      "addressLocality": "Medellín",
      "addressRegion": "Antioquia",
      "addressCountry": "CO"
    },
    "geo": { "@type": "GeoCoordinates", "latitude": 6.2099, "longitude": -75.5642 }
  },
  "author": {
    "@type": "RealEstateAgent",
    "name": "Juliana Torres",
    "url": "https://miinmobiliaria.com/agentes/juliana-torres"
  }
}

Readable. Google understands it. This is exactly what ver.me generates for every property page on ver.casa — and it's the right call for SEO. But look closely at the Schema.org RealEstateListing type definition: it has exactly two native properties — datePosted and leaseLength. Everything else is inherited from parent types: WebPage, CreativeWork, Thing. The actual housing-specific data lives in a nested Apartment object linked via about.

This is not a design flaw — Schema.org is doing exactly what it was built to do: annotate web pages for search engine crawlers. The inheritance from WebPage is intentional. A RealEstateListing is a webpage; it exists to describe a URL. That assumption is precisely the problem for a distributed network.

In Schema.org, the listing's identity is its URL — change the URL and the listing vanishes, its history gone, its connection to the agent severed. In AT Protocol, the identity is a DID. The URL is a view of the record, not the record itself. Any portal, AppView, or CRM can render a different URL pointing to the same underlying data.

The key insight is that these two standards aren't in competition. They solve different layers of the same problem. AT Protocol serves as the canonical record layer — source of truth, owned by the agent, indexed by any AppView. Schema.org serves as the presentation annotation layer — generated automatically from the AT Protocol record when a web page is rendered, for Google and AI crawlers. When a portal renders a property page from the firehose, it embeds the JSON-LD in the <head>. Google gets its structured data. The agent keeps their data sovereignty. The portal is a renderer, not an owner.

Where ActivityPub fits

AT Protocol and ActivityPub (the protocol underlying Mastodon, Pixelfed, PeerTube) solve related but different problems. AT Protocol is optimized for global discoverability — the firehose model means any AppView can efficiently crawl the entire network; it's designed for millions of actors and billions of records. ActivityPub is optimized for push and federation — when you post on Mastodon, your followers receive your content; the actor model (Inbox/Outbox) is designed for bilateral and community relationships.

I wrote a TIL on ActivityPub back in 2022 that ended with exactly this intuition: the MLS's RETS standard, and any successor to it, could benefit from this kind of protocol. This post is the longer argument for why that intuition holds.

For a real estate listings network, you want both. AT Protocol is the database — listings live in agents' repos, indexed by portals and CRMs, globally discoverable. ActivityPub is the message bus — when a listing changes status, interested parties (buyers who saved it, agents co-brokering it, portals that syndicated it) receive an event via their Inbox. A portal like Fincaraíz, in this model, becomes an AppView — a curated index over the firehose. They still provide value: ranking, search UX, featured placements, local market context. But they don't own the underlying data. They're readers, not landlords.

The elephant in the room: this is all about the transaction fee

Let's stop pretending the MLS is primarily an information system.

It isn't. It's a commission-splitting coordination mechanism with a data layer bolted on top. The original MLS — invented in the late 19th century by US real estate boards — was not created to help buyers find homes. It was created so that listing agents could make a credible promise to buyer's agents: bring me a qualified buyer and close the deal, and I'll pay you half my commission. The database was the proof of that promise. The cooperation was the product. The listings were the means.

Every portal that came after inherited this structure, even when they didn't inherit the explicit commission fields. Fincaraíz doesn't split commissions — but it charges agents to publish and profits when an agent closes a deal that started on their platform. Zillow's Flex pricing model — where agents pay a referral fee only on closed transactions — is a direct attempt to capture the same value. The MLS logic is baked deep into the industry's economic DNA.

So here's the uncomfortable question for any distributed listing protocol: if you remove the platform's ownership of the listing, how does anyone get paid for making the match? This isn't rhetorical. It's the reason the Retsly experiment failed — and why nearly every open real estate standard has struggled to gain durable traction. Someone has to fund the infrastructure, verify agents, moderate fraud, and maintain the firehose. In the current model, that someone is the portal, funded by listing fees and lead gen commissions. Remove the data moat, and you have to answer what replaces it.

In August 2024, the NAR settlement forced one of the most significant structural changes to US real estate in decades. Sellers are no longer automatically responsible for paying both agents' commissions, and buyer's broker compensation can no longer be advertised on the MLS — that negotiation must now take place outside it. The commission offer, the founding economic mechanism of the MLS, was stripped out of the listing record itself. And yet the MLS didn't collapse. Agents didn't stop cooperating. The system adapted because the underlying coordination value — I have a listing, you have a buyer, let's split the work — survived even when the specific on-platform mechanism was removed. Economic coordination doesn't require a centralized platform. It requires a medium through which terms can be expressed and enforced. The NAR settlement accidentally proved this.

There are three plausible models for embedding economics in a distributed protocol. The simplest keeps the protocol pure — compensation is negotiated bilaterally, off-protocol, between agents. This is already closer to how it works in Colombia, where there's no MLS-style commission-splitting standard, but informal handling means no transparency and no protection for either party. A more structured approach would extend the protocol with a re.estate.collaboration record — a co-broking offer published by the listing agent and delivered via ActivityPub's Inbox/Outbox to verified buyer agents in the same market, creating an auditable trail while staying permissioned. The most ambitious design adds a re.estate.transaction record published when a deal closes, signed by both agents, with compensation terms embedded — a public, immutable history of every transaction that makes the NAR commission cartel structurally impossible to recreate. It's also the hardest to build, requiring both agents on the protocol and integration with notarial systems.

Open questions remain: Who maintains the firehose infrastructure if not a portal extracting rent? Can ActivityPub's Inbox model handle compensation negotiation at scale without becoming a spam vector? If a transaction record is published to a public firehose, what data privacy obligations does it create under Ley 1581 (Colombia), LGPD (Brazil), or GDPR? These are the right questions — they're the design surface where the interesting work happens.

The open standards that already exist for this

The W3C and adjacent communities have been quietly building exactly the primitives needed to solve the economics problem. They just haven't been assembled into a real estate stack yet.

W3C Verifiable Credentials (VC 2.0, full Recommendation since May 2025) is the answer to the agent verification problem. A Verifiable Credential is a cryptographically signed claim — issued by a trusted authority, held by the agent, verifiable by anyone without calling the issuer's servers. In Colombia, the Superintendencia de Notariado y Registro could issue a RealEstateLicenseCredential to every registered agent's DID. Any AppView reading the firehose checks the credential — no labeler required, no manual whitelist, no portal gatekeeping. The VC travels with the agent when they switch CRMs and expires or revokes automatically when the license does. This is not speculative: VC 2.0 is in production today, including in the EU's digital identity infrastructure.

Interledger Protocol + Open Payments is the answer to the commission flow problem. Interledger is TCP/IP for money — a standard for routing payments across networks (COP bank → MXN digital wallet → USD escrow) without a central clearinghouse. Open Payments builds a REST API layer on top with grant-based conditional payments, where a seller can authorize a payment that only unlocks when a specific event is confirmed. If the AT Protocol re.estate.transaction record — signed by both agents — is the event, then commission release becomes a protocol-level trigger, not a bilateral trust problem.

Smart contract escrow is not a W3C standard, but it's the honest completion of the picture. An escrow contract holds the commission from the moment the listing agreement is signed. In civil law jurisdictions like Colombia, where property transfer requires a notarized escritura pública, the notary is already a trusted third party. A contract that releases funds on the notary's digital signature — expressed as a Verifiable Credential — is legally grounded, not a DeFi experiment. The practical blocker is that agents don't use crypto wallets. That's a UX problem, not a protocol problem, and it's solvable.

The gap between "decentralized listing protocol" and "decentralized transaction protocol" is smaller than it looks. The identity layer (DIDs), the trust layer (VCs), and the payment layer (Interledger/Open Payments) are all production-ready or close to it. What's missing is the Lexicon definitions, the credential schemas, and the AppView implementations that wire them together. None of that requires inventing new cryptography or convincing a standards body to act. The real question isn't whether the technology exists — it's whether anyone in proptech is paying attention to it.

What would it take to build an MVP?

Not as much as you might think. A minimal viable implementation needs five things: a re.estate.listing Lexicon (v0, opinionated, non-exhaustive) published at re.estate or an equivalent namespace and opened for community review; a reference PDS wrapper for agents, since most agents won't run their own PDS and need a hosted service with a simple publishing UI; a reference AppView — a minimal portal that indexes the firehose and renders listings, proving that portals can be built on top of the protocol; 50 early-adopter agents in one city (Bogotá, Medellín, Mexico City) to put real listings on the protocol and prove discoverability works; and a public firehose API so any developer can build on top of it.

The total engineering investment for the first three steps, with a focused team, is probably 8–12 weeks. The fourth step is the hard part. The fifth is the flywheel.

Why now

AT Protocol is past its experimental phase. Bluesky has demonstrated that the firehose model scales to millions of users and the Lexicon system is mature enough for production applications. The real estate industry is simultaneously in a moment of structural tension: the NAR's 2024 commission settlement broke a 50-year-old pricing cartel; Zillow's failed iBuying experiment proved that platforms trying to capture the transaction face brutal economics; and RESO (the Real Estate Standards Organization) has spent two decades trying to standardize MLS data with limited success, demonstrating that voluntary coordination inside the existing ownership model doesn't work.

The protocol primitives exist. The hard cryptography, the identity layer, the firehose infrastructure — none of it needs to be reinvented. What's missing is a Lexicon, a reference implementation, and an early community. Those are all things that can be built in public, in the open, starting now.

What I'm not claiming

This post is not a roadmap. It's not a pitch for funding. It's a hypothesis worth pressure-testing.

I'm not claiming AT Protocol is better than ActivityPub for all use cases — the right answer is probably both, for different layers. I'm not claiming this fully solves the trust problem. I'm not claiming existing portals will voluntarily participate — they won't, initially. I'm not claiming smart contract escrow is ready for Colombian real estate agents in 2026.

What I am claiming is that the technical substrate exists to build a real estate listings network that is more fair, more open, and more economically efficient than what we have today. The question is whether enough builders find this worth attempting.

If you're working on proptech in LATAM or thinking about federated protocols for high-stakes data, I'd like to talk. Find me at @julian.cantillo.dev on Bluesky, @juliancantillo on X, or via ver.me.

References

Standards and Specifications

Retsly and the Zillow Acquisition

  • "Zillow Acquires Retsly" — GeekWire, July 2014 — geekwire.com
  • "Zillow Acquires Retsly, A Service That Helps Developers Access Real Estate Listings" — TechCrunch, July 2014 — techcrunch.com
  • "Zillow's Retsly Acquisition No Threat to MLSs" — Inman, July 2014 — inman.com
  • "Bridge Interactive and Retsly Join Forces" — PR Newswire, January 2017 — prnewswire.com
  • Zillow Form 8-K, FY2014 — SEC EDGAR

NAR Commission Settlement

  • NAR Settlement FAQs — nar.realtor
  • "The Future of Realtor Commissions: Understanding the NAR Settlement" — APSLaw, December 2024 — apslaw.com
  • Summary of 2024 MLS Changes — nar.realtor

Further Reading

This post reflects personal technical opinion and ongoing research, not a product announcement. The Lexicon sketches above are illustrative, not normative.

←Volver al blog