1. superfeedr: @BarnabyWalters Pinging from http://blog.superfeedr.com/indieweb-microformats-fragments-subscriptions/ … to http://waterpigs.co.uk/notes/4T3FSd/  I get "Source URI does not contain a link to the target URI"

    @superfeedr thanks for the heads-up, it was a caching issue in — now squashed with your mention happily on my page! I need to make taproot show names of blog posts instead of/in addition to the first bit of text.

  2. Fixed a simple security hole in , uncovered unintentionally by an attack mounted ≈5hrs ago — intent appeared to be to create new user accounts, unintended result was the creation of a new, empty article.

    Hundreds of requests were made against URLs similar to these:

    • /articles/do.php
    • /articles/modules.php?app=user_reg
    • /articles/index.php?app=home&mod=public&act=register
    • /action/sign_up
    • /articles/sign_up.html
    • /articles/?page=login&cmd=register
    • /articles/tiki-register.php
    • /articles/index.php?page=register&action=register
    • /index.php?page=item&action=item_add
    • /articles/index.php?user/create_form/
    • /articles/join.php
    • /articles/index.php?dll=register
    • /articles/index.php?option=com_community&view=register
    • /articles/register.php
    • /articles/signup.php

    Presumably these URLs are compromised on other systems — needless to say they are far too ugly to exist in ! I’m unsure exactly why /articles was used as the base URL for the attack in all cases apart from two.

    As these URLs don’t exist, and will never exist, it should be safe enough to add server- or application-level filters immediately closing any requests which include them.

  3. Just implemented notifications in ! I get a native, first-class notification when I’m mentioned. Really easy to do with the notification API: developer.mozilla.org/en-US/docs/Web/API/notification

    Update: demo video!

    1. Navigating to my homepage and granting notification permissions
    2. Native notification from iTunes for comparison
    3. Notification of a new comment from KartikPrabhu (thanks for helping demo!)
    4. The notification is a proper, first-class notification in notification centre

    Not shown: clicking on the notification navigates to the source of the mention.

  4. now sports a composite homepage feed, meaning it’s not just notes which show up on the homepage, but also articles and music!

    Next up: breaking out various post types which I’ve been overloading notes to create, e.g. checkins, audio, photo, into their own things, remove the ability to create “named notes” (that was a stupid, yet well styled, idea) and figure out what to do with all the old notes which should actually be in other categories. Auto-detecting which templates to use for them should be easy enough, but I doubt I’ll be able to move them all into their new homes.

    All that old content will have to stay as notes for the purpose of URLs and querying, but in at least some cases can be styled better. Overall I’m comfortable with this, as it leaves history (and, more importantly, URLs) untouched without compromising the reading experience too much.

  5. Reflecting on 2013 with my . Biggest things personally have been making my second , moving to Iceland and meeting+working with all the great people over here. Lots of and progress, including a great indiewebcamp in September.

    Looking forward to 2014: more cooking, more indieweb progress, seeing more of Iceland, going to some gurdy festivals, improving hardware hacking abilities, connecting my gurdy and other devices to the web and each other.

  6. The other detail added to : phoning via SIP and a “Call Me” button. On desktop devices you’ll see it on my homepage in the Elsewhere section. Clicking it on a WebRTC-enabled browser will start an audio call with me if I’m logged into a SIP client.

    Next: using a Tropo app as a middleman for providing voicemail transcription and local numbers, improving/providing mobile UI.

  7. Notes vs Articles, again

    After deliberating a little about how to “do” a composite homepage feed, whether or not I should forget about having “notes”, “music” and “articles” and just merge them all, coupled with the fact that I already use notes for replies, I have reached a simple conclusion, of which this post is the first demonstration.

    /notes/ and what used to be “Notes” is now my de-facto dump for short-medium length chronological posts of all types. This covers notes, replies, checkins, short articles (basically named notes with more structure) and so on. Posts with a name live at /notes/DDD-name, those without names live at /notes/DDDSSS.

    /articles/ retains all content which lived there in the past. Going forward it might become more of a wiki, or a place for very long things like Data Export.

    /music/ will retain all it’s content, and be where I post standard musical notation tunes. Audio recordings of those tunes will be posted as audio posts with a link to the relevant tune.

    Hopefully these changes, along with improved templating (post-type-specific DOM templates here I come) will make finding, posting and reading posts on a much more pleasant experience.

  8. Sandeep Shetty: Very cool. What's the use-case though? Also is this coming of the doctrine based indexer that you had?

    @sandeepshetty thanks! I’ve wanted to plot tag usage over time for a while now to see if there are any interesting patterns. I’m not using doctrine any more, in fact I’m not even using a SQL database for indexing until I really need one — data stored in yaml files, indexed by a csv file in ~210 lines of code — see also waterpigs.co.uk/notes/4TQNY2

    When I post a note, adds one to the week counter for each tag, then I have an endpoint which makes that data into an SVG.

  9. New in : latest 3 articles and location of last checkin/location post on the homepage — hopefully some useful/interesting context.

    Next: mobile-focused homepage design.

  10. Chloe Weil:

    → An audio version of this article is available.

    I built Twitter. For the past few months I’ve loosely talked about my intent to publish micro-content (a tweet) to my site and sending a copy out to Twitter, as opposed to using Twitter directly. This publishing model goes by the acronym POSSE: Post to your Own Site and Syndicate Elsewhere.

    There are several notable reasons why people would choose to own their data. Personally, I felt liberated by the broader idea that services like Twitter, Facebook and whatever comes along in the future would be representations of me, rather than “me, elsewhere.” I hide in plain sight on other services by obfuscating my identity through a hilarious avatar, using a different poorly-considered, rarely-duplicated handle for each account, and avoiding amalgamating a community (“friends”, followees, connections, basically). I’m a serial late adopter because the idea that these things are me makes me uneasy. I still haven’t gotten to the root of this but I suppose it has to do with shame, as do all my issues.

    Implementing POSSE to Twitter also has the promise of solving the problem of neglecting my personal space on the web — this domain — which has always been my greatest hobby, and what brought me here in the first place. But what most compelled me is that I somehow find the need to build completely bespoke solutions to all my technical problems. For instance, I don’t use music subscription services because I have valuable personal metadata that is currently handled by iTunes, and the tool that I prototyped in Javascript to manage that data in the browser independent of the service, application or file is in development. I am very authentic yes.


    I spent the past three months avoiding actually building this. An autumn of procrastination included migrating my blog over to Publify, a Rails-based CMS that offers built-in POSSE to Twitter features, only to realize my incumbent CMS, Kirby, suited my needs better. I ended up abandoning my work.

    It only took a few moments to get POSSE to Twitter working. I found the action responsible for posting an item of content to my site in the code for Kirby’s admin panel and wrote a function that posted the content to Twitter using the API. But I also wanted to populate my existing 1,800 tweets into the CMS, in addition to being able to support what is modeled as an average of 1.6 items of micro-content per day. I read that this wouldn’t scale so well with Kirby, and, to my horror, it looked like I was going to have to go outside the file-based CMS and store my tweets in a database. The Kirby documentation itself recommended that databases are a better system to store large quantities of user-generated content, and fortunately, Kirby is built upon the Kirby Toolkit, which helped to subdue my nemesis, MySQL.

    I’m going to mention here that it’s important that I use tools built by people who share my values. Federic de Villamil, author of Publify, has written about data ownership and silos and Bastian Allgeier, author of Kirby, has written about and is working on a decentralized vision of the web. These are things that motivate me too. Because the authors care about the same things I do, their tools come with features that anticipate problems I’d need to solve, so I don’t waste time and hair struggling against software.

    What I ended up ultimately building, aided by a spec of sorts, is Web Design 101. It’s a form. It lives at a URL on my domain, and has a textarea that accepts 140 characters for the tweet, a text field for a URL if my tweet is an @reply (to enable conversation associations on twitter.com), and a toggle that determines whether I want the tweet to appear on my list of tweets on this domain. I would prefer to have my @replies hidden unless they’re really funny. The hidden tweets still get saved to the database and can be queried by their tweet ID, but they are excluded from the query that lists my tweets on my domain.

    When I submit the form, the API posts to my Twitter account, and the result of that request is posted to my database, which contains the full history of my tweets. The data submitted by Twitter is formatted similarly to the csv output of my archive of tweets, which is how I based my database schema. This is why I send the content to Twitter first and use the response to post to my database.

    This is the barest combination of elements hacked together in PHP, but it’s better than what I was doing before, which was posting to Twitter. And, I’m not going to proselytize, but how many of us have built a form that posts to a database, or requested that an API do a thing? That’s essentially all this is, and the details can be teased out in a couple dozen Google searches. Think about it.

    Ideally, I would like for my URLs to have the format /note/tweet_id or custom slugs rather than the query string be obvious, but, predictably, I’m having some .htaccess challenges and I’d rather kill myself. There is also some unfinished code that saves a unique hash along with the tweet so that in the future I can append a permashortcitation (new favorite word) to the end of my tweets, but again, .htaccess, and I really would rather die than learn regular expressions. In fact, “Never Learn RegEx” is on my bucket list, so I have no choice. Also, speak about destruction, but apparently I’m having timezone issues with the timestamp.

    I’m okay with all of this for now, because these are technical details (some of them glaring, yes), but I’m preoccupied by a shift in thinking. Ultimately, I would like to extend this model in order to write any length of content to my domain with the option to tweet 140 characters to Twitter, truly making Twitter an optional destination for anything, not just the micro-content originally intended for Twitter. This may help mend my mental dissociation between tweeting and blogging. But then I would be telling you all about how I built a CMS.

    @chloeweil great article and great work implementing ! Interested in your choice to use a database for performance reasons, was that prompted by actual experience or just the cited help thread? fwiw I’m having no performance problems storing >2000 notes in flat files with a CSV file index

  11. New in this version of :

    • Improved styling (still WIP, as always)
    • stream on homepage, currently just notes but will add other things too
    • content creation/editing UIs publicly viewable (take a peek!)
    • profile photo as the icon
    • complete code restructure, now using silex for HTTP routing
    • removed tonnes of nonsense framework code, replaced with small number of ≈200 line functional libraries. Clearer, easier to navigate and much more fun to work with
    • no more SQL databases — content is indexed using a custom built 209 LOC CSV index which is surprisingly speedy, and suits my needs perfectly
    • no more support for rendering content in many forms using content negotiation (HTML, JSON, ATOM etc.) — now only HTML+microformats2 representations of content are given
    • ATOM feed shimmed with microformats2 to ATOM converter
    • Pingbacks no longer natively accepted (though they are sent), using webmention.io to shim them into webmentions for easier handling

    The local maximum has been overcome, for now. There is still much to do.

  12. Had many basic software development lessons hammered in by personal experience over the last couple of years: hierarchy bad. side effects bad. many moving parts bad. undue complexity bad. inconsistency bad. SQL databases fragile. always be reducing.

    It’s amazing just how seductive complex, unproductive tools can be. Successfully overcome+abandoned:

    • Codeigniter
    • Doctrine ORM
    • Bootstrap
    • Backbone, Ember, Angular
    • Symfony Security component

    PHP remains productive and speedy (with composer, delightful dependency management), python nice with some irritations. jQuery useful when absolutely necessary, plain with small libraries loaded via requirejs handle most progressive enhancement concisely. node.js nice for some things, preferring go’s approach to async programming but still not much everyday need for it.

    Avoiding middlemen: LESS, SASS, Coffeescript. Unnecessary for most of my work, and more moving parts is bad.

    Now bothering me is the frameworky nonsense accumulating in . Need to cleanse.

  13. I just faked having a task queue for note posting tasks using Symfony HttpKernel::terminate() and it was the easiest thing ever.

    Instances or subclasses of HttpKernel have a terminate($request, $response) method which, if called in the front controller after $response->send(); triggers a kernel.terminate event on the app’s event dispatcher. Listeners attached to this event carry out their work after the content has been sent to the client, making it the perfect place to put time-consuming things like POSSE and webmention sending.

    Once you’ve created your new content and it’s ready to be sent to the client, create a new closure which carries out all the the time consuming stuff and attach it as a listener to your event dispatcher, like this:

    $dispatcher->addListener('kernel.terminate', function() use ($note) {
        $note = sendPosse($note);
        sendWebmentions($note);
        $note->save();
    }
    

    Then, provided you’re calling $kernel->terminate($req, $res); in index.php, your callback will get executed after the response has been sent to the client.

    If you’re not using HttpKernel and HttpFoundation, the exact same behaviour can of course be carried out in pure PHP — just let the client know you’ve finished sending content and execute code after that. Check out these resources to learn more about how to do this:

    Further ideas: if the time consuming tasks alter the content which will be shown in any way, set a header or something to let the client side know that async stuff is happening. It could then re-fetch the content after a few seconds and update it.


    Sure, this isn’t as elegant as a message queue. But as I showed, it’s super easy and portable, requiring the addition of three or four lines of code.

  14. So I got in-stream reply contexts showing — perhaps summaries of comments next? I like Facebook’s approach of showing the last 4, a total count and a “show me more” button, which could be implemented simply as a link to the note page initially.

    Reply context stream example: http://waterpigs.co.uk/notes?tagged=reply

    Still TODO: make the ↪ a link to the in-replied-to page, add the datetime to the title for that link, remove the in-reply-to info from the bottom of in-stream notes as it’s noise now