A single OStatus-based PHP app, marketed well, and with an easy install path, might make widespread adoption of OStatus more likely. It could even piggyback on existing WordPress installations as a plugin. Then, anyone with a self-hosted WordPress blog would be able to host their own status updates under a fixed path appended to their existing blog, such as example.com/status/. It also offers the potential for anyone with a WordPress blog to become a provider of status pages for people who didn't want to host their own (because WordPress has an inbuilt user registration system), which could create a distributed, portable network with no lock-in.
There are supposedly 60 million WordPress installations out there. These users already understand the value of owning and hosting their own content. That's an awful lot of potential to kickstart the uptake of a distributed social network, and I'm not sure that anyone's thought to exploit this yet.
Once installed, there's nothing to stop you sharing your entire posts (or snippets) as OStatus messages.
I think it could also be a branding issue. If I was building a distributed OStatus-based social network on the back of private WordPress installations, I would:
1. Market it under a different name than "OStatus". WordPress users need not know that their blog is automatically syndicated via RSS, and users of this new social service need not know that it's powered by OStatus. It is easier to market ideas than it is to market technologies and protocols.
2. Present users with an interface they're familiar with from other social networks, without stealing intellectual property.
3. Create a pretty marketing page that sold the project on its merits as a free social network that nobody owns. Give it a mascot or a bold logo.
4. Encourage the thousands of WordPress-related blogs to write about it, with a goal to drive WordPress developer adoption that might trickle down to other WordPress users too.
With the actual structure you can decide if you want to use the whole pack or only single items and the complete OStatus pack will be compatible with all single plugins/specs.
I agree that the Name "OStatus for WordPress" is not that end-user friendly... but with a better name and a better installer it should be a good start!
If someone is willing to help, please let me know... Up to now it's only me working on all the OStatus plugins (pubsubhubbub, activitystreams, webfinger, salmon, ...)
And a download option for those who have the expertise to setup their own server.
Today, I imagine the lowest barrier to entry would be to build a one-button install on one of the many PaaS's with free tiers. Heroku, DotCloud, maybe even an Amazon micro EC2 instance.
I'm proposing a button like [Create OStatus server]. It goes and provisions you a Heroku or DotCloud or Amazon account, creates an instance with everything installed, you get a link. Done.
We can make it way easier than installing Wordpress. The account provisioning part is tricky but all it takes is a good will partnership from one of the many PaaS providers, in exchange they get to upsell the owner to beefier paid servers.
I think the secret weapon in the OStatus arsenal is that there are literally hundreds of millions (literally HUNDREDS OF MILLIONS) of PubSubHubbub-enabled feeds on the Web.
Blogger, YouTube, WordPress.com, Tumblr, and Posterous as well as StatusNet and Diaspora* all provide PuSH-enabled feeds. That's a huge body of content to follow in real time.
Another good part is that PubSubHubbub will help with SEO -- Google Search bots subscribe to PuSH-enabled streams, which gets you indexed faster. Lots of incentive is good for getting things done.
There is distinctly lower support for the other parts of the OStatus stack. But I hope we'll see this stack continue to develop.
They launched there first Alpha Status App that's build on top of the Tent.io protocol: https://tent.is/
If you like to get more information about the Tent.io protocol, checkout: http://tent.io/
Of course, they were kind of obvious additions and Twitter does them too now. Status.net also had a very handy, very slick XMPP interface, perfect for those of us who don't like to play "where's the setting" on a website. Unfortunately that got taken down with the upgrade to Status.net 1.0, and hasn't yet returned.
I personally run https://freesocial.org/ which is based on the StatusNet software.
Third-party clients have, however, not implemented StatusNet support despite the fact SN has a Twitter-compatible API. _That_ is something I don't understand why.
The activity can be small status messages like Twitter - but can also be anything else, like photos, check-ins, whatever. So in that way it's much more like a distributed Facebook than a distributed Twitter - but right now the existing clients out there don't really show that very clearly.
Let's not forget that Twitter would have never been that successful without its developer community. If you can attract developers to rstat.us, then you will probably attract more users over time.
Disclaimer: I have no idea if this can be implemented.
There is some interesting work along these lines from the founder of StatusNet going on in https://github.com/evanp/activitypump
A UI mockup of a client that would read from the 'pump' is here: http://statusnetdev.net/inbox.html
FYI: Today, Tent.is -- the first implementation of Tent.io, a protocol for fully decentralized social networking -- went from 0 users to 2000. In a day.
...And since it's free, I bet it'll grow MUCH faster than App.net which, after TONS of media coverage and endorsements from the likes of not just Scobleizer, but The Washington Post and even fucking CNN(!), got just ~12,000 people to sign up by the deadline.
Specific sites aside, I'm glad that people are actively creating alternatives to the centralized, corporatized, developer-unfriendly services that currently dominate the landscape.
Adoption for a user is tied with friends' adoption. Most users won't see any interest in switching from Twitter/Facebook to a decentralized network, because they don't understand the importance of privacy and controlling your own data.
Anyone with the plugin would be able to connect their network into anyone else with the plugin. I would imagine it could be done with openid and xmlrpc.
They also have visible half-conversations with a similar number of other people whose tweets are “protected” so that only “confirmed followers” can read them. I don't see OStatus doing anything with the latter, and I don't think those people are going to move to public streams, and if they don't move, the other people interspersed with them won't move because it'll become impossible to talk to them. This is more or less the same reason I still reluctantly keep a LiveJournal: the open-Web facilities for “but only show it to these people” are severely lacking (and I haven't found a good way of doing anything about this yet).
There's also the issue of social networks including things that are de facto currency-like: “number of followers” on Twitter is an obvious one. In a distributed network these usually can be faked, or at least are that way on the UI side since it's hard to generate a UI for that that doesn't drive the user's security-related cognitive load through the roof. (Or reveal more information about subscriptions than people prefer, but that's a shakier reason since some existing networks already reveal that graph.)
Is there any push for OStatus or other distributed social network approaches to handle these use cases? I haven't been able to find any, and OStatus seems to think the restricted stream case is explicitly out of scope.
I personally though would prefer to have the main use case - the one with just public data - work first and learn from that and get that rolling before moving to the more complex stuff.
I'm tempted to compare to how deploying new transport protocols over IP is nearly impossible for consumer clients now, because everyone's built NATs that assume TCP and UDP, because those were the common cases and therefore the important ones and now anything else is instantly hosed. It's a bit of a bad example, though, because in the case of transports there are other reasons as well.
Google Plus seems to have achieved this fairly well. I haven't had the time to take a look at their API yet, but I can't imagine it's any less than what LJ provided.
Here's another one: Dreamwidth runs an LJ-derived codebase, arguably an improved one (they had considerably better separation of “subscribe” and “authorize” last I checked, rather than a “friends list” that conflates these), and some of the people I contact on LJ have moved there, but they all have continuous crossposts back to the original LiveJournal, and if I moved there I think either no one would read anything I wrote, or else the comment streams would be so disjoined that I would be effectively a strange-looking LJ user anyway.
That last is also a concrete example of why nonexclusivity is not a complete solution. The resource that's being fought over is not where one can read but where a bunch of other people do read. If everyone views your content at Phuubaar's House of Crossposts, then if Phuubaar cuts you off, you are still hosed in the general case even if you provide the same stream somewhere else, because those users are not going to know about it or are going to find it too inconvenient to subscribe.
And the tooling around Atom and RSS aggregation all seems to be built around the idea that feeds are almost always public. I haven't had any success with the idea of creating a private Atom feed and expecting any of my friends to be able to read it. Either it'll require authentication, at which point the software usually won't be able to access it, or I can try to use a capability-URL style, at which point one of them will punch it into their favorite everyone-shares-everything social aggregator (Google Reader?) and then my (illusion of) confidentiality is gone.
This is terrible, and I don't know how to fix it.
It's really painful working with Twitter now. Twitter's display 'requirements' and other aspects of the API are super restrictive after their latest update.
However, the sad truth is that the population of Twitter users isn't going to be shifting anywhere else anytime soon. Most users hardly care about the 'openness' of the platform. I imagine the best way for a competitor to succeed would be by allowing users to cross post statuses to Twitter.. but Twitter API restrictions would kick in there too!
The reason Twitter is popular is because there's a large active community of users and they do a good job of enabling you to discover and follow people you're likely to be interested in. It doesn't really matter how "open" it is, any more than it matters if Facebook or Tumblr are open.
WordPress works with a distributed "install it yourself" model because people use it to power their websites and they want configurability and extensibility. With social networks like Twitter, they want community and baked in support with devices and other services.
"@example.com/abc" is one (not particularly nice) way of doing it, but I'm struggling to think of any way that would work nicely.
The obvious 'let's use email instead of that @you thing' would make implementation really non obvious, because it dramatically changes the @ role from the current usage: @ means 'adressed to', not 'residing at' like email/xmpp.
I'd reverse the order, which would read much better and follow known ordering conventions (FQDNs, email...):
email tag syntax inspired: @abc%example.com. That would be @marcoarment%twitter.com and @marco%app.net.
FQDN inspired: @abc.example.com looks much better. That would be @marcoarment.twitter.com and @marco.app.net. It would follow the convention that a non qualified name belongs to the local net. I don't know how that could possibly extend to actually integrate with DNS itself, so that a something-record @marco.marco.org. would resolve to the service handling marco's status stream, MX style.
You will soon be able to use your own domain names so ^https://example.com will be possible.
This kind of works. Ideally I'd like to drop the leading @ but I guess that'll be hard to do.
We could go oldschool with a newline:
More seriously, I wish there was an easy way to divorce the username from the server similar to how DNS works so I could move my provider without losing my identity. A separation of name providers and service deliverers would do this.
Also, do we need names to match domain names? Couldn't we start from scratch?
It would be interesting to see what we could come up with if we dropped .com, .net, .org, .name etc and went for something more abstract.
.blue .horse .cheese .bang
That domain does not have to be the server they use for microblogging or whathaveyou. It shouldn't be, honestly. You can host your identity anywhere and point to the microblogging server using a link.
So, I can be email@example.com, as familiar as an email address which is REALLY important for usability; the UI can drop the domain if you think it is ugly or hinders readability, and we go on from there.
This is what webfinger + xrd gives you: http://code.google.com/p/webfinger/wiki/WebFingerProtocol
It's already used by status.net, rstat.us, etc etc. tent.io ignores it and wants to reinvent everything.
Now I can switch microblogging sites if I want by just pointing to a new one. But, just like changing your name is a hassle in real-life, changing where your identity is held is also hard. Using DNS and having your own server for at least your identity are ideal.
What's wrong with firstname.lastname@example.org?
Using the same means of locating a person seems very very reasonable from both a technical aspect (it works for them just fine) and from the viewpoint that people already understand that an email address represents somebody's online presence and this is how you can communicate with them. Concept familiarity is extremely important for adoption, so that should be considered.
I've shared my thoughts on distributed social networks here http://web.bozho.net/?p=235
Users can be migrated, although it is easier if the identity is separated properly. Webfinger does exist to solve a lot of the migration headaches by allowing a well-known place to link all of your services to a common identity. You want to migrate? Just link to that new service. You then have to multicast some announcement, which is the hard part, and messy... but possible. Webfinger is usable from status.net, rstat.us etc etc... but they also allow you to host your identity with them.
Your privacy argument thus holds true for email as it is a pull system where your email can be read by any intermediary server. You solve this problem in both instances with keypair encryption. The problem is not a technical flaw (closed, centralized systems are opaque about your data, which can be seen as worse.) but rather a flaw in presenting and educating people to use secure practices if privacy is desired.
I agree that DiSo apps need to have built-in continuous backups and migration support.
We built ScoopSpot to make microblog better, one of the core proposition was to allow the application developers work with the statuses more openly. However, it didn't caught attention of the people. One interesting aspect of ScoopSpot was to allow user follow a tag or topic.
The possibility of application built on what users' interests are limitless (at least that's what I think). I will look into the protocol of OStatus to see how can we make our API's open.
What gives? End of the hype?
People use twitter because other people use twitter.
An open service doesn't solve that, it just makes things more complicated and worse.
Wordpress works because it's not a network platform, it's a publishing one. Wordpress is inherently not a social network, it's a CMS. Sure, there are social bits, but it works well as an installable thing because you don't have to deal with issues like connecting or discovering other blogs. You can just install it, write content, and hit publish and boom, you're publishing on your own site on the net.
The only people who see a problem with Twitter right now are devs, not users.
All the "open twitter" projects are going to turn out the way of Diaspora, not Wordpress.
You're a government agency (lets say, state of california), and you have hundreds of departments and thousands of messages:
Would you rather register a twitter username for each department? Or would you install a StatusNet instance for each organization and let them maintain control?
Edit: I tried to post from my status.net client choqok and it failed with "Creating the new post failed. The result data could not be parsed.". Is the api url https://rstat.us/api ?
Full Disclosure: I know the creator, not by person but on the Net
Edit - Personal preference
This is much the same. Who knows the types of exciting tools it might spawn?
existing apps that have already solved the problem
Obviously Twitter doesn't solve it for everyone, otherwise you wouldn't see these sort of efforts.
Neither Twitter nor Facebook really tread virgin soil, either.