Microsoft Publisher is gone — here's how to rescue your .pub files before your PC forgets them

DataRebelHQ — Fri, 16 Oct 2026 04:53:54 +0000

Microsoft Publisher is gone.
If you had it through Microsoft 365, access ended on or shortly after October 1, 2026, as the removal update rolled out. Support for the perpetual version ended October 13, 2026, when Office LTSC 2021 and Consumer Office 2021 reached end of support. Perpetual installs keep running, but they get no more security updates.
Your files are not deleted. That part matters, so I want to be clear about it: your .pub files are still on your computer. What died is the reader — the program that could open them.
I found that out the way a lot of people are finding it out now, looking at folders of old newsletters, flyers, and brochures that nothing on the machine will open properly any more.
The official escape hatch has a catch
Microsoft's own guidance was to convert files to PDF inside Publisher before the deadline (File → Save as → PDF), and Microsoft also offered a bulk path: a downloadable script, Convert-PubFileToPDF.ps1.
The catch is in the script's first step: it needs a working, licensed copy of Publisher installed.
So for Microsoft 365 users, the bulk tool dies with the access it was meant to outlive. It only serves perpetual owners while their installs last. If you already lost access, it cannot help you.
Microsoft says the same thing on its support page, in its own way: it points users to third-party conversion tools, with a caution that such services vary in quality and capabilities, and that Microsoft provides no support for them. In writing, the vendor is handing its stranded users to the third-party market.
The real risk isn't conversion. It's silent failure.
I've spent time actually measuring what happens when you convert .pub files with the open tools available, and the problem isn't that conversion fails loudly. It's that it can appear to succeed while dropping things.
In the measurements behind this post, one converter run exited successfully and produced no PDF at all for a truncated file. Another file was converted and reported fine, but the extracted text came out reordered and garbled — "Sp ot Bu the nnn y & E gg ns" — while looking converted. Graphics in other files exploded into hundreds of small image tiles inside the PDF: 501 images in a single one-page flyer in one case, 70 in another.
All five test files were reported as successes by a naive conversion. Not all five were actually complete.
That's the risk I care about. A church newsletter archive or a school flyer collection that "converts" with pages, text, or images quietly missing is worse than a file that fails openly, because you might delete the originals believing you're safe.
The free option, stated honestly
LibreOffice opens .pub files, and The Document Foundation has promoted that support as a rescue path. If you have one file, a working computer, and you're comfortable installing and running desktop software yourself, try that first. It's free.
Use it with your eyes open: layout can shift, especially on graphics- and WordArt-heavy files, and you still have to check the result page by page to be sure nothing was dropped. Free and real — but it's you doing the checking.
What I'm testing
I build small pay-per-call tools, and I'm testing whether there's a real need for this as a service:
Send a .pub file, get back a PDF.
$0.10 per file, one at a time.
$0.05 per file in batches.
Every conversion completeness-checked before it's handed back: pages present, text present, images present, checked against the source file.
That's a structural completeness check. It is honestly not a pixel-perfect promise. I can't promise the PDF looks pixel-identical to what Publisher would have rendered — Publisher itself no longer exists as the ground truth to compare against. What I can check, and report, is whether the pages, the words, and the images survived the conversion, and flag the files that need a closer look.
The ask
I'm not building this on a guess. There's a short waitlist page here:

https://exchangerebel.com/publisher-rescue/

It asks two questions:
How many .pub files do you hold?
Would you pay per file to convert them?
There's also an optional email field if you want to hear the result, and an optional note if there's something I should know about your files.
If enough people sign up in the next two weeks, I'll build it. If not, I won't — either way I'll post the result here. That's the deal with a test like this: the answer is the answer, and I'll share it either way.
— DataRebel

I Put 76 APIs Behind x402-over-MCP — and an Agent Paid for One

DataRebelHQ — Wed, 14 Oct 2026 18:42:07 +0000

AI agents are getting good at calling tools. They're still bad at paying for them.

An agent can't fill in a pricing page, can't manage a subscription, and shouldn't be holding your API keys. What it can do is sign a transaction. So if I want to sell data to agents — and I do — the payment primitive has to be per-call, machine-native, and settled before the data moves. That's x402: the long-dormant HTTP 402 status, revived as a protocol where the server answers an unpaid request with a payment challenge, the client pays, retries with proof, and gets the data.

I'm Mo. I run ExchangeRebel: 24 pay-per-call API services — 79 paid operations over plain HTTP — covering Solana token safety scores, SEC fundamentals, FINRA short interest, ETF distributions, US macro data, UK company records, product recalls, trademark search, weather, news timelines, a stock screener, and a pile of developer utilities. Every call is priced in USDC on Solana, from $0.005 to $0.50. No accounts, no API keys, no subscriptions: the payment is the authorization.

This post is about the newest front door: one remote MCP server that exposes 76 of those operations as tools, payable through the standard x402-over-MCP transport. It's live, it's listed on the Official MCP Registry and Smithery, and on October 14, 2026 it took its first settled call. Here's how it's built, what conformance actually cost, and where it honestly falls short.

The problem: agents don't do checkout flows

Every monetization pattern built for humans breaks for agents. Subscriptions assume a person who logs in monthly. API keys assume a person who signs up, stores a secret, and rotates it. Prepaid balances make the seller a custodian of buyer funds — I don't want to hold anyone's money, ever.

A per-call payment flips all of that. The server quotes a price in the protocol itself. The client pays exactly that, once, for exactly one call. Settlement is the access control. If the payment doesn't settle, the data doesn't move — fail-closed, no exceptions, no free tier hiding anywhere.

The architecture: the gateway holds zero payment logic

The MCP server lives at https://exchangerebel.com/mcp — one stateless Streamable HTTP endpoint on the same worker as the rest of the fleet. Stateless matters: no sessions, no server-initiated streams, nothing to keep alive between calls.

The design decision I'd make again: the gateway contains no payment logic of its own. Each of the 24 underlying services already had a toll gate — code that builds the x402 challenge, verifies a payment, settles it, records it in a ledger, and only then serves data. Those gates had already survived two full-catalog payment sweeps over HTTP. Reimplementing settlement inside the MCP gateway would have created a 25th payment path to audit.

So the gateway is a translator. An unpaid tools/call gets its challenge built from the target operation's existing challenge — and the gateway proxies nothing upstream, because proxying an unpaid call would be a free-data side door. A paid call has its payment payload re-expressed as the standard payment header and is proxied to the tool's own toll gate, which runs the exact code path an HTTP buyer hits: discriminate the rail, precheck, replay-check, verify, settle, record, serve. The gateway then translates the HTTP response back into a tool result and attaches the receipt.

How does a gate know which rail a payment belongs to? By the transaction's fee payer. A Dexter-facilitated payment carries Dexter's fee payer (DeXterR2kQm8AvRHnNPatWkE46TfAcMeBDjb6FySoAb8); a PayAI payment carries PayAI's. The gate checks Dexter first, then PayAI, then the direct rail — one discriminator, no guessing from payload shapes.

Replay protection is layered the same way: each rail keeps its own settlement ledger, and the gateway adds its own serve-once marker keyed by the hash of the payment bytes, so the same payload can't be served twice through MCP either.

The payment flow, in MCP terms

The x402-over-MCP transport mirrors the HTTP flow, just moved into _meta:

The client calls a tool with no payment. The server returns a tool result with isError: true carrying the PaymentRequired payload — price, asset, network, the works. This is the MCP equivalent of HTTP 402.
The client builds and signs the payment, then retries the same call with the payload at _meta["x402/payment"].
The server verifies and settles, serves the data, and returns the result with the settlement receipt at _meta["x402/payment-response"].

// 1. Unpaid call
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call",
  "params": { "name": "devutils_time_now", "arguments": {} } }

// → result: { "isError": true, "content": [ /* PaymentRequired:
     0.005 USDC, Solana, pay to the toll gate */ ] }

// 2. Retry with payment attached
{ "jsonrpc": "2.0", "id": 2, "method": "tools/call",
  "params": { "name": "devutils_time_now", "arguments": {},
    "_meta": { "x402/payment": { /* signed x402 payload */ } } } }

// → result carries the data, plus the receipt:
// "_meta": { "x402/payment-response": { /* settlement receipt */ } }

Client-side wrappers already exist (@x402/mcp on the TypeScript side, a Python equivalent), so an agent framework that speaks this transport runs the whole loop transparently. And the catalog stays free: tools/list returns all 76 tools with full input schemas and the price stated in every tool description, so an agent — or its spend policy — knows the cost before calling. All tools are paid; prices run $0.005–$0.50 USDC per call, and results are served only after payment settles.

What conformance cost

Two line items dominated.

Dual x402 conformance. The fleet speaks both protocol versions: v1 in the response body, byte-identical to what existing v1 clients expect, and v2 in the PAYMENT-REQUIRED header. All 79 paid operations pass as both. That's not vanity — different catalogs and facilitators read different versions, and MCP's transport assumes exactly the standard v2 payload. The conformance work done for HTTP is what made the MCP wrap cheap.

The price floor. Third-party facilitators charge per settled call — PayAI runs about $0.00145 a settle. Price a tool at $0.001 and you lose money on every sale. So the fleet floor is $0.005 per call: 54 of the 76 MCP tools sit exactly there, and the rest price up to $0.50 by data cost and value. Dexter, for the record, settles free — but the floor is set by the rail that charges, because the seller doesn't choose the buyer's rail.

The proof

Sweeps prove a rail works when I pay myself: PayAI settled 74 of 74 catalog buys, Dexter 79 of 79, each verified from the workers' own settlement ledgers rather than client-side success messages.

The MCP proof followed the same rule. On October 14, 2026, the first paid MCP call ran from a real wallet through the Dexter rail: devutils_time_now, $0.005, served with paid_via: dexter. I didn't trust the client's success screen — I read the server-side counter in KV (mcp:count:2026-10-14:settled), which had moved from 0 to 1. First settled MCP call, verified from the server's books.

The honest footnote: every settle so far, on every rail, is my own test money. The first payment from a wallet that isn't mine is still ahead of me. That's what the listings are for.

Honest gaps

The direct rail doesn't exist over MCP. Our HTTP API has a third rail — pay directly with SOL or USDC plus a fresh memo, retry with the transaction signature. That dialect is fleet-specific and simply not expressible in the standard MCP transport, which carries the facilitator-settled v2 payload. MCP buyers get PayAI and Dexter; the direct rail stays HTTP-only, and the docs say so plainly.
Generic MCP clients stop at the challenge. A client that doesn't speak x402-over-MCP calls a tool, receives PaymentRequired, and has no idea what to do with it. That's protocol-correct behaviour, but it means the MCP server by itself doesn't create demand — discovery does. The registry listings, the catalogs, and posts like this one are the actual distribution.
Two tools change the real world. Telegram bot provisioning ($0.50, allocates a bot for a month) and trademark watch registration ($0.50, 30 days) settle once and say so in their descriptions. Idempotency isn't a nicety there; it's the product.

Where it's listed

Official MCP Registry — com.exchangerebel/exchangerebel, status ACTIVE
Smithery — sound-money-investing/exchangerebel
x402scan — the HTTP fleet, 121 resources
The intro post on Moltbook, the social network for agents: https://www.moltbook.com/post/95f7a819-f3ba-4595-920d-8877e02de001
Full catalog and API docs: https://exchangerebel.com/openapi.json

If you build agents: what would yours pay $0.005 for, per call, without asking you first — and what's missing from a catalog like this that would make it pay more?

DEV Community: DataRebelHQ