Tag Archives: #indieweb

Posted on
by

One of the many itches I have been scratching, as part of taking my social media contributions out of silos, is how to keep track of what my friends are up to. So, we’re talking about bringing the familiar social networking concept of friends, subscriptions and update notifications to a distributed social network like Idno, an Elgg/Elgg multisite node, or an Indieweb site.

Existing systems, like PuSH, seem a little to complicated for my liking. I wanted something I could get up and running in about an hour, and test using curl.

I expect other people in the Indieweb community are thinking about this too, but I couldn’t find anything with the 30 seconds of googling I had time for, and since I needed it I thought I’d throw my hat in the ring…

Outline specification

  • Two sites/profiles: Alice and Bob.
  • Alice wants update notifications from Bob.
  • Alice’s site looks at Bob for subscribe endpoint.
  • If found, Alice’s site sends POST containing Alice’s profile URL to the endpoint:

    subscriber=http://alice.com/profile/alice&subscribe=http://bob.idno/profile/bob

    Note: Bob’s endpoint is specified for multi-user situations, allowing the system to know which user we’re subscribing to.

  • OPTIONAL: Alice and Bob mine each other’s profiles for MF2 data, one could also do key exchange at this point for any secure messaging or authentication for syndication of private posts.
  • When Bob creates or updates a post, he discovers Alice’s endpoint and sends a POST containing the permalink, e.g:

    subscription=http://bob.com/foo+bar/

  • Alice checks to see if permalink is from recognised domain (Optional, but recommended).
  • Alice visits the permalink and parses MF2, extracts the author and checks that the author URL is in the subscription list.
  • Alice then uses the MF2 content to produce a feed, or pop up a notification, whatever.
  • If Bob deletes a post he sends a DELETE containing the permalink to Alice’s endpoint, e.g:

    subscription=http://bob.idno/foo+bar/

  • If Alice wants to unsubscribe/unfriend she sends a DELETE mirroring the initial subscription request to Bob’s endpoint, and then (optional, but recommended) ignores any future post from user.

Crucially, it doesn’t require firing ATOM blobs around or maintaining extra feeds of data.

Handling popularity

An obvious problem with this proposed spec is how one handles a situation where a user has many subscribers. Here, we may want to update the spec or use a different technology, but the vast majority of people will likely only have a couple of hundred people in their network, tops.

I’ll probably be building this functionality out as an plugin for a couple of client sites in a couple of days, and I’ll post implementations when I have them, but let me have your comments below!

Posted on
by

WebHookWebmention, as well as the legacy Pingback, provide a way of notifying a third party site that you have made some reference to something on their site. So, for example if I reference somebody elses blogpost in mine, that blog will be notified and my reference may appear as a comment on the post (unless they’re blogging on a passive aggressive silo like Google+ or Facebook, or their blog uses Disqus, which is, in many ways I won’t go into now, the suck).

Pingbacks, and increasingly Webmention, are supported by most major web frameworks and blogging platforms, but adding them to a home rolled platform can be a little bit of a faff, especially if these platforms are build on static HTML.

So, inspired by Pingback.me written by Aaron Parecki, I wrote a bit of middleware that can be installed on a web server with minimal fuss, and can provide pingback/webmention services to other sites.

The reason I didn’t use Pingback.me was that I needed something quickly, I had reasons why I didn’t want to install an entire Ruby stack, and I needed the webhook functionality for a couple of projects (including some funky node.js dataset regeneration to tackle some scalability challenges, but that’s a different story).

Setup

One of the main requirements for pingback2hook was ease of setup, which I hope I’ve achieved.

  1. Start by checking out the source code from the github repo here, and place this on your web server.
  2. You’ll need to have PHP 5.3 running with mod-rewrite, and also CouchDB (to store pings), which on Debian systems, should be a fairly straightforward setup.

    apt-get install apache2 libapache2-mod-php5 couchdb; a2enmod rewrite

  3. If you’re running pingback2hook on its own subdomain, you should be up and running, but if you’re installing to a subdirectory of your site you’ll need to modify the RewriteBase in .htaccess.

Enabling pingback and webmentions on your site

Once you’ve got the software up and running somewhere, you can then start enabling pingback support in your sites. This is a two step process:

  1. On the pingback2hook server, define an endpoint for your site in a .ini file. This file will define the endpoint label, a secret key for communicating with the API, and zero or more webhook endpoints to ping. E.g.

    [mysite]
    secret = "flkjlskjefsliduji4es4iutsiud"

    ; Zero or more webhook endpoints
    webhooks[] = "http://updates.mysite.com"
    webhooks[] = "http://data.mysite.com"

  2. On your website, declare the necessary hooks in your metadata, either by headers:

    // Webmention
    header('Link: <http://pingback2hook.myserver.com/webmention/myendpoint/>; rel="http://webmention.org/"');

    // Pingback
    header('X-Pingback: http://pingback2hook.myserver.com/pingback/myendpoint/xmlrpc');

    And/or in the header metadata…

    <html>
    <head>
        <link href="http://pingback2hook.myserver.com/webmention/myendpoint/" rel="http://webmention.org/" />
        <link rel="pingback" href="http://pingback2hook.myserver.com/pingback/myendpoint/xmlrpc" />

        ...

    </head>

    ...

</html>

Once set up, you will get an entry in the database for every pingback or webmention a given permalink receives. If you’ve defined some webhooks, these will be pinged in turn with the JSON content of the ping.

Viewing your pingbacks

To view your pingbacks you can either make a direct query of the couch database (default: pingback2hook), or make use of the API.

Currently, you can query the API via its endpoint at https://pingback2hook.myserver.com/api/myendpoint/command.format, passing any required parameters on the GET line.

At the time of writing only one command is supported, but I’ll add more as I have need to:

Command Parameters Details
latest.json|jsonp target_url, limit (optional), offset (optional) Retrieve the latest pings or webmentions for a given permalink url.

To make the query, you need to authenticate yourself. This is done very simply by passing the ‘secret’ for the endpoint in your request header as X-PINGBACK2HOOK-SECRET: mysecret. This is very basic security, and your code is being sent in the clear, so it goes without saying that you should ONLY make queries to the API via HTTPS!

Have a play, and let me know what you think!

» Visit the project on Github…

Posted on
by

IFTTT (short for If This Then That) is a very powerful service that one can use to hook a number of different cloud services together in cool ways, and it’s a service I make a fair amount of use of.

Like many of us who make use of cloud services, the Snowden revelations, that the US and UK intelligence communities had hooks into all the major cloud services (or perhaps a better word would be “confirmations”, since many of us suspected this was going on for a while), have given me pause to re-evaluate the services I use and trust.

So then, what of IFTTT?

With all the hooks it has into other services, it does seem to represent the ultimate in back doors. Out of necessity of function, the permissions granted for each service are quite wide ranging, and we only have it on faith that they won’t be abused. Ok, so it’s not as bad as them knowing my password, since I can click a button and revoke access at any time, but until then IFTTT have full access.

As a US company, and through no fault of their own, IFTTT are compromised when it comes to security, since they’re all backdoored by the patriot act. I suspect that if they haven’t been forced to share access to accounts, it’s only because they are still relatively small fish (when compared to the likes of Google) and are only really used by the technical subset of internet users. But as they grow, it’s only a matter of time before they appear on someone’s radar.

In addition, their business model has always been a little bit of a head scratcher. I suspect the whole service came about from a “wouldn’t it be cool if…” kind of conversation, rather than a set agenda to make money (quite right too), but servers don’t pay for themselves, and I do wonder how long it will be before In-Q-Tel come calling.

Of course, it may be moot, since most of the services that IFTTT connects to are also US based, and for that matter, other countries are almost certainly forcing backdoors into their cloud services too.

Still, it’s got me pondering self hosted alternatives… any nice #indieweb projects out there?