For those who don’t know, before I started building Sill, I worked in journalism technology for my whole career. Even today, most of my working hours are spent consulting for publications and mission-driven organizations. So I’ve been idly wondering for a long time how news publishers can best join the open social web.

With the release of standard.site, I saw an opportunity to get news publishers onto the open social web with a low-intervention step. Many news publishers use WordPress, and many of those publishers use the same social/SEO metadata plugin: Yoast. Yoast already puts together all the metadata needed for a site.standard.document record, so how hard could it be to put that on a PDS?

Honestly? It wasn’t too bad! Today I’m launching the alpha version of Wireservice, a WordPress plugin that lets you sync your posts to standard.site records on your PDS. Want proof? This post is on my PDS!

How do I get it?

If you want to use Wireservice today, you’ll need to clone the repo into your plugins directory, or clone the repo, make a zip file of it, and upload it to your WordPress via the WordPress admin. I’m working on getting Wireservice into the WordPress plugin directory, but there is an 18-day backlog to get it reviewed!

What does it do right now?

Currently, Wireservice does the following:

• Maintains a scoped OAuth connection to your PDS from your WordPress, via an AIP proxy.
• Creates a site.standard.publication record for your WordPress
• Creates site.standard.document records for your posts
• Integrates with standard WordPress fields and Yoast SEO fields for easily mapping your content to site.standard fields.
• Optionally converts your post to plaintext for the textContent field on documents.
• Allows you to backfill your PDS with old posts
• Sets up verification for your publication and document records
• Lets you browse your PDS records directly from WordPress

Wireservice does not:

• Post to Bluesky for you, or set a bskyPostRef on the document record. I’m unclear if people would want this. Let me know!
• Publish content in the content field of the document record. Work on a lexicon is ongoing, see below.

How does it work?

Connecting to a PDS

The reason Wireservice wasn’t too hard to make was because all the hard work is handled by AIP, Graze’s excellent OAuth service. I’m now hosting an instance at aip.wireservice.net, and Wireservice manages its connection to your PDS there.

After you install the plugin, you set up an OAuth connection to your PDS from the WordPress admin, proxied through AIP. This OAuth connection can only read and write standard.site records. To get started, go to Settings > Wireservice in your WordPress admin after you have installed the plugin.

You can also stand up your own AIP service if you don’t want to use mine. I put some instructions in the README of the repo that should help.

Publication records

Today, Wireservice supports every record defined in the site.standard.publication lexicon. The basic metadata can come from standard WordPress fields or, if you have Yoast installed, Yoast fields. Take a pass through the SourceOptions.php file to see everything Wireservice gives as an option.

Document records

Standard.site documents can be created automatically when you publish by setting your default fields. Similar to publication records, you can pull from standard WordPress fields or Yoast-specific fields if you have Yoast installed.

Wireservice doesn’t support the content field yet. This is largely because I don’t have a good content lexicon to map to. As I was writing this, Aram Zucker-Scharff published markpub.at, a proposal for a Markdown content lexicon. This may make sense as an option for Wireservice as it develops. However, if you want, Wireservice can put your post content in the textContent field as plaintext. I have deeper thoughts on a content lexicon that might make sense for news publishers, more on that below.

Wireservice also adds a meta box to the WordPress post editor that lets you override your document record fields if the defaults don’t make sense.

Backfill

If you’re all-in on atproto and standard.site, you may want to backfill your existing WordPress posts to your PDS. On the Wireservice settings page, you can click the backfill button and it will batch upload your posts based on your default document settings. You will need to have created your publication first.

Records browser

Once you have created a publication and some documents, you’ll be able to see the records browser from the Wireservice settings page. This page pulls your publication record and all document records mapped to that publication directly from your PDS.

Verification

Finally, Wireservice handles the verification pieces of the standard.site process. It sets up a .well-known/site.standard.publication route that serves the publication AT URI. It can autodetect if your site is hosted at a nested path (based on what you set as Site URL in your publication settings) and move the route to the proper path.

Wireservice also adds the <link rel="site.standard.document"> tag to your posts for document verification.

What’s next?

Wireservice offers WordPress publishers a simple way to get their publishing data on AT Protocol. But for my target audience — news publishers — this is not enough. News publishers need a way to attract new and loyal audiences for their journalism.

What the atproto ecosystem lacks right now is a high-quality news reading experience, akin to Apple News or Smartnews. Many news publishers are used to porting their content to aggregation apps like these as long as the process is easy and the reward is worthwhile.

Luckily, Apple News Format is just JSON. Lexicons are also just JSON. Apple News Format is especially nice for publishers because its flexibility offers a high level of brand safety. Your fonts, colors, and style are transferable. While there are some core differences to work out, we can build an Apple News alternative on atproto. One that works better for publishers and for readers.

Currently, Apple News offers a ton of audience to news publishers. From experience, raw pageviews on a story on Apple News can dwarf the raw pageviews on a story at the canonical URL for a mid-size publisher. However – again from experience – those high pageviews rarely translate into anything of value for a pubilsher. Apple News readers rarely subscribe to newsletters, donate, or become members of news organizations with those offerings.

A fresh approach to news aggregation on atproto could solve many of these problems.

• The standard.site lexicons already offer a subscription graph that this aggregator could use, giving publications a direct path to knowing who their subscribers are, rather than locking those subscriptions in another walled garden.
• The work done by ATProtoFans is a vision of what membership could look like for publishers on atproto. A news aggregator could give readers easy ways of directly supporting their chosen publications.
• As work on permissioned data continues, even paywalled content on the protocol, accessed via subscription to the publisher, becomes possible.

For readers, the benefits of a protocol-native news aggregator are also clear.

• This aggregator can work on any platform, not just Apple devices.
• Using the same feed-driven approach as Bluesky, an atproto news aggregator can offer algorithmic choice.
• By layering in other social features, an atproto news aggregator can offer a fuller experience. What news is popular in your network (a la Sill)? What are people highlighting on Margin? What Semble collections is this story a part of?

So, how does this translate to a roadmap for Wireservice? Here’s what I’m thinking:

• Support a lighter content lexicon (hopefully markpub.at!) for lower-lift WordPress blogs.
• Develop a rich content lexicon that competes with Apple News Format, offering brand safety and layout flexibility.
• Build integrations for these lexicons for more publishing platforms. I had hopes for Ghost, but it looks awfully complicated.
• Build a high-quality news aggregator experience on top of these lexicons (aka, draw the rest of the fucking owl).

What would you like to see? Let me know.