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/bobNote: 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!
nice brainstorming, loving the idea of #microformats2 key discovery for private content! (I publish a link to my PGP key on my homepage, if you want to test it out 🙂
Have you had a look at PuSH v0.4? It’s way simpler than old PuSH and is no longer strongly tied to RSS/ATOM content.
Note also that the “argh my little site got popular and is dying” thing can be solved even within your ideas, by making the endpoint an external service. Woo hypermedia discovery over well-known URLs!
(originally posted http://waterpigs.co.uk/notes/4SEHLS/)
What’s complicated about PuSH? Rather than re-inventing the wheel, what could we simplify to your liking? Help us make it better while let us share what we learnt too!
Thanks Barnaby!
I’ve not really got into it with PuSH 0.4, my last look at it was when it was still tied to ATOM, so it might be worth a look. As Julien points out, wheel re-invention should be avoided, although I think the use case here is slightly different.
Running this as a different service would certainly work, although it doesn’t solve the thundering herd of MF2 parsers hitting your site… although I guess that’d be indistinguishable from a regular spike in traffic, and could be handled with standard technologies. I doubt, at this stage, we really have to over think it!
Mainly that it was bound tightly to ATOM, but as Barnaby points out, this is somewhat out of date 🙂
That said, I think I’m trying to solve a subtly different use-case: for example, CRUD on content, plus a way of getting detailed author info, and with a key exchange, allow private content to be pushed securely to a friends list.
Just brain storming at this stage, I’m certainly not wedded to any particular implementation 🙂
Of course, the actual notification portion could be carried over PuSH, which might well make sense. Especially of tomb-stoning is supported…
+1ed this.
Over on my Idno development fork, I’ve pushed some functionality that I think is rather neat (and I hope will be adopted by upstream).
In a nutshell, I’ve started fleshing out the ability to Friend/Follow other users (based on some stuff I’ve previously kicked about).
The ability to add friends (and create posts only visible to them) is what puts the social in social network, and was functionality previously missing to idno core. An added complexity is that, since Idno is designed to be a distributed network, this needs to work across multiple installations.
Idno references users by URL, so this much was fairly straightforward, however I absolutely didn’t want people to be typing URLs into boxes to add a friend…
MF2 to the rescue!
Since everything in Idno is marked up and parse-able by it’s built in Microformats parser, Idno can easily harvest the required information when parsed a page, so all I really needed to do was pass an endpoint a URL.
So, I created a simple bookmarklet:
Once dragged into your toolbar, you can click on any page and your Idno installation will find any users present and allow you to add them in a couple of button clicks.
Monocultures are considered harmful
What makes this approach especially cool is, so long as the page is marked up using simple Microformats, your friend does not need to be running Idno in order for you to add them.
Your friends could be running Elgg, WordPress, Fizzbuzz, whatever, and you can still follow them, and allow them to see private posts (using some form of authentication – more on that to come).
Have fun!
Share this:EmailLinkedInTwitterGoogleFacebookReddit