Category Archives: Indieweb

Posted on
by

Because I’m currently in the UK, I went along to the Indieweb Camp Oxford event today!

I didn’t really go with a plan, except to sort of see what other people were up to and help out where I could, with a backup plan of doing a bit of Known dev if I could.

In the end I helped guide some folks with setting up their own Known installs, and answer some questions about the Indieweb in general (apparently I’m a veteran now!).

Was a really fun event, and it was really great to hang out with a bunch of like minded smart people!

Temporarily location protected checkins

I had a conversation with one of the attendees, a fellow traveller, and I hit on a hopefully useful extension to the Known Checkin plugin – protected checkins.

Protected checkins will, when enabled for a post, protect your exact checkin location for 24 hours. Logged in users will still be able to see your exact location, as will logged out users after 24 hours have elapsed.

The use case here is for vulnerable people, as well as travel bloggers, backpackers and nomads, who want to share their location but not be particularly precise with the location while they’re there.

So, with this feature, you can check in to a location, but not share your precise location until much later, after you’ve presumably moved on.

Anyway, I thought it was a cute idea, hope you’ll find it useful!

» Visit the project on Github...

Posted on
by

This weekend I attended the first Oxford Indieweb camp, kindly organised by Garrett.

Day 1

Due to an early start, and not enough coffee, I had left my phone at home, and so couldn’t log into anything. Two factor auth on things is great, but I think I’ve just spotted a flaw.

Anyway.

I didn’t go with much of a plan, except to meet some techy folk. So that much I achieved.

I had some thoughts about maybe looking into federalisation – cross user login, friend/follow etc. But I also sensed this was going to likely be more than was achievable in the time I had.

During introductions, I mentioned to folk that I was a contributor to Known and gave the project a bit of a shill, since I figured it might be interesting to folk by way of giving them a head start on a few things. So, spent the day helping one of the attendees write their first plugin for it.

After a day of discussion and coding, we retired to a local pub for some more relaxed conversation.

Day 2

Rain stopped play, which was a shame. Many folk decided to stay home. Nevertheless, had a pleasant morning chat over coffee and bagel with Beverley, hiding from the rain.

After braving the shops, and meeting up with a catch up with other friends, I went home and started sketching out some federation / Vouch ideas I had after some interesting discussions.

Great weekend of techy fun, more again soon, please!

Posted on
by

The other week I wrote about a plugin I made that lets you syndicate content from a Known site to an IRC channel.

Since folk using other platforms expressed an interest, I thought I’d quickly write down how to do it for the other indieweb folk out there.

Getting started

Writing content to an IRC channel is actually pretty straightforward, I’ll get onto the specifics of what you need to do in a moment, but your first step is to collect necessary information.

At the very least you’ll need:

  • Server details: Server (e.g. irc.freenode.net), Port (e.g 6667, or better, 6697 for TLS)
  • The channel you want to post to (e.g. #indiewebcamp)
  • The nickname to use (and password if your nick is protected by nickserv)

Collect that information (or hard code it if it’s just for you), you’ll need it later.

Making a post

Posting some content to the channel after this is fairly straightforward. Obviously, if you want to persist on the channel you’ll need to start thinking about implementing a proper bot, but a single posting doesn’t need to get into that.

The basic protocol is:

  • Connect to the server on the given port, and I strongly suggest you use TLS.
  • Greet the server by sending the following: 
    USER *username* *username* bla :*username*\r\n
NICK *username*

    All the *username* bits in the first line are actually meant to be your username, fullname and nickname. For brevity, because I wasn’t writing a full client, I just used the same thing.

  • Wait for response from server. At this point the server will spit back some information about the server, and may ask you some questions. You *should* parse that intelligently, but I couldn’t be bothered, so I just wait a few seconds.
  • If you need to send a password to the nickserv, do so now: 
    PRIVMSG NickServ :IDENTIFY *username* *password*

    Wait for response (or a few seconds) as before.

  • Join your channel: 
    JOIN #channel

    and wait for response.

  • Post your message: 
    PRIVMSG *#channel* :*your message*

    and wait…

  • Quit: 
    QUIT

    and close your connection.

If you want to experiment with this before you start coding, you can connect and do the whole exchange by hand via telnet/telnet-ssl, e.g:

marcus@dushka:~$ telnet-ssl irc.freenode.net 6697
USER example example bla :example
NICK example

.... server response ....

PRIVMSG NickServ :IDENTIFY example somesecretpass

....

JOIN #indiewebcamp

....

PRIVMSG #indiewebcamp :Hello folks!

....

QUIT

Some gotchas

All in all, posting to an IRC channel is pretty straightforward, however there are a few things that can trip you up.

  • Don’t be too fast: The main issue is that if you just open the connection and splurt your commands, you likely won’t get anywhere. The server will respond, and will expect you to listen to what it says. As I said above, the best thing is to read and process this response intelligently, but you can of get away with just waiting a few seconds… obviously YMMV.
  • Nickname collisions: The above code doesn’t handle a situation where the nickname is already active on the network. I sidestep this issue by using a different username than my regular IRC handle for my syndication user, and to use nickserv to guard it. If you don’t want to take that approach you’re going to need to do something else, like parse the server response to detect the problem and present alternate nicks.

Happy syndicating!