So, Known lets you share links via a share API (and a toolbar bookmarklet). In the later versions of it, this action also calls a link shorten event hook which allows a plugin to shorten the shared URL.

Because I often share links, I wrote a quick plugin to hook into my bit.ly domain.

Using the plugin

Install and activate the plugin in the usual way, and then in your admin panel add your generic access token to the input box on the bitly page. Generate this token from your bitly settings page.

Currently you can only have one domain per Idno install, basically because I was short of time and so didn’t do the full OAuth thing.

So much to do, and so little time. Have fun!

» Visit the project on Github...

I’ve submitted a pull request over on the Known project git repo that allows you to specify a CURL proxy connect string (which has since been merged).

If specified, this connection string will make all web service and web mention calls be sent via a proxy server.

This was a relatively small change, but is useful in many ways – for example, for communicating through a corporate firewall. It is also provides a way of routing Known to Known communication over TOR.

Why would you want to do this?

Well, this is part of an ongoing effort to harden Known against the new attack realities we face on the internet in the 21st century.

One of the things that the Snowden documents have revealed, is that the bad guys are particularly interested in harvesting everyone’s social graph – who knows who – so that they can, among other things, automate guilt by association.

Going to some lengths to hide this information from an attacker sitting on the wire, is therefore, a prudent thing to do.

Ok, how?

  • Install the TOR proxy on your server; this may just be as simple as typing apt-get install tor.
  • By default the tor package only installs the client, so you’ll need to modify the config to open up a SOCKS relay.
  • Next, tell your known site to use this relay; open your config.ini and set the proxy_string:
proxy_string = 'socks5://path.to.tor.proxy:9100'

Gotchas

Routing over TOR is only part of the solution of course. For the communication to be properly safe, you should also encrypt the communication using HTTPS.

Unfortunately, whether a connection is conducted over encrypted HTTPS or not is largely up to your friend’s webserver. But, you wouldn’t be silly enough to run unencrypted, right?

Given the numbers of nasty attacks that can be launched against an unencrypted web connection, the internet at large is now moving towards deprecating unencrypted port 80 HTTP. Google search results will now give preferential treatment to encrypted websites, so that’s another reason!

So, don’t be part of the problem. Have fun!

This article got me pondering on how one might start building a distributed “related article” network, but without relying on a centralised silo.

Related articles on the same site is largely a solved problem, but at the moment, to do the similar thing with multiple sites requires a centralised service. Centralisation is bad, as we’ve discussed before, so how could you build a federated network of sites, all referring people between each other in an automated but meaningful way?

My current thinking is to leverage PuSH; Alice lists sites to which they’d like to receive related articles from, these could be individual sites or even a centralised aggregator. Alice’s site then subscribes to the PuSH hub and starts receiving updates, when these updates are received they can be passed through to whatever comparison algorithm you’re using – I’m thinking of adapting the wordpress one for this blog.

Should be fairly straightforward to implement, and would provide a simple way to federate content within a group of individuals.

Anyone working on something like this, or shall I drop this into my todo list?