Skip to main content
 

The tyranny of content types #indiewebcamp

I've been thinking this morning about content types and granular access permissions (which, it turns out, is ground the IndieWeb community has already tread).

Activity Streams is a data syndication format with very granular content types, which is awesome - unless those content types dictate the kinds of content you actually allow people to create with your software.

Why should a content type be strictly a note, or an article, or a place, image, video, application? One of the amazing things about the modern web is that we can combine content types to create experiences that are richer than the sum of their media parts.

At the simplest level, I want to be able to (eg) include a photo with a checkin. But why not construct a post that's a photo followed by some audio followed by some text followed by an interactive widget followed by a non-linear video with an interactive layer on top of it? One of the neat things about the is that you control your platform - and that should mean controlling the form of your content too.

Watch this space ...

· Posts

 

Centralizing my digital trail into a single #indieweb stream is making me think about what I post.

It shouldn't be surprising. I've been on the web and posting on the Internet since 1994, but posting in the usual way scatters my data all over the place. Short status updates end up on Twitter; longer, more personal ones on Facebook; checkins on Foursquare; photos on Flickr; audio on Soundcloud; etc etc etc.

My site here at werd.io is an attempt to change my posting habits from being silo-first to more of a approach: Publish (on your) Own Site, Syndicate Everywhere. Now, all my status updates, posts, photos and checkins are here in one place, on a server that I own running code that I write, and copied to all those other sites.

It's made me think about posting much more deliberately.

A friend of mine often says that you shouldn't publish anything on the web that you wouldn't be happy seeing on a billboard. I don't think that's true on the whole web - for example, at latakoo we're building tools to make sending, storing and sharing private media content (video, audio, images, large data files) easier, including a self-hosted enterprise option that federates with our hosted .com site. But for the free, public, social web, it definitely makes sense.

This morning, I checked into my office, and then I checked into a local BBQ joint for lunch. Do I really need to share that? Possibly; possibly not. It's my choice, but at least having all this content front and center allows me to make it in a more informed way. I'll probably check in a little less often, except perhaps to announce my presence at venues for special events (like IndieWebCamp this weekend) or to "tweet" links to resources I think are interesting.

This is all new, and my thoughts on it are still baking. Having one stream has certainly made me think about my identity online in ways that I haven't for years. Maybe I'll maintain several identities? Run an anonymous site for frivolous checkins or photos of my latté? The jury's still out, but because I'm empowered to run my own platform, the choice is all mine.

· Posts

 

I don't get why you'd use markdown to blog on your own site.

Markdown is useful: an easy-to-use notation system that allows you to mark up your text in a safe, fast way.

Because you're never letting your users write raw code, there aren't any worries about them posting malware or exploit attempts, or accidentally writing bad markup. At the same time, simple lines and dashes are converted to valid HTML. Everybody wins.

But when you're writing your own site, you don't need to worry about those things. You don't care about you posting malware or exploit attempts. (Either you want to, or you won't.) You also don't need to worry as much about bad markup - and if you're not proficient in HTML, you can install a WYSIWYG editor, like the one in WordPress. Unless you're a Dr Jeckyll who morphs into an id-like alter ego without warning, you don't need to worry about your own trustworthiness as a user of your own system.

On a self-hosted site, all does is restrict what you can do. It has a syntax to learn, just like basic HTML does, and because you actually have to keep in mind which HTML tags it uses when you write it, it's actually a little bit more complicated to remember.

I like a lot of the goals of new publishing platforms like Ghost (I backed it on Kickstarter) but this feature sticks out like a sore thumb to me. I'm not at all sure this is the best writing experience on the web. And I don't see what's wrong with HTML.

Updated to add: I've had lots of feedback by people who point out that they just want to write text, not HTML, which is more than fair enough. But surely this shows demand for a smarter, context-sensitive rich text editor rather than another syntax to learn. Why couldn't an editor know to start creating bullet points when you type an asterisk and a space at the beginning of a new line?

· Posts

 

Owning your data is cool - but having your own awesome site is cooler.

There's been a lot of news stories lately about how technology companies like Google, Apple, Microsoft and Yahoo! may or may not be giving your data to the as part of a project called . They deny it, news outlets confirm it and it's hard to tell what's real and what isn't real.

Whatever your political views, or whether you think government entities should be able to snoop on your phone and electronic communications, it's hard to argue that the sheen hasn't come off the consumer Internet industry. As the economist Umair Haque said earlier today:

The large online services have created a world where, despite the breadth of software's possibilities, the scope of our communications are limited. On Facebook, you can post status updates, links, photos and videos; on Google+, you can post status updates, links, photos and videos. What if you want to post a game, or an interactive multimedia presentation, or a live graph connected to real-time data?

Those things are hard for centralized services, because they've got to concentrate on common denominator forms of content - like status updates and photos - but they're much easier when you control your own site. If you could install your own publishing app as easily as an app on your phone, and then add new ways of posting stuff to that site just as easily, suddenly you would be able to make your presence on the web your own. And you could let other people in - you could create online communities that fit your needs, rather than bending your communities around the limits of a Facebook group or a mailing list.

That's what inspired me to start working on idno, and these are some of the ideas that inspired other people in a community of developers called the to build their own sites and platforms. We don't believe in treating people as data points; we believe in user-centered software for individuals. Software that you control.

will be available to install onto your own site later this month; a turnkey hosted version will follow. In the meantime, if you're a developer, you can check out Idno on GitHub, or some of the other IndieWeb projects out there.

Won't you join us?

· Posts

 

#indieweb checkins; trying to decide the best approach

Map readersI've been self-publishing my photos and status updates for less than a week, but I already wouldn't do it another way. Idno lets me post easily from my phone or laptop, and the updates show up on the sites I'm connected to. Right now, that means Twitter and Facebook, but sites like Flickr and LinkedIn are coming. (This is all available as open source code, by the way.)

Technical aside: when I post something new, it gets an Activity Streams object type and verb. Status updates are notes, blog posts are articles, and photos are images. Plugins then listen for when new, public content is created with those object types (and, right now, the "post" verb) , and syncs them to third-party sites as appropriate. That way someone else could write a better status update plugin than mine, and nobody would have to rewrite the plugins that synchronize content.

The other silo that I use all the time is Foursquare. Theoretically, taking the user's location isn't hard - did I mention I'd written a book on Javascript Geolocation? - but in reality, this is harder than just grabbing the user's current latitude and longitude and saving it to an Activity Streams place object. Foursquare maintains an extensive database of venues, that's so good that a bunch of third party services use it as well. I don't really want to have to duplicate that.

There are alternatives: OpenStreetMap has a downloadable free software database of locations. The downside is that you need to extract points of interest yourself - and the database, perhaps predictably, is over 28 gigabytes. That's far too much data for most individual sites to be handling themselves. It's certainly not something I'd like to deal with on my personal server.

For me, the perfect use case is this: I click "check in" in idno, the browser grabs my location, I'm presented with a list of nearby points of interest and I select one. The content is saved locally and then synchronized to location-centric services like Foursquare and Facebook Places.

Now, I could use Foursquare's database to populate that list of locations, but somehow that feels unclean. The purpose of me self-hosting is to own my own data, and using that database would make me dependent on Foursquare's service. Also, the flip-side of that also makes me uncomfortable: if my purpose is to put less value into Foursquare's service instead of my own site, I probably shouldn't be using the database they put so much investment into.

I'm not sure anyone else is syndicating their location to sites like Foursquare from their own sites, but if they are, I'd love to hear from them. Until then, I'm considering writing the simplest possible shim: a geolocation plugin that takes my physical location and lets me save a "hint" along with it, that will act as a way to gently nudge the third party synchronization plugins to pick the best venue. The hint wouldn't be publicly displayed, but for example, I could type "amendment" when checking into one of my favorite brewpubs in San Francisco, and that'd be enough for me to be checked into 21st Amendment on Foursquare.

Speaking of which, time to head over the bay and grab a pint ... Sadly, I won't be checking in just yet.

· Posts

 

A new website running on a new platform

idno.pngI just installed a vanilla configuration of idno onto my new website at werd.io.

idno is a personal attempt at building a publishing platform that adheres to IndieWeb principles: own your own data, publish on your own site, use existing social websites for dissemination but not as an origin. I've also tried to use microformats where possible, allowing every page to contain lightweight semantic information, as well as making it skinnable, extensible, and social.

I also wanted a chance to think about platform design again, separately from my work at latakoo (where I'm CTO) and informed by my previous work on Elgg (which I helped start nine years ago). What would I do if I was building a platform from scratch in 2013? How could I make it more useful?

I'm proud of the results so far, and the decisions I've made. Here are some highlights:

idno is based on Activity Streams, and every page is an API call

If you visit the front page of the site, or click on any user profile, the feed you see is an Activity Stream (albeit rendered to HTML). You can easily toggle a JSON version by setting application/json to be your web client's accepted type. There's automatic RSS, of course, too. And if entities have attachments - for example an uploaded file or a photo - the RSS items have automatic enclosure tags, as you'd expect. (That means idno can host podcasts and deliver other files via RSS.)

The system is designed so that all plugins automatically have an API without having to do any extra work. I'm also planning on implementing HTTP signatures, or something like them, to authenticate seamlessly in addition to standard sessions.

idno uses HTML5 (and Bootstrap, jQuery)

HTML5 needs no introduction or reasoning. Bootstrap is a very handy set of rails for responsive front-end design (with lots of pre-existing themes), and jQuery is an integral part of that. On top of that, idno bakes in some useful features behind the scenes - like autosaving works in progress using your browser's local storage, for example.

idno runs on PHP 5.4 with a MongoDB back-end.

PHP is a controversial decision, but it remains one of the most widely-deployed web scripting languages in the world. Version 5.4 is old enough to be installable on most servers, but new enough to contain some really neat features. Idno makes extensive use of the JsonSerializable interface. (It also uses a lot of 5.3 features like lazy loading and namespaces.) MongoDB, meanwhile, means that we don't have to force plugin writers to maintain schemas, nor to emulate NoSQL in MySQL, which has been a tactic I've used in the past. So far it's performing great, and it also provides GridFS, a useful file store.

All of this a work in progress, which has mostly been coded late at night, and there's still a lot to do. For example, at the time of publishing, the hashtags below aren't linked anywhere and aren't automatically marked up, but I bet if you check back in a few days, they will be. Another is that although my posts are automatically POSSEd out across the web, I can't yet posts things like replies to tweets from the idno interface. Nonetheless, I invite the brave to check out the GitHub repository (idno is released under an Apache 2.0 license), and let me know what you think.

· Posts