Category Archives: Software

Posted on
by

The ability to follow your friends, and receive notifications when they post new activity, is a vital part of what makes a social network – well – social.

With a distributed social platform like idno, this presents a bit of a problem.

In a previous post, I mooted a specification that would allow for distributed friend/follow/notification on Idno, and any indieweb platform that chooses to support the protocol.

Since it’s always a good thing to have a reference implementation for these things, I put together a couple of plugins that implement the spec. The first, Subscribe, provides the basic engine – the protocol endpoint, together with a subscriber and subscription list page. The second, SubscriptionNotification, provides a visual notification mechanism, via a popup label, and a summary page.

This is highly experimental, and is subject to change as we flesh out the mechanism, but I think it’s a good start.

» Subscribe plugin…
» SubscriptionNotification plugin…

Posted on
by

Ok, so the other week I wrote a little bit about migrating my git server from gitosis (which is no longer maintained), over to gitolite.

Along side this, I also run a gitlist server. Gitlist is a web front end for git, similar to gitweb, which provides a slick and modern looking “github” style interface. It is also remarkably easy to set up and configure.

One gotcha I found was that, while unmodified gitosis repositories displayed correctly, as soon as you pushed a change, gitlist presented an error:

Oops! fatal: Failed to resolve HEAD as a valid ref.

After some investigation, it seems the problem stems from a permission issue. By default, gitolite creates new files and repositories with a slightly more restricted set of permissions.

Fixing the problem

Once the problem was identified, the solution is thankfully fairly trivial:

  1. First, stop gitolite making the situation any worse. Go to the gitolite home directory and edit .gitolite.rc, and set

    $REPO_UMASK = 0027;

    This will cause new files to be created with access to group, as well as user.

  2. Next, give your web server process access to the gitolite group. Assuming, as with me, the user is git, modify /etc/group and add your webserver user to the git group, e.g. git:x:128:www-data
  3. Restart apache for your changes to come into effect.

Fixing broken repositories

New repositories and files should now be created using the more permissive access permissions, which gitlist/gitweb will now be able to see. However, you may need to fix the permissions on some existing repositories.

find repository-name.git -type d | xargs -i{} chmod 750 {};
find repository-name.git -type f | xargs -i{} chmod 640 {}

Hope this helps!

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!