WordPress(.org) is one of the few open source projects to have encouraged large numbers of non-technical users to download, setup, and host their own serverside software. I think the Ostatus "movement" could learn a lot from it.
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.
That plugin's a good start. It's only been downloaded 708 times, though, possibly because it's not being actively developed or promoted, and perhaps also because it has a long list of dependencies that would make setup too hard for most.
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.
I agree with all of your points! I started to build it as a pack of loosely connected plugins, because thats what OStatus is... a pack of combined open protocols...
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, ...)
FYI, there also seems to be a drupal plugin: http://drupal.org/sandbox/sanduhrs/1132580 - but it seems to be experimental at the moment. Also, I did not try it out myself - yet.
What if you could one-click deploy to Heroku, OpenShift or AppFog? OpenShift can even have multiple competing hosting providers or you can use the free hosting from Redhat (which includes a LOT more resources than Heroku's free plan). And of course you could still do the traditional dedicated/VPS type installation.
I wasn't that familiar with Azure, but I had heard that they had Linux VMs now (which would be one option), but I did a little digging and it appears you can actually run RoR apps on the Windows side as well:
That covers the convenience factor well, but not the cost factor. Heroku's great for the right kind of app, but no-one would have heard of WordPress if it required a Heroku install.
I suspect the necessity of the PHP path may be outdated.
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.
Most blogs still run on shared hosting primarily for reasons of cost and a lot of people have existing shared hosting accounts that allow them to host multiple domains. If you're looking at individuals (the majority of whom are not typical HN readers and haven't gone down the PaaS path) installing this, it still makes sense to go LAMP.
Maybe within the HN ecosystem, but there are 10s of millions of wordpress installs running on the web. I would imagine only a very very small minority of said installs has any idea what a PaaS is. Those types of people are install wordpress on their $5/month hostgator accounts all day long because of stuff like fantastico making it a one click process as well.
Maybe I was unclear but I'm not asking to educate people about PaaS.
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.
Evan, I think right now most people are getting distracted at how OStatus would benefit the end-user that they fail to see how the protocol/service stack benefits organizations.
I would love for this to work, but "like X but open" is not enough. What you need is "better than X and open". I wish I knew how to do "better", but unfortunately, I don't.
Status.net was 'better than Twitter and open' for a while; as I understand it, Status.net was grouping together threads of replies, and handling @mentions in the body of a message (as opposed to only at the beginning) long before Twitter did those things.
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 don't see the user experience on Twitter being on a par with neither StatusNet nor any of the third-party clients out there.
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.
Technically it's much more than Twitter - it's a way to subscribe to activities in realtime (Activity Streams + Pubsubhubbub), a way to easily do so for users on a website (WebFinger) and a way to notify people of others activities which they are being part of (Salmon).
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.
Giving developers an environment they can play with and build great products around is the best way of achieving success.
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.
But that developer community is a given if you are making a competitive or alternative service to something like Twitter. It's a prerequisite, not a bonus. I would argue you're still not giving the users enough of a bone.
How about adding context (e.g. similar to wordpress's category tags). People can then filter the streams they subscribe to.
For example were YouTube to post an OStatus message when a new video were uploaded I could subscribe to GeekAndSundry@youtube.com's messages, then filter that subscription so that only those posts with categories TableTop and TheFlog came through, without seeing posts tagged DarkStarComics.
Equally, if a user posts about their two hobbies, say Technology and Cycling, I could filter to only see their Technology posts, reducing a lot of the clutter in my feed.
Like twitter or facebook but open, decentralized, and unarchivable would be nice. Something along the lines of Off The Record (not google talk's) where users could disavow messages from their account manually or automatically after x number of days. It seems like twitter is useful for asynchronous communication with a very short shelf life, as opposed to IM (synchronous) or RSS (hopefully a longer shelf-life), which would lend itself to that sort of privacy model.
Disclaimer: I have no idea if this can be implemented.
A distributed message bus seems to be the most promising model. It'll be better than 'twitter but open' through the variety of messages being passed (see the sidebar of the UI mockup below). I believe the messages being spoken will come from activitystrea.ms, but the bus itself has yet to be determined.
I really appreciate what StatusNet is doing, but I've found that it's just not useful enough to... use. It's Twitter but more free and with far fewer users. That's rather different from Diaspora and Tent.io's visions.
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.
Even if tent.is now has 2000 users (including myself) over 24 hours, it does not mean that it will reach 12,000 people. With this kind of projects, people tend to subscribe, play with it a few minutes and then forget about it.
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.
Tent's success is far from certain, of course. Sounds like you're convinced that just because something might not happen, it almost certainly will not. Also a fallacy.
WordPress already has the complete infrastructure and adoption needed for a social network. The only missing key is interconnecting them, why the need for a separate platform? app? It's all in place. Only a plugin is needed.
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.
I have a large chunk of friends and acquaintances who now conduct their ongoing visible conversations with each other almost entirely on Twitter, many of whom have started becoming impossible to reach by other means.
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'm not commenting on whether OStatus will ever have these features. I'd like to just point out that what you're describing is absolutely disturbing. I'm talking about the part where you said that these people cannot be reached the other way and conduct all of their conversations on Twitter.
Well, let me clarify just in case: the “impossible” is an exaggeration, since they will eventually respond to things like email, but it's not enough to keep up. Many of the socially-important multicast messages only occur on Twitter. I've been meaning to subscribe to them with a local aggregator, since for those whose tweets are publicly visible that should be sufficient, but while my existing RSS links still work, I can't find any way to acquire new ones, so right now I'm reduced to manual polling.
I had not! That appears to work for now, though I'm not convinced it will continue working if Twitter continues going the way they are. For some reason that didn't appear in my search; thank you.
Has there been discussions about handling private data in Private content? Yes - and there have been efforts in making that possible in OStatus, but since OStatus itself is just made up of other specifications it currently awaits those other specifications to get extended in a way that supports this - not sure what the current status really is.
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.
Sure, but you have to be careful of the gradual lockdown effect as more people get involved. The handling of non-public information is a cross-cutting concern. If everyone builds their software and security models around the assumption that all posts are visible to everyone (because it's the common case, and they decided, just as you're saying, that supporting the common case was the most important thing), then going back later after everyone's gotten attached to the software and trying to add private multicast without any leaks can be a nightmare. No one will be able to use it because their friends won't be able to use it unless every piece of software in between makes it work.
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.
> 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).
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.
Does that really qualify as open-Web facilities, though? Is it “show it to these people”, or is it “show it to these Google Plus users”? The latter is not appreciably better than the LiveJournal case, for me, and in fact this provides a demonstration of the lock-in effect.
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.
Does anyone know of "friend discovery" services using OStatus? Most proprietary social networks have that "let me riffle through your addressbook" thing, which I imagine the privacy-conscious would eschew (I certainly do), but e.g. my Twitter "following" list is publically available, so it shouldn't be hard to go through that and find people I'm following who are also on an ostatus-compatible service somewhere
As a developer, I would love to see this get more traction. I really would.
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!
I agree, I don't see how implementing the same thing as Twitter but with missing features (like posting via SMS) is supposed to draw away Joe Everyuser.
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.
rstat.us does let you cross-post statuses to Twitter. And most of the API restrictions have limited reading, not writing, so this feature may be safe for some time.
I think the big problem with distributed systems is how to address people. "@abc" is getting more and more synonymous with "abc" as a Twitter username, and App.net uses the same style. This already leads to confusion when they don't match (e.g. Marco Arment is @marcoarment on Twitter and @marco on App.net); I have no idea how you fix this for decentralising.
"@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.
> "@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.
And I would say that it's totally up to any OStatus client to improve on that in their UI if they want to. Mobile phones and e-mail clients rarely uses the raw numbers and e-mail addresses in their UI:s but instead uses data from eg. an address book to make it more userfriendly.
If you want to keep the @name you could always go in reverse:
com.example@abc
Although I think that would just confuse most of the world.
We could go oldschool with a newline:
abc
example
com
;-)
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
While we may end up with just the same as now (but without the .com) it might be interesting.
You need a domain to get information about a person, such as where their server is.
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 wilkie@mydomain.net, 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.
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.
It implies an e-mail address and the expectation would probably be for the provider to receive an e-mail sent to that address. Not unlike @facebook.com addresses, so it may work.
Email is a federated system just like status.net, rstat.us etc. We can all have our own clients, servers, and still interact, communicate, and play well with every other email server.
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 see a problem with OStatus that, it seems, is also seen by others - it may not be user-friendly. When a deployment that uses OStatus shuts down/fails, that's it - the users are gone. And that seems like a dealbreaker.
As another mentioned, email has this issue. Email (smtp) is a federated system, much like http. Basically, we can all have our own clients, servers, and live on our own, but still interact as a whole. Just like ostatus powered websites. It then inherits all of these scenarios.
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 don’t have time for this, I’m shutting it down" should never happen. Don't use free services with no business model and don't provide free services with no business model. Even for your friends. It sounds harsh, but it's a lesson that people need to learn IMO.
I agree that DiSo apps need to have built-in continuous backups and migration support.
We built ScoopSpot[1] 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.
[1]https://www.scoopspot.com
What ever happened to app.net? I keep waiting to see it resurface in comments related to Twitter, but it never does. Not a mention of it in any of these comments either.
From what I've seen, the tent protocol (and service) is more complex than OStatus, and capable of a lot more. To me, tent.io is more like a distributed tumblr than twitter.
Slightly off topic, but i've only just seen these Twitter API usage changes now, how are they going to enforce these new display requirements? It's surely not feasible to manually check the display of tweets in all apps?
All of Twitters API changes essentially keep the compliant developers compliant, and let them smack down the non-compliant ones that get too large. Not a lot of the requirements/agreements can be programatically enforced.
Ok, um, this is not going to work. Half of the magic of Twitter is that it's a single service, so you can subscribe to anyone, pull anyones feed into yours, retweet, share, all that junk.
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.
nope, but I can guarantee you that organizations do.
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?
Unless Twitter angers their users greatly there's not much that can be done. Twitter stands for status updates just like Google stands for search. A competing product would have to have a (slightly?) different feature-set I think..
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 ?
The client api and the backend that implements the protocol are different. I mean, you simply need html to provide a means of building a client. But, no client will really do that. rstat.us will try to support existing apis, but that's not there just yet. The backend in rstat.us does support ostatus, and can interoperate with status.net, but does not have the same api as of yet.
It annoys me that folks with a poverty of imagination are creating clones of existing apps that have already solved the problem. Another Twitter but open or Facebook with proper privacy..etc. Fail!.
This is more a protocol than an app. In the early days of computer networking lots of companies had their own proprietary email systems that couldn't talk to each other. Then an open email protocol was created and email became so much more than an interdepartmental communications tool.
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.
"X, but Y" is a perfectly reasonable business model. Almost any product isn't particularly unique, from cars to shavers to operating systems to knives.
Neither Twitter nor Facebook really tread virgin soil, either.
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.