Archive for August, 2012:


Rethinking Social Media : A Self-Contradictory Opinion

Stamp US 1977 2c Americana

Should the USA nationalize Facebook?  Um, no.

To be more specific, aside from it being the USA – a country which tends to believe in the market doing a better job of looking after people’s interests than the government – there are any number of reasons why you don’t want a state running a social network.  A good example would be “People from other states use it too”.

Should any other country nationalize Facebook?  Still no.  If you can explain why having a public social network is more important than good public transport, or good public healthcare, or good public education, you are a better person than me.  No wait, you are a far worse person than me, and you don’t deserve to have an opinion on anything.  Go away.

But the article makes a good point that it would be nice to have a trusted social network – one that would support people in countries where they don’t have freedom of speech.  Of course, no government would do this, because it would either involve being seen as siding with enemies of states you might want to still pretend to be friendly with, or it would involve coming up with a system which would be as useful to enemies of your own state.  The terrorists would have already won (even if all they won at was Mafia wars… which presumably some of them would be quite good at.)

However governments are not usually the protectors of free speech.  In general they tend to protect ‘the sort of speech we want, but not that other speech which tends towards the nasty and evil’.  To protect free speech, I would look instead towards various charities – the Amnestys, and EFFs and CPJs of the world.

And, in thinking of those charities, it occurs to me:

Would there not be some place in the world for a ‘free speech social network’, supported by a non-profit foundation, and presumably grants from both right on for-profit organisations and charities of the sort I’ve described before?

Here is my thinking – if I were to set up this sort of social network, it would have to have the following characteristics:

It would have to compete head to head with Facebook and Twitter and whoever else.  You want this network to be the place everyone goes to, the place everyone knows about – because you don’t just want freedom of speech for specially equipped activists, you want freedom of speech for absolutely everyone.  You want it to be easy and safe to say what you want as and when and why you want.

Because people wish to shut down free speech, and because there is no legislature that could be trusted with protecting a free speech social network, it would have to be distributed.  In saying that, I worry too much that I’m contradicting what I have previously said about social networks not needing to be distributed.  I would like, if I may, to plead a technicality:  There would be a core site for the social network (or perhaps a core site in each country).  All the sites would communicate to each other.  And all would interoperate with each other.  And, if you wanted higher levels of security still, you could run your own version of the site.  Now some of these sites may need to block particular content for legal reasons – but that wouldn’t be a problem, people could simply go to other sites (which would be well known about) hosted in other jurisdictions if they wanted that content.  So what I’m talking about here is not ‘lets build some distributed software, and try to get a network to take off based on it”, I’m talking about ‘lets build a good social networking site, and by the way, you can mirror some or all of the content, and interoperate with it in a distributed way if you want’

To achieve the goal of distribution, its going need cryptography.  Things like ‘only distribute this to my friends’ can only be done with crypto in a distributed system.  But crypto can also be used to solve other issues like ‘this proves who I am’.  The trick here would be to hide the crypto from the end user as much as possible – which is to say, they should never need to know that crypto is involved.

It should play well with TOR – some people who would want to use this network would need TOR – but the site that most people see would be hosted on the open internet, because that is the obvious place to host such things.

It would have to be free to everyone.

I’m optimistic that this could be done.  The wikimedia foundation has worked, and has managed to produce not just Wikipedia, but the software which powers it.  I see no reason why similarly generously spirited people shouldn’t get together to create the ultimate social network.  One which cares about its users, and which is free, because it is funded by people who care about freedom, not by people who care about adverts.

Will it happen?

It could.  And possibly it should. I think it might just be an idea whose time has come.

Rethinking Social Networks : Different Applications

 

Assuming we don’t want to replace Facebook, then we are left with trying to use social networks in other applications.  These need to be applications that lots of people are going to want to use (otherwise the social aspect is useless), which perhaps have a viral way of grabbing people’s attention (using social to sell them) and which fundamentally are made better by being social.

When I’m thinking of the sorts of application which come in and grow big, my first port of call is to see “What are geeks using right now which hasn’t caught on in the mainstream?”  There are two things that currently come to mind:

Bug Tracking Systems

and

Distributed Version Control

Now – clearly neither of these are new ideas (although I was thinking of distributed version control well before it hit the mainstream consciousness – but that’s another story).  And both of these exist to some extent outside of geekdom:  You have a certain level of version control is various word processing systems, and online data storage systems, and ticketing systems of various type exist in various industries (mainly industries with support desks).  So how do we make them different, and make them social.

Bug Tracking:

As I said, ticketing systems are used in many industries.  In my job I have to handle both the customer support ticket system and the internal bug tracking system.  In my time I’ve used quite a few bug tracking systems of various colours.  They have generally common characteristics:

Someone enters a bug into the system (we could generalise this as ‘someone enters a thing for you to do into the system’).  This raises a ticket.

They assign the ticket to the person they think is responsible

This person is made aware of the issue by an email arriving.

If they don’t think they are the person responsible, they pass the issue on to someone else (and that person gets an email)

 

Better systems let you say things like:

This particular tasks consists of multiple subtasks

and

Before I can work on this particular task, someone else must complete another task.

 

This is starting to look like a general ‘to do’ system.  Indeed, I’m astonished when I hear that most companies don’t use a system like this to manage their projects, and keep track of things that have to be done, and when they are to be done by.  That  also suggests to me that, given a more friendly user interface, we might be onto a winner.

So we’ll start with a single user ‘to do’ program.  They can enter tasks, and mark them as done.  They can also break them down into subtasks, and put dependencies between tasks.  All that requires is a friendly UI to make everything clear.  There are good examples on the net.

Now, lets take a leaf out of tripit’s book.  When you sign up to the todo apps site, you get an email address.  You can forward any email you get assigning you things to do to that address, and it will get turned into a todo within the system (which may well be a todo along the lines of ‘TODO: Generate todo tasks from this email”).  The first social aspect is that each task will be associated with the original email – which means you can send an automated email back saying something like ‘I’ve identified the following tasks from your email – if you want to see that I’m keeping up with them, please go to this web page’.  Moreover you could only allow someone with the email address you originally identified to log in to that site (using email based authentication)

We can go further.  What if you generated a task which someone else had to do.  Now, its pretty bad form to say ‘here is something you’ve got to do, which I’ve already put into a task tracking system’) – but you could add a task ‘wait for a response from this person’ and send them a querying email from your to do system.  Moreover, if that person is already using the bug tracking system, the email could be automatically redirected to their todo list box – which would mean they would have a task that you could monitor.  If they are not using the system, well, every email you send will have an advert encouraging them to give it a try.

Monetisation could come from apps (see passim), enterprise subscriptions (will walled gardens that won’t stay in someone’s account once they leave the company and mass email subscriptions), or premium subscriptions.

 

Distributed Version Control

The concept here is there exists some sort of document (or set of documents), wherein each person can have a copy and make their own changes, then pass the document on to someone else who already has a copy of the document, who can decide if they want to accept some or all of your changes into their copy.  There isn’t one true central copy.  Also, you can go back in time and see how the document has changed.

We geeks use it to keep track of our source code.

But in the real world it would seem great for managing that big collection of stuff you have to keep track of for a project (or, on a smaller scale, for a meeting)

I see it as being like this:

I have some sort of application where I can store various pieces of text, photos, lists, links to web pages, other documents etc, and keep them all together in one place.  In the old days that place would have been a file, these days it would be a web site somewhere.  Now, I might want to let someone else look at this collection of documents, while I might want to let others edit it.  Easy – I just set it to email them links to the document – now all those people have accounts where they can take a copy of the document, and where they can edit their own copy to their hearts content - and some will also have the ability to see what changes I’ve made since – and fewer still will have the ability to suggest I accept some of their changes (it would be something along the lines of ‘Show Ben These Changes’ in the ui.  To us Geeks, I’m talking about a github pull request)

Again, it is fundamentally social – and all the app I’m describing needs to actually be is something akin to a wiki – or HyperCard.

 

Go with either of these ideas, and you have the potential to exploit the still underexploited social arena

Rethinking Social Networks : How To Replace Facebook

Facebook engancha

It seems like Facebook has got sufficiently sticky that we will never be able to usurp it from its position.  Altavista felt that way once, but all it took was for a new startup to come along and do things better.  Lets say we want to usurp Facebook – how would we do it?

The first thing we have to do is make money.  Even if we want to get VCs involved, I think they would still want to see some sort of monetization plan.  I also think that, right now, app.net are right – you don’t want the money to come from adverts.  However, app.net seem to suggest the solution is charging the user a subscription.  I’m not sure about that.  If you want to create the ideal Facebook killer you want to get lots of people there – and a subscription is a gatekeeper.

I have a different idea to monetize the social network (a plan, which incidentally, encourages it to be a better platform too):  the network is funded by an app store.  This might seem odd, until you realise that almost all publishing on the network could be an app – and that only apps sold via the app store could interact with the various apis.  Apps could either be ad-supported (in which case, we would take a cut of the advertising), in-app purchase supported (in which case we would take a cut of the purchasing), or price supported (we get a cut, you get the picture).

To explain further – we would create a social network where you would get access to read anything posted to you – and perhaps to post twitter size posts to up to 100 followers.  This would suit most people.  If you want to add pictures to your post, you’ll need to buy the ‘add pictures’ app.  If you want to have more followers, or to be able to push your posts to particular people, we’ll provide apps.  Want to write longer articles?  We can provide the means.  Want to do something we can’t even think of?  We’ll make an api so that other people can do it – so long as they follow the rules of our framework (and our app store guidelines).  Want to use your phone to read – you can do it for free from our mobile site, or, if you need an app – there will be one (but it will be ad supported, to pay for the cost of development).  Want to post from your phone – that’ll be an in app purchase.

Most of these apps would be a one off purchase.  We might also charge for storage above a limit (I’ve long believed storage should usually be a one off purchase price – if you’re making people rent storage, you should probably be thinking about making people pay for something like data transmission instead).  We might charge a recurring fee for some ‘enterprise level’ features – but only to skim lots of income from big companies.  People will keep coming back.  People will want multiple accounts.  Each account will need apps.  We will keep making money – but we will be making it from our biggest fans – from the people who want to pay us.

So we have a monetization plan.  How do we get people to the new service?

The answer is:  we make it easy.

Facebook seems to provide a few services

  • Find and keep up with old friends (or at least don’t lose track of them totally)
  • Keep up with current friends, and arrange activities
  • Stay in touch with celebrities
  • Do some amount of microblogging
  • Play multiplayer games
  • Store & publish photos

My guess is we don’t want to replicate all of these – at least not to attract people.  I suggest right off that we don’t worry about the finding and keeping up with old friends aspect.  That’ll come to the new platform when enough people are there.  Celebrities will do the same.  We want to be a good platform for them to blog on, but not spend our time trying to encourage them.

The app store monetization strategy suggests games are a good thing to support.  It isn’t my interest, but it will attract people.

The other area to support strongly is microblogging and publishing of photos.  Now this is harder – why blog on a platform which no-one uses?  My answer is we make it better, and we make it easier to share.  Anyone can read things you publish to the world (and there is no reason why you can’t syndicate such content to other social network feeds, along with a linkback).  What if you just want to publish to a small group?  You could always use email to share your content.  Not just to link to our site, but to share what you are writing.  We have no need for people to come to our site – unless they want to use it to publish – so why not work on making the mailbox the hub of the social experience?  Of course, people are not going to want your tweets in tiny one line emails, so how about trying to create some sort of ‘what I’m up to’ life journal digest you can send out.  Tweets for followers, longer blogs & photo albums to email readers.

Of course, any email address we send your digest to, we remember.  If you come to our site later, and log on with that email address, it will be pre-populated with all the people who have sent you their digests.  Because each email would have to offer you the opportunity of turning the digests off, the link to do this would encourage you to log in with your email address – and show you what is available.  You might also consider allowing the links to take you directly to your own page (in the zero-login, cookie only, format I described a few days ago… this might have problems though, as I would suspect these links and emails might be very forwardable.  That said, commenting by replying to emails, facebook style, would have to be supported.

This wouldn’t be an overnight success – but it would provide a pathway to something which could grab people virally, and wouldn’t require people to use the site themselves unless they wanted to.  And to get people to want to use the site?  Well, it would simply have to be better for them to use than Facebook - and given how hard Facebook seems to be trying to drive people like me away, that can’t be too difficult.

 

Rethinking Social Networks : The App.Net move

Social Network

Social Networks are high in people’s minds right now.  Twitter is annoying its developers, trying to become an island rather than the convenient platform it used to be.  Facebook is a mess, a jumble of confusing options, an unfriendly interface, and adverts jumping out at every corner – it reminds me more of the pre-Google Altavista than anything else.  And there is reaction to this.  The Diaspora project seems to have gone nowhere, but newcomer App.Net has hit a kickstarter target – and, by getting enough people to make a cash commitment has become interesting.

App.Net makes two points:

  • At the moment, the customers of social networking sites are not the users, but the advertisers.  So long as the users are tied in, they will remain, and their eyeballs will be able to be exchanged for the contents of advertisers wallets.  A social network designed for users needs to be funded by the users – they need to be the customers
  • What makes a social network work is when it ceases to be a website and becomes a platform

Its worth describing two geek fallacies before we continue:

Fallacy 1:  Any good internet project is distributed in nature.

This is the flaw of Diaspora.  Geeks love us some hard distributed systems problems, but the take away from the user the simplicity of going to a single place – the same place as everyone else – to get what they want.  Distributed technologies such as social media require people to provide servers – but these servers have to be paid for, so people will charge.  Charging isn’t too bad, except any such server must, by its nature be a commodity, there is little room for differentiation.  It is hard to see why anyone would want to get into this game – see the decline of usenet servers as an example.

Fallacy 2: It is all about the platform

UIs are for wusses.  What matters is the clever technology underneath.  This is both true, and false.  What matters to must users is that users get the features they are looking for – it doesn’t matter if the backend has some hyper-clever architecture or runs in Spectrum BASIC if it does the job and keeps out of the way.  Geeks think differently – they want to know that their lives are going to remain easy as they interact with the system over time, so they design platforms which you can build good products on top of, but don’t care that much about the product.  I fear this might be what app.net are doing.  I hope I’m proven wrong.

Where app.net have been clever is in using Kickstarter for some cash.  Not because they needed the cash (if you can convince that number of individuals to pony up $50, you can probably convince some investors to do likewise).  Getting the cash gave app.net some publicity, because Kickstarter is hot right now, and social networks are causing consternation – and for a social network to get going, it needs publicity.  But it also got a number of people to tie themselves into the service – and the sort of people who would fund a new social network are early adopters, the thought leaders in the social sphere, and this could be very important to app.net’s growth.

But it could be more important to the people who paid for the developers licence.

Right now, if I wanted to try something new and interesting in the social world, I would seriously consider tying it in with app.net – because its a small market of exactly the sort of people you want playing with your fresh idea.

I don’t think there is anything special about app.net in itself, but I expect it to be a breeding ground for interesting social graph based applications.  So in app.net’s case, perhaps by building the platform, they are doing the right thing, even if it isn’t the right thing for them.

Incidentally, I have a number of thoughts about the next moves that could be made in social networking – I’ll be writing about them over the next few days.

The Horse

Andalusian

Even if the fall doesn’t hurt, it can be hard to get back on the horse.

Lots of things take time to become a habit.  There are lots of things I do frequently, which are not yet habits.

And sometimes, for whatever reason:  Stress. Overwork. Tiredness. Something new that interests me.  Boredom. I stop doing them.  Not because I don’t enjoy them, but because the take something like time, brainpower, energy, willpower that I don’t have enough of.

These things.  Things I like.  Things I enjoy.  These things seem to be the hardest things to start doing again.

To start doing these things again is making a statement ‘this time I’ll stick with it’

And that statement carries the hidden statement ‘and if I don’t stick with it I’ll be a failure’

Which is a shame, because I can’t do the things I like, because of the potential to fail.  Whereas if I never do them again, I’m not so much a failure as a tormented genius with sooooo much potential.

So failure seems to be a better route than being the sort of person I would dismiss with sarcasm.  I will let myself fail at most things, if it means I can succeed in having fun – or just the occasional feeling of success at not having failed yet.

I will get back onto the horse.

I will lose weight.

I will write more.

I will try to knock a few entries off the list of things I could do right now if I had the energy

(I tried horse riding once, I didn’t enjoy it.  The horse in this post is metaphorical.)

I will fail at some or all of these.  That isn’t the problem.  Because the joy isn’t is getting to the end.  It isn’t to say on my dying day ‘ha-ha I stuck with it all the way.’  The joy is in the process.

 

Turn on, tune in, log out

British biometric passport

I hate logging into websites.  And I’m a master of it.  After a number of hassles with external websites revealing my passwords to the world, I now have a lastpass setup managing my login credentials and a google authenticator to keep my google identity (which is probably more important than my birth certificate) extra-secure.  And does this work?  Well, most of the time, but the other day I got logged out of a banking account and had to reregister because I got my details wrong 3 times in a row.  Was it my fault?  Well, maybe, but I don’t for the life of me know what exactly I did wrong  - or how I could avoid doing the same things wrong in the future.

I also hate writing login mechanisms for websites.  They always seem overly complicated – the sort of thing you wish could just be done better by someone else.

My first experience of a half-decent login system was with tripit.com.  With tripit, all I had to do was start forwarding emails to their email address.  I got an email back telling me I could go to a magic URL, where all my details were awaiting me.  But then it asked me to set up a password to secure it all.

On most websites, it doesn’t matter who I am.  It only matters that I am the same person I was last time I came to the website.  Why should I have to log in?  In fact, a lot of web sites recognise me and log me in automatically if I’ve been there fairly recently

So, Idea 1:  Instead of making me sign up to a website, just assign me a cookie, and then whenever I come back in – in a day, a week, or a decade, read that cookie, and log me back in.

This is simple.  It is session management.  Website writers are going to have to do session management anyway, so why not just have two sessions – a short term ‘is currently doing a particular thing’ session and a long term ‘is still the same person’ session.

There seem to be two big problems here:  Security and Multiple Browsers

The security problem is that cookies remain the same and are passed in plaintext.  This can be resolved, in part, by making all connections via https.  All the evidence seems to suggest https-only is the way to go for lots of reasons, so this is no big loss.  As for cookies remaining the same – well, the website can always decide to change your cookie on its own schedule (so long as you log in).  And because the cookie will be website generated, it will only ever work for that website – and if that website gets hacked, well, they probably have access to everything you stored on that site anyway.  No no huge risk, so far as I can see.  (we could probably do more complicated things like making the cookie you provide a public key, and making session initiation a challenge response procedure, but that probably isn’t needed)

The multiple browser issue is harder.  If I want to access the same account from two browsers, the cookie generated account issue is a problem.  Different cookies will be generated for each browser – meaning you are a different person at work and home.  There are three ways around this:

1 – add the ability to set a username and password to your account once you have logged in.  Let people associate different browsers with the same account by then loggin in with the username and password.

2 – add the ability to associate an email address with your account.  You can then request the site emails you with a way to log you in on other machines.  Since you’ll need to do this if you have the username password mechanism, you’ll proably have to do this anyway

3 – make the problem your browsers problem.  Come up with an way of identifying the cookies as shareable, then let your browsers choose a central location to allow them to be synched.  This is ideal as it also allows browsers to let you switch between multiple accounts with the same site.

So – this seems quite simple, but it seems you still need to write code to register an email address with your site (at least until all the browsers come up with a solution to synch cookies).  My suggestion here is:

Idea 2: someone needs to generate a web service which will manage the storing of email addresses and associating them with an internal representation of user ids.  All your site would have to do for registration purposes is provide a form which sent the email address and internal id to said service.  When a user wanted to receive a log in email, you would have to provide a simple request whereby you provided the email and your sites id, and got back the internal id.  You would then look up the id, then generate an email which would lead the user to a page which would allow them to access their long term session cookie.

some bonus ideas:

Idea 3: if I send an email from my valid account to ‘logmein@whatevermywebsiteis.com’, it should, by return post, send me an email that would log me in – meaning I wouldn’t have to do any setup work’

Idea 4: You could happily sign up with multiple email addresses.  The site should only send to the email address you request.

Idea 5: If you lose control of an email address, you may need to revoke it.  The best way to manage this would be to allow you to revoke all email addresses, then let you assign them again one by one.

xoxco makes a similar argument (which didn’t so much inspire this piece, as made me think there was probably something up the tree worth barking at)

© Ben.Cha.lmers.co.uk
CyberChimps