I’ve launched this as Bridgy Fed!

I often work on connecting things that don’t automatically connect but should, like Bridgy for IndieWeb and social networks. Federated social networks like GNU Social and Mastodon have been hot recently, so I’m thinking about them too.

OStatus is the most widely used standard for federated social networking. Here’s background and a straw man design for a bridge between OStatus and IndieWeb’s Webmention, which would let users on both sides follow, reply, like, RSVP, and otherwise interact with each other’s posts.

(OStatus is being replaced by a newer standard, ActivityPub, so I’ve also designed a similar ActivityPub bridge.)

Background

First, some links:

• Spec, W3C community wiki with Howto, and component standards:
  • Atom
  • Salmon
  • Portable Contacts
  • PubSubHubbub
• Mailing list (inactive, spammy)
• IWS 2017 session writeup
• List of implementations. Notable:
  • GNU Social
  • Mastodon (issue)
  • Friendica (details, wiki)
  • Hubzilla (GitHub)
  • Diaspora (discussion, minor wiki note)
  • pump.io (issue)
• The Federation (focused on Diaspora, not OStatus)

Bridge design

The bridge needs to translate a few high-level things: data, discovery, and interaction protocols.

First, some simplifying assumptions and non-goals:

• Don’t translate AS2 to microformats2 HTML. Most of the big existing projects already include mf2 in their HTML: Mastodon, GNU Social, pump.io, and Friendica (but not Diaspora). We’ll just use that in place.
  (This may not hold for non-text interactions, e.g. likes, so we may need to revisit those. Also, it may only works well for public data, so…)
• Only public posts and interactions. I’m not sure any project has truly robust, mature support for private or semi-private interactions right now, so they’re not a high priority.
• Require IW sites to serve Atom and PuSH themselves. There’s fairly widespread support for both in major CMSes and external like Superfeedr and FeedBurner.
• No user registration. The bridge is mostly stateless, modulo discovery caching and Salmon keypairs, and we don’t need to do an OAuth-style user approval dance on either end…so let’s not!

Next, a major design decision. Choose one of:

• Proxy all domains. Say the bridge’s domain is bridge.example. If IW user alice.example and OS user @bob@ap.example want to interact, they’d do so via wrapped identifiers like @alice.example@bridge.example and bob.ap.example.bridge.example, respectively. Pro: no changes needed on IW or OS sites. Con: bad UX.
• Require sites to point to bridge. If IW sites support OS content negotiation discovery and redirect to the bridge, and OS sites add a <link rel="webmention'> that points to the bridge, the normal alice.example and @bob@ap.example identifiers will work automatically. Pro: Good UX. Con: depends on support in each individual project.

Proxying is a non-trivial amount of work, and we can always add it later, so we’ll start without it.

Data

granary already has a first pass at translating between microformats2 and ActivityStreams 1, but it hasn’t been tested against an OStatus implementation. We’ll need to do that and fix any holes. At minimum, I think the PoCo extensions are missing.

Discovery

For OS to discover IW users, IW sites will need to redirect WebFinger and XRD URLs to the bridge, which will fetch their homepage, find its representative h-card, and generate WebFinger data for it. Also, if it’s the first time we’ve seen this user, a Salmon magic key is generated and stored.

For IW to discover OS users, OS projects will need to advertize the bridge’s webmention endpoint in their HTML, e.g. <link rel="webmention' href="https://bridge.example/webmention>. As an example, I’ve already asked Mastodon for this in an issue.

Interaction protocols

To convert a webmention to OS:

1. Accept incoming webmention.
2. Fetch source page. Translate it to AS1.
3. Fetch target page. Determine author user.
4. Discover user’s Salmon endpoint via WebFinger/XRD.
5. Send the AS1 interaction in a Salmon slap.

To convert an OS interaction to webmention:

1. Accept incoming Salmon slap.
2. Parse AS1 object in body, determine target URL (reply to, like of, etc). Reject if no target is found.
3. Fetch target URL, discover webmention endpoint.
4. Send webmention with OS source and IW target.