Tag Archives: friending

Posted on
by

The other day I sketched out some notes on how friend/follow and subscribe might work in a distributed social network such as Idno (I have since hacked together some plugins based on those notes).

So, I thought I’d sketch up some thoughts on how private and friend only posts might work in a distributed social network:

Outline specification

  • On account creation (or if there isn’t a key present) a key pair is generated, this key pair is used to identify a user’s profile to that user’s friends.
    • I’m not sure exactly what kind of key this should be at this point, although I’m leaning towards a PGP key pair, although OpenSSL has its merits (of course, there is no reason why we can’t use multiple technologies).
    • We’ll probably have to have the private key stored on the server for the purposes of signing, although there’s no reason why these have to be your main keys.
  • When Alice follows Bob, as described in my previous post, they both pull the public keys from each other’s profile as part of that exchange, which have been marked up using Microformats 2. Any keys found are saved against the record of that user.
    • For security, we probably want to do some sort of key validation here; perhaps key fingerprint, or perhaps better some web of trust based on mutual friends…
    • How key revocation might work is an open question, but I think the easiest way might be for Alice to send another subscription request to Bob, and have that re-trigger this process, rather than (as happens at the moment), returning an error that Alice is already subscribed to Bob.
  • When Bob writes a friends only post he lists Alice’s profile UUID in a list of people who can view the post, then ping’s Alice’s endpoint.
  • When Alice visits Bob, or Alice’s site visits Bob’s permalink, it identifies itself by signing the request using her key. If the signature is valid and belongs to a key for a user for which Bob has allowed access to the permalink, the data is displayed, otherwise a HTTP 403 code is returned.

Just some rough thoughts for now, let me know your thoughts!

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!