#Owlcat exploring the hole in the porch I fell through
#Owlcat exploring the hole in the porch I fell through
I spent this past weekend at the 6th annual IndieWebCamp in Portland, newly christened the “IndieWeb Summit” (to differentiate from other camps throughout the year in the US and Europe). IndieWebCamp is a community of developers, designers, and bloggers working to help people publish on their own websites and just generally have more control over their data. A great thing about the community is everyone tries to (and is encouraged to) be pragmatic, positive, kind, and open-minded; there is very explicitly no one right way to do things. This is not the “all venture-funded corporate services are surveillance spyware selling your data to the highest bidder” crowd.
We were incredibly fortunate to have an amazing photographer documenting all three days. Having a bunch of beautiful photos to pull from makes writing about it is so much fun. Also: it was really hot. So hot I considered ignoring this advice. Climate change is being unkind to the Pacific Northwest.
On Friday we met with some other organizers for a half day of brainstorming about how to build the community and improve events in the future. This was a new thing, and was honestly maybe my favorite part of the weekend. We spent some time talking about how to be more welcoming to a larger group of people, which took on two primary aspects: how we can improve our embarrassing lack of diversity (demographic, geographic, and areas of expertise), and how we can redesign the website and chat rooms to be more inviting to people who are understandably turned off by IRC or a wall of text on a wiki.
The event itself is modeled on a BarCamp, with one day of small group discussions, proposed and organized in the morning, and then a hack day where everyone tries to implement, write, or design some small thing for their website, with demos at the end. There were sessions on webhosting, accessibility, static sites, syndicating to 3rd party services, WordPress, Camlistore, microformats/structured data, building for the long web, and lots of others. Discussions run about 45 minutes and always go too quickly.
One of the attendees was a man named William Mason, who is totally blind, and I think he probably gave us thousands of dollars worth of free accessibility consulting (it turns out our tooling — Slack, IRC, and Mediawiki — are all particularly bad for vision-impaired users). Knowing that we were mostly working on projects for ourselves or a small handful of people, in our spare time, he encouraged us to give some thought to how making our software more accessible for vision impaired users might help us make better software in general. I learned that screenreader software and movable braille displays are exorbitantly expensive (being a captive market and all), but Apple builds screenreading into their products by default, so they are overwhelmingly popular in the blind community. Also he and his partner brought everyone cupcakes 😍 🍰
Another personal highlight, bonafide tech hero Scott Hanselman came by around lunch time on the first day, and his kids demoed their hand-coded website My Hamster Blog (he and his brother will be thrilled if you visit and increment the site counter).
The demos were really impressive; they ran the gamut from debugging installations, writing blog posts, conducting surveys, to putting together the building blocks of an indieweb search engine. Ben posted photos of the demos on his website, including a particularly unflattering one of me.
For my hack I added a super basic service worker to my feed reader. By giving it a little bit of caching and offline support and a simple manifest.json file, Chrome rewards you by loading the page more like a real first-class app. I was pretty pleased with the result of a couple hours’ work, and I’m really enthusiastic about this Progressive Web Apps thing (especially for hobby projects like this where there’s no way you could write and maintain Android and iPhone apps) — which is apparently wholly separate and kind of the opposite of Instant Apps.
One more takeaway: lots of us left feeling encouraged and excited to write more long form stories/journals/articles, even if it’s not great prose.
Sometimes I leave these events overwhelmed by how much (software and social) work there is still to do; but this time I definitely left Portland energized and excited. And full of frozen yogurt.
Following Shane’s call-to-arms (to write more than 140 characters at a time) and gRegor’s lead and to spite Sandro who doesn’t want to read it, I wanted to write a little bit about day 1 of the IndieWeb Summit while it’s all still fresh.
Observation: I’m an odd mixture of excited/energized and sleepy. Keep yawning through conversations I’m super interested in hearing. I’m incredibly happy to be part of this community. And I’m proud that I get to act as any kind of “leader” within it, even though that is so not my normal mode.
Sessions were excellent. First thing we talked about web hosting and how we can make it accessible to a wider audience. Shared hosting sucks and really limits the type of software you can run; VPS requires major intense UNIX knowledge and time and effort; PaaS’s are great but still very technical and kind of expensive for people just screwing around with a personal site. I really latched on to the idea of sort of a co-op model where friends share space, and have one or a few dedicated sysadmins… sort of like tilde.club or that server your friend ran in college, with someone who’s excited to help their friends (a small group of people who know and trust each other) setup/admin/run their sites. The admin would provision and install software manually until some parts become awful, and then automate those pain points (and hopefully end up with something (re)useful). This feels like an “in”, where typically the hosting issue just feels totally impenetrable to me.
(This might be a terrible idea that will create horrible security and/or ruin friendships)
Eric led a session on Camlistore. Together with a podcast about IPFS I listened to recently, I guess I’m starting to get it, sort of? Content addressable static resources part makes a ton of sense, but I haven’t connected the dots on the mutable layer on top of that (in either Camlistore or IPFs). I’d like to learn more about that because naively I’d expect that to be the weak link in terms of longevity — You have a terrabyte of SHA1’ed data that you can check and verify, but if the (mutable) index gets corrupted, how do you find anything?
Closing out the afternoon, I found a comfy couch and listened in on a session on longevity lead by Emma.
A week or two ago Kevin Marks pointed the IWC channel to a must-read talk called Inessential Weirdness in Open Source given by Sumana Harihareswa at OSCON this year. Weirdnesses are quirks of your project, community, or culture that might intimidate/discourage newcomers. Essential weirdnesses are foundational; without them, you’d be doing a different thing. Inessential weirdnesses are everything else, losing them might slow you down or make it less fun, but it wouldn’t change any fundamental aspect of the project. She makes a point of saying that inessential doesn’t mean unimportant or bad — your weird tools (ahem, git) help you get stuff done; jargon is useful shorthand; in-jokes are part of a group’s culture.
I really like this framing. It gives us permission to defend the essential, even if some of it is off-putting to some people. And it gives some direction for where newcomers should start, and what can be hidden/saved for later.
So inevitably my question is: what are IndieWebCamp’s weirdnesses? Folks, mostly Tantek, have done an amazing job defining the essential ones on the wiki under Different and Principles. Build stuff on the web, on a site you control. Have fun. Don’t worry too much about making it beautiful or well architected, polished, smart, or automated (unless those are the things you enjoy). Don’t just talk about building things, build things!
Some inessential bits are plumbing and protocols: rel-me auth, webmentions, micropub, microformats, bridgy, etc. etc. etc. It’s amazingly cool that some of these are or are on their way to becoming Real Web Standards (TM), and a testament to the amount of thought and work people have put into them. Buuuut it’s an overwhelming amount of information, and you can do all the stuff in the previous paragraph without any of it.
The Antipatterns section of the wiki reminds me of sections of the talk where she discusses open source developers snarking on Windows. The perceived distaste for databases, client-side rendering, or XML feeds. (Like with Windows) it’s not wrong, it’s valuable information, hard-won from experience, but it could be discouraging for a new person.
We’ve definitely done things to smooth over some jagged edges. Asking Loqi “what is…” in the channel is a low-pressure way to get explanations and definitions for jargon. Aaron’s made an incredible effort to make the IRC channel accessible to anyone regardless of technical savvy. And Known provides a dead-simple way for people to use most of the indieweb innovations without necessarily being developers.
What else can we do? The last two points in the talk speak to this: 4. Build and maintain differentiated but connected spaces
These newcomer-friendly spaces are like tidepools, connected to the ocean, but calmer, where things can germinate in a gentler environment.
We don’t really have this. People of all skill levels are always welcome to come to HWC and IWC events or hang out in the IRC channel, but they’re going to hear a lot of words that don’t make any sense. Sometimes new people come to Homebrew and they demo a cool portfolio site or a blog or a little web app they’re building for their resume, and I definitely feel awkward transitioning to jargon-heavy protocol minutiae.
and 5. Acknowledge the costs
And yeah, there’s a tradeoff here. You are going to reduce the amount of time that the outreach-centric folks spend in the pre-existing expert communities. Let’s acknowledge that different spaces are genuinely, irreconcilably different.
That one hit me hard… I try to give support or be welcoming, as long as it doesn’t interfere with the stuff I want to work on. I struggle with helping people get started at IWC because it cuts into my time to write something to demo. Even just acknowledging that there are costs is helpful for me, that having Loqi and being friendly on IRC isn’t enough.
It might be interesting to try having a separate IRC channel
(I’m having trouble coming up with a good name though,
#indieweb-start (kind of a Java joke there),
#indieweb-welcome). This channel would be for
people who want to set up a site for the first time, or the first time in a while.
HTML, CSS, JS, DNS, hosting, static site generators, CMSes, etc. would all be on-topic.
For federated comments, semantic markup, etc. we’d direct them to the main channel.
There might be cool things we could do with Homebrew Website Club too. Tantek has done sort of impromptu intro/demo sessions when we have a lot of new people, and I think those are great. Along those lines, we could designate an HWC a couple times a year as an “installfest”, where folks would leave with a simple personal website. I don’t know if there’d be interest … in organizing or attending (and it may be just straight up redundant in the bay area at least)
Part of this is deciding how far we’re willing to go, how much we’re willing to slow down. I genuinely don’t know the answer to that… it’s probably a good idea to start small and to think carefully about what we want to encourage in newcomer spaces or event — If it’s just troubleshooting wordpress installations that won’t be fun for anyone.
As someone mentioned in the channel the other day, I’m a little worried that we’re doing a lot of iterating and refining existing ideas but not coming up with much new stuff lately. And maybe that’s a sign that we’re too focused on those handful of ideas (which had pretty much all already been invented when I joined IWC in early 2014). Bringing in new people (designers, writers, journalists, artists!) with different perspectives would be ideal and is the goal, but I wonder if even just opening up a space that zooms out a bit from POSSE and webmentions and semantic markup, might generate some new avenues for exploration on its own.
(Please forgive my tongue-in-cheek tone, I guess I’m in a weird mood this morning.)
I want to argue that, in its current incarnation, \Idno\Entities\ActivityStreamsPost is wholly redundant, and makes every interaction that involves it significantly more complicated.
The most egregious example is rendering a feed. Currently we do these lookups to render any feed:
If there were no ActivityStreamsPost intermediaries, this whole thing would be done with 1 DB query (the first one), rather than 1 + 2N queries. Just generally they make the code harder to read and modify (e.g. do you know off the top of your head whether /status/edit/[id] refers to the id of the Status or its ActivityStreamsPost id? I don’t!). This bit of the export code demonstrates just how redundant they are, and how easy they would be to exorcise.
All that said, and even though I am ostensibly a microformats partisan: I honestly like activitystreams’s Subject-Verb-Predicate model. In the Known-as-a-reader sense, it could be useful to have activities like “Alice posted an essay” or “Bob liked Alice’s essay” that refer to the same Predicate, but actually represent different actions. I’m sure this was the intention originally, and I think it is a good intention and a good design. But that is not what is there at the moment — instead we’d have: “Alice posted this essay” “Bob posted this like of Alice’s essay”, “Carl posted this post that is a reply to Alice’s essay” — i.e. the ActivityStreamsPost is a wrapper around the post that adds no information or context. The actual Verb is implied inside the object itself, by the presence of a likeof or inreplyto property. It’s a weird mix of ActivityStreams and the IndieWeb model.
So that’s all a long way of saying, I think we should get rid of it. Or make it something meaningful and useful.
Originally posted to the known-dev mailing list
Anybody who’s been watching my GitHub activity for the last couple of weeks (i.e. Ryan Barrett) will probably not be surprised by this, but I’ve migrated my website to Known! I spun the parts of my homegrown software (Red Wind) that I was happiest with into separate libraries and services (mf2util, flask-micropub, brevity, silo.pub, and Woodwind), but haven’t had the energy for polishing or adding new features in ages. Contributing bits and pieces to Known has been exactly the opposite — it’s way more fun collaborating with a group and knowing that my changes might be used by lots of people.
Honestly, I’m a little worried indieweb folks will be disappointed in me. Red Wind is not a great product nor a beautiful piece of software, but it is a fully independent implementation of some of the indieweb protocols, and it is a bummer to lose that bit of diversity. And plus now I have to go update a million references on the wiki :(
But that said, I’m happy with the decision and only wish I had done it sooner. I really enjoy using Known and writing code for it, and I think there’s a lot I can bring to its development community.
Running AndroidStudio with sudo works fine, but without, it just fails silently:
kmahan@lemur:~$ android-studio/bin/studio.sh kmahan@lemur:~$
Through trial and error, I found that removing the config option
-Didea.path.selector=AndroidStudio1.5 from the java command in studio.sh works around the issue… No clue why. So that it still chooses the same config directory, I replaced that option with
-Didea.system.path=/home/kmahan/.AndroidStudio1.5 which specifies the full path instead of the selector.
So now the entire command at the end of studio.sh is:
LD_LIBRARY_PATH="$IDE_BIN_HOME:$LD_LIBRARY_PATH" "$JDK/bin/java" \ $AGENT \ "-Xbootclasspath/a:$IDE_HOME/lib/boot.jar" \ -classpath "$CLASSPATH" \ $VM_OPTIONS "-Djb.vmOptionsFile=$VM_OPTIONS_FILES_USED" \ "-XX:ErrorFile=$HOME/java_error_in_STUDIO_%p.log" \ -Djb.restart.code=88 -Didea.system.path=/home/kmahan/.AndroidStudio1.5 \ $IDE_PROPERTIES_PROPERTY \ $IDE_JVM_ARGS \ $REQUIRED_JVM_ARGS \ $MAIN_CLASS_NAME \ "$@"
and now it starts up just fine
I went into this week with a goal of outsourcing all my POSSE syndication to Bridgy Publish; I’ve put a bit of work into it lately, mainly adding support for publishing to Flickr and was feeling like it was well past time to start dogfooding it.
But this week’s conversations with Ryan Barrett et al about the purpose and breadth of Bridgy Publish changed my mind. I cannot both experiment with new idioms and techniques for POSSE and use a service that very intentionally (and rightly) only adopts those things once they are well-established.
So I started thinking we should build a service one level of user-friendliness down from Bridgy, and one level of developer-friendliness up. It would present developers with a uniform API but publish to a bunch of different social web sites, and then CMSes could syndicate content for each service via this API. Where Bridgy Publish takes one input and tries to render something sane to a bunch of different silos, here you or your CMS would craft a different version for each silo.
And then I realized the API already exists and I already built the service! With one slightly hacky workaround, silo.pub fits the bill pretty nicely. Borrowing heavily from Bridgy and Red Wind, I added support for Flickr and Facebook today (though I’m waiting on Facebook’s approval before anyone else can use it … right now it will return a permissions error when you try to post). Pretty soon I plan to remove most of the silo-specific code from Red Wind and proxy it all through silo.pub.
I’m polling myself to see what my itches are for my site, and privacy’s the big one right now … probably because impending life-circumstance-changes make me a little wary about having every nail clipping show up in Google search results. Turning on OwnYourResponses recently is partly to blame too. Previously every once in a while I’d have a joke that was too dumb to put on my site, so I’d just tweet it. But now there is no in-between! I want those Tweets archived, but not necessarily popping up at the top of my home page :)
It feels timely. We’ve explored the Twitter model pretty exhaustively. I’m curious to look at the LiveJournal model!
Ideally I’d like to let friends log in to my personal site to see stuff. For anyone to actually do it, this would need to be as painless as possible, at minimum accepting indieauth, email, Twitter, and Facebook identities. Initial login would send a “friend request” that I’d approve manually (bonus points if it figures out that we are friends on that silo and automatically sets their permissions that way). Also if someone logs in with multiple identities, it would be nice to have some mechanism to consolidate them. “You just logged in with Facebook, but you were already logged in as …, would you like to combine these?”
Supporting webmention is taking on a significantly lower priority in my mind, partly because it’s daunting to implement.
In reply to.