IndieWebCamp January 23-30, 2015

This is an automatically-generated summary of the IndieWebCamp wiki edits from January 23-30, 2015

Table of Contents

New Pages

Changed Pages

New Pages


Created by on January 23

Pebble or the Pebble Watch is a smart watch that pairs to a mobile device via Bluetooth LE, and provides a very minimal low resolution black&white text & pixel display, has passive sensors (3D accelerometer, compass, ambient light), a vibration motor and four buttons.

The manufacturer currently supports interfacing with the iOS and Android operating systems.


App Store

Pebble announced on 2014-01-06 that they would be launching an app store. Pebble, from the beginning, has supported apps written in C with the use of their SDK. Many of these apps required the use of companion apps on the connected phone.

Since version 2.0 of the API, a javascript library permits Watchapps to access phone functions and the Internet directly.


  • Pebble is limited to the installation of 8 watchfaces/watchapps.

IndieWeb Examples

Aaron Parecki

Aaron Parecki uses a Pebble with to:

David Shanske

David Shanske has used a Pebble since 2013-12-16:


See Also

Android Wear

Created by on January 24

  • Sat, January 24 Created page with "<dfn>Android Wear</dfn> is a version of the [[Android]] operating system designed for [[smart watches]] and other [[wearables]]. == Indieweb Examples === David Shanske === {{g..."
  • Sat, January 24
  • Sat, January 24

Android Wear is a version of the Android operating system designed for smart watches and other wearables.

Android Wear was announced 2014-03-18, with the first models released at Google I/O on 2014-06-25.

Indieweb Examples

David Shanske

David Shanske has owned an Android Wear watch, the LG G Watch since 2014-11-06 and has used it to:

2015/Cambridge/Guest List

Created by on January 27

IndieWebCamp Cambridge 2015

Official Guest List

If you have a personal site If you want a personal site
Are you a Creator (create & share design, UI/UX, and/or code)? Either: add yourself to the guest list by Logging in with your own domain, or Publish a post saying that you're coming with a link to this RSVP page and send a pingback to it. If you're in the process of setting up your personal site, or don’t have a personal site but want one, or want to create and contribute to the IndieWeb but don't know where to start, you’re still very welcome! Find a creator (either listed below, or ask on IRC) to team up with and ask them to add you as their apprentice. Then get your site setup with IndieAuth and edit your entry!

Curious about attending? See what happened at the main IndieWebCamp 2015 in June!


Venue Capacity: 48

  • Signed-up: 2
  • Spots remaining: 46

Alphabetically sorted by full display name.

Name: Amy Guy

IndieWeb Projects:

Personal URL:

Name: Tantek Çelik

Organization: Mozilla

IndieWeb Projects: CASSIS JS∩PHP (on github), Falcon (my personal site publishing software), Whistle (URL shortener)

Personal URL:

Elsewhere: @t,

Name: Your Name

IndieWeb Projects:

Personal URL: your domain

Elsewhere: @yourname



Apprentices, add yourselves with your name, personal URL (if any), Creator, more info. Alphabetically sorted by given name.

Name: Apprentice Name

Apprentice Of: Your Name

Personal URL: your domain

Elsewhere: @yourname

Remote Participants

As with past IndieWebCamps, we'll setup remote participation for folks who can't be there in person but can still participate during the camp over IRC and hopefully live video.

Name: Aaron Parecki

Organization: Esri

IndieWeb Projects: p3k,, IndieAuth, micropub

Name: Your Name

IndieWeb Projects:

Personal URL: your domain

Elsewhere: @yourname


Folks that can't make it (but hopefully can participate before/after remotely!)


No one is listed yet. Add yourself to the list using the attendee template!

Missed You

Sorry to miss you folks - hopefully you can make it next year!


No one is listed yet. Add to the list using the attendee template

Created by on January 27

Hi all,

I'm Achor Kwon

smart watch

Created by on January 24

  • Sat, January 24 Created page with "A <dfn>smart watch</dfn> is a mobile device designed to be worn on the wrist. Designed to be similar in appearance to traditional watches, and often defaulting to mimicking the f..."
  • Sat, January 24

A smart watch is a mobile device designed to be worn on the wrist. Designed to be similar in appearance to traditional watches, and often defaulting to mimicking the functions of a traditional watches, the most common use of smart watches is to receive notifications from a smart phone without having to remove this device from a pocket.

The two most prevalent types of smart watches are the [[Pebble] and Android Wear. Unlike Pebble, which is the product line of a single company, Android Wear is a watch operating system that runs on hardware provided by several companies. Apple has announced its intention to release a smart watch, which is expected to increase adoption of the product category.


While watches that could interface to a computer have existed since the 80s as a narrow category, the current selection of smart watch offerings began in 2013.


  • Size
  • Battery Life
  • Utility as a companion to a smart phone

See Also


Created by on January 25

인디웹은 이전의 블로깅, 소셜웹 연합 및 분산화 등의 노력과 분명한 차별점이 있습니다.

블로그와 분산화의 새로운 미래

인디웹은 이전 노력 및 커뮤니티와 몇 가지 차별화 되는 점은 아래와 같습니다.

관심이 있으시면, 지금 참여해주세요!

회사가 아닌 인디

인디웹은 인디(indie)라는 단어와 같이 독립성을 강력히 지원합니다.

인디웹은 커뮤니티(community)이자 공유 장소(commons)이며 회사가 아닙니다.

회사인 "" (with the ".")는 인디 기술을 성취하기 위해 인디웹 원칙을 따르지만 인디웹과 분리됩니다.

함께 보기

Bluetooth LE

Created by on January 23



Created by on January 23

subtext is like a subtweet without the extra tweet.

See Also


Created by on January 25

  • Sun, January 25 Created page with "A '''<dfn>creator</dfn>''' in the context of the IndieWeb is someone who owns their domain, uses it as their primary identity on the web, creates (for example, code, design, user..."

A creator in the context of the IndieWeb is someone who owns their domain, uses it as their primary identity on the web, creates (for example, code, design, user experience) for their site, and openly shares at least some of those creations.



Main article: indieweb

The IndieWeb is about owning your domain and using it as your primary identity.

  • You can have more than one such personal domain.
  • You could use your own domain for purely a professional identity facet, preferring to keep anything personal off the internet/web. That's totally fine.


Being a creator means you must do one or more of:

  • Code. Create or contribute to IndieWeb open source projects
  • Design. Create or contribute to IndieWeb designs, graphic, layout, adaptive or otherwise.
  • User experience. Create wireframes or other IndieWeb user interface flows

As an IndieWeb creator, you must be using the things you create (code, design, user experience) on your personal site. If it's not good enough for you, then it's not good enough for the IndieWeb.


Lastly, one of the goals of IndieWebCamp is to empower each other and interoperability among our sites, encouraging re-use of code, design, user experience and thus:

You must share at least some part of what you create.

You don't have to share the entirety of what you create or even most of it.

Just find some part of it that it at least minimally useful, and that you're OK with sharing.

It's OK to start small, even just a function or two, or some graphics files, or user experience flow diagrams, or even just wiki design descriptions, for example, URL designs, and slowly add to it over time.

The point is to take something that is powering or has empowered your IndieWeb site, that you work on, develop, improve, create, and share it with others, in the hopes that it will help empower and improve their IndieWeb sites.


As a creator, you're encouraged to sign-up to and participate in IndieWebCamps, to meet other creators, collaborate on improving each others sites, and growing the IndieWeb.

See upcoming IndieWebCamp events.

You are encouraged to bring an apprentice to IndieWebCamp, to help them get their own domain and setup their identity and content on their own site.

See also


Created by on January 25

  • Sun, January 25 Created page with "{{stub}} '''<dfn>Monoculture</dfn>''' refers to the [[antipattern]] of one piece of software dominating (or trying to dominate) its field, often by being limited to communicatin..."

Monoculture refers to the antipattern of one piece of software dominating (or trying to dominate) its field, often by being limited to communicating with other instances of the same codebase. A monoculture (same software running on servers run by different people) is one step above a silo (same software running on servers run by the same people or organization).



Examples of software monocultures that have developed over time:

  • Mobile WebKit: web designers that only design their mobile web content for the WebKit browser, including only using -webkit-* CSS properties or even blocking access to browsers that don't have a WebKit user-agent string.
  • BuddyCloud "is an open source, distributed social network"
    • No one particular project should be considered a "distributed social network"
  • Diaspora to some degree emphasized interop with other Diaspora instances, though it did support several open standards, and thus made progress towards open interop rather than single-project-interop.
    Main article: Diaspora
  • has been pitched (no pun intended) as a single project distributed social network solution.
    Main article:
  • ...

Common patterns among monoculture projects include:

  • don't bother to research/re-use existing working protocols (or only minimally do so)
  • don't bother to engage with existing healthy communities
  • go down the path of solving it all themselves in the project
  • expect others to follow their software/protocols when they didn't bother to follow anyone else's, or at least document why they considered and rejected them, or why theirs is an improvement (contrast with webmention being a deliberate improvement upon pingback).

Monoculture Community

Another slippery slope with monoculture projects is the tendency to create monoculture communities around said projects.

Having a vibrant developer / user community is a downright necessity with fledgling open source projects.

  • Is it? None of the fledgling open source IndieWeb projects that people here are building for their own sites have any kind of project-specific developer/user "community". Perhaps this is a false assumption of "necessity". What an open source project does need is at least one dedicated creator and you get that through relentless selfdogfooding. No amount of developer/user "community" can make up for dedicated creators (or lack thereof). - Tantek 11:43, 30 May 2013 (PDT)

However, when creating community one can make a choice which is intrinsically monoculture perpetuating (which appears to be the convenient default) or conversely a culture which fosters cross platform interoperability and compatibility.

Take for instance this prize from the stretch goal from the Kickstarter of the promising new blogging platform Ghost:

"We will build an Open Source Digital Magazine curating stories written with Ghost" Ghost blogging platform

Is it truly within the ethos of the open source software movement to create an open source magazine that only covers content written from one platform of blogging software?

Would open source not be better off if multiple projects within a given domain (e.g. content publishing) all worked together to achieve something bigger?


There are numerous downsides to monoculture, including:

  • security risks — the exact same bugs on many servers mean attacks can be reused and deployed in bulk to a large numbers of servers. Examples: WordPress, MediaWiki, OpenSSL
  • software encodes values: what Facebook means by "liking" something is different than what Google means by "+1"-ing something, which is different than what Twitter favoriting means, which is different from what WordPress means by "starring" something. The semantics of each differ: having a wider array of software means that people can experiment with encoding a wider array of conceptualisations of the things they value into the software they use.
  • Open source monocultures can foster unproductive disagreement between collaborators. If everyone is working on the same project then we all have to agree on all details of implementation. Alternatively, focusing on interoperability and personal use cases encourages healthy debate without the need for anyone to compromise.
  • Monoculture builds up fragility debt - by making internal connections easier, at the expense of interoperation, ending in a large collapse as all connected data is lost at once. See The Antifragility of the Web

Perceived Advantages

Monoculture appears to have some benefits; for example the ease of implementation across different instances of the same code base.

However, this "ease of implementation" is an illusion of progress in terms of interoperability that may actually provide a motivational barrier to working on the hard problems of cross-implementation interoperability.


Software can avoid promoting monoculture by prioritising integration with other codebases over working with other instances of itself.

As a community we can avoid monoculture by using many different implementations and building/lobbying their developers to build them to work together.


Potential antidotes to monoculture:

  • Encourage monoculture projects to support indieweb building-blocks and become indieweb friendly.
  • Encourage participants in monoculture projects to join IRC and signup on the Guest List to attend the next IndieWebCamp. By engaging these projects productively, perhaps we can help improve them and their cross-project interop.

We should document monocultures that we have successfully reached out to and integrated into the broader indieweb community.

Blog posts

See Also


Created by on January 25

  • Sun, January 25 Created page with "<span style="float:right;height:192px;font-size:192px;margin:72px 0 -64px">✊</span> {{stub}} '''<dfn>데이터 자기 소유</dfn>'''는 인디웹의 중요한 [[principles-ko..."

데이터 자기 소유는 인디웹의 중요한 원칙 중 하나입니다. 인디웹은 인터넷 서비스 업체(silos)에만 올리는 대신 여러분 자신의 도메인(domain) 퍼머링크(permalinks)를 가진 콘텐츠를 스스로 소유하는 것을 중요시 합니다. (물론 복제본POSSE를 이용하여 올리거나 원래 포스트로 돌아갈 수 있는 permashortlink를 만드는 것은 가능합니다.)


그 이유를 why-ko를 자세히 보세요.



기본 정보

아래 순서대로 읽어보세요:

대형 웹 사이트

대형 웹 서비스 업체에 콘텐츠를 올리지 마시고 여러분의 데이터를 여러분의 사이트에 직접 올리세요.

대신 POSSE 기능을 이용하여, 대형 웹 사이트에 여러분의 콘텐츠로 오도록 하는 링크와 정보를 공유하세요.

포스트 유형

각 콘텐츠 유형에 따라 여러분의 사이트에만 올려주세요.

IndieWeb 예제

Snarfed 사례

Ryan Barrett has:

  • instead of Instagram, posted:
    • posted photos on his own site always [21], POSSEd manually, backfed via Bridgy
    • read his Instagram stream via instagram-atom instead of the Instagram app
  • instead of Google+, posted on his own site:
    • articles, notes, and photos always, POSSEd manually, backfed via Bridgy


#ownyourdata is a rallying cry hashtag for aggregating content across indie web sites and 3rd-party silos about "owning your data", "owning your own data" etc.

#ownyourdata posts tend to be a a subset of Posts about the IndieWeb.

추가 정보


Created by on January 25

  • Sun, January 25 Created page with "<span style="float:right;height:192px;font-size:192px;margin:64px 0 -32px">✂</span> {{stub}} '''<dfn>Design</dfn>''' is a catchall term used to refer to everything that affect..."

Design is a catchall term used to refer to everything that affects users about a page/site including:



Some thoughts on design.


What's the minimum viable (for any particular feature) UI (MVUI) you could implement and start using via your website? - Tantek 11:25, 15 May 2013 (PDT)

Prioritize Through Use

Once you design/implement that MVUI and use it, by actual use in the wild you'll come up with a much more informed set of next-most-important-to-you features to implement. - Tantek 11:25, 15 May 2013 (PDT)


It's OK (and even often good!) to make incremental improvements to the design, however small or conditional.

For example, every time you reduce the number of situations where the user sees an error and/or has to file a support ticket, the likelihood of an overall better user experience is increased.

And on the contrary, avoid making such incremental improvements depend on other incremental improvements that can be done independently or later. Such dependencies are a milder form of the completeness trap.

UX Before Infrastructure

There is a misdirected priority/desire (often among developers/engineers) for things like:

  • "a general message producer/consumer so I can implement it once"[1] or similarly
  • a general parser so I can implement it once

"...and then spend the rest of my time focusing on the UX" (ibid)

This is the kind of reasoning that led people to push for XML over everything else.

It was a misplaced focus on solving infrastructure *before* UX.

It turns out that doesn't actually help you solve the UX, which is the real challenge.

On the contrary, if you have good UX, then the infrastructure/plumbing can be almost anything, and swapped out later too.

This is perhaps a key distinguishing feature/aspect of the indieweb and IndieWeb efforts.

UX Before Protocols

Start with the MVUI/UX that you want on your website and implement accordingly.

When you reach a site-to-site boundary, i.e. an IndieWeb-to-IndieWeb boundary, in whatever feature you're designing, creating, iterating, use the desired UX to drive the design of a minimal protocol.

Never shoehorn upwards, that is from protocol up to UX - as that is the tail wagging the dog.

At the end of the day, the UX is what matters, regardless of attributes, protocols, etc.

And without UX, that is if you don't know what UX you want, you'll overdesign/overengineer your protocols & formats, as nearly all protocols & formats are.

On the IndieWeb, we focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest most minimal protocols sufficient to support that UX, and nothing more.[2]


See specific features (e.g. from IndieMark) and building blocks for screenshots and to add more, e.g.


There are various design experiments which may be useful as sources of inspiration, or may indicate fleeting fashions or ephemeral design trends:

  • parallax scrolling - use of scrolling to change perspective / layout of what is on the page, e.g.

See Also


Created by on January 25

  • Sun, January 25 Created page with "<span style="float:right;height:192px;font-size:192px;margin:96px 0 -96px">😋</span> '''<dfn>selfdogfood</dfn>''' is a stronger form of [[dogfooding]], that is, using <em>your ..."

😋 selfdogfood is a stronger form of dogfooding, that is, using your own creations on your own personal site that you depend on, as an aspect of your primary online identity, day to day — if you're not willing to use your creation on your own primary personal website, why should anyone else use it on their primary personal website?

Metaphorically speaking, a person's ideas must be the building he lives in - otherwise there is something terribly wrong. Søren Kierkegaard, introduction to Provocations

key components


Selfdogfooding has several required components, one of which is dogfooding, but the other is the essential self part of selfdogfooding:

  1. dogfooding
    • active creation - whether code, UX, interactive/visual/graphic design, being an active creator
    • use of what you create (e.g. by your company, on your company's site, your club's site, etc.)
  2. self - what you must do above and beyond dogfooding, to be selfdogfooding
    • personal - use of that creation - you yourself personally using your creation for your own personal uses - it's not (just) a job use (i.e. that you can shut off when you go home), it's a personal use.
    • identity - use of that creation in what you identify as your self. The act of creation alters an aspect of the public "self" of the creator. On the web, this means use of that creation actively on your personal website that you primarily use to identify yourself to others. I.e. not on a test site, nor a hobby site, nor an occasional use site, but your primary personal site and thus as part of your primary identity on the web.


  • "Is its creator living and breathing it in his day-to-day online life? If so, awesome, if not, yawn." - Tantek 2013-01-03 11:05 (PST) (originally posted as a comment on a Google+ post).
  • "any web server software that isn't actively selfdogfooded by its creators on their own personal domains is fragile and should not be trusted. and if web software creators themselves don't have a personal domain they use on the web then the web software is categorically untrustworthy." (speaking to the unfortunate demise of Open Photo, e.g. on Barnaby's site, and the screenshots on there that he'd linked to from patterns/note-list#Documented_Examples & patterns/note#Documented_Examples) Tantek Çelik 2014-05-12 in IRC

  • If I make software for [someone else], am I ever going to rely on it? Unlikely

    If I make software which solves my own problems in a useful way, might others find it useful? Much more likely. - Barnaby Walters (2013-08-21 in iRC)

  • I have a higher tolerance for my own stupidly designed interfaces than [another person] would, but at some point I'm going to get frustrated by inefficiencies in my interface and make it better for me, which then makes it better for everyone. - Aaron Parecki (2013-08-21 in IRC)

  • ...


Posts about selfdogfooding (most recent first)


It has come up in discussion several times that a more appealing term should be used. No consensus has been reached yet.

Please add IRC links and summarize discussion...

    • gRegor Morrill likes the simple phrase "use your own product" or UYOP if an acronym is preferred. It's simple and to the point.
  • Drinking your own champagne, or self-champagneing
    • or just champagneing; doesn't need distinguish it from a preexisting term
  • Self-kool-aiding — also has the connotation of buying into your own spiel


In the Star Wars mythology about lightsabers, you (a Jedi) have *only* one, that you are expected to have *built* it *yourself*, and that you *depend* on as an extension of your *self*.

Contrasting examples:

  • dogfood: In Ep1, Anakin is merely dogfooding C3P0, which he built to also help his mom. Even though he cares about it, C3P0 is not part of Anakin. No aspect of identity/self.
  • selfdogfood: In RoJ, Luke is selfdogfooding his own lightsaber that he made. It's his only lightsaber, he made it, he depends on it as an extension of himself.


Use and development

Are there two dimensions to selfdogfooding: use and development?

A: There are many required aspects of selfdogfooding, use and development only two of them.

Content updates but no commits

Would a site that is regularly updated with posts but not have commits for a while qualify as selfdogfooding?

A: At some point if there are no creative (code, UX, design) commits by the self-identified primary user of said site, then they've shifted from dogfooding (which requires a creation/use feedback loop) to simply being a user. No, eventually, after "a while", that should not be considered selfdogfooding.

Unverifiable commits

What about sites that are running non-open-source software (no way to directly verify commits)?

A: Even web sites running software that is either little or not at all open sourced can still be analyzed for what features they use in terms of :

  • outward visual appearance and user interface
  • external notifications (e.g. PuSH and webmention behaviors)

Thus even if specific code commits are not transparently visible, there are plenty of other direct and indirect sources of evidence for creative (code, UX, design) changes, and thus the create/use pairing can still be verified to some extent.

testing your code in production


Whilst testing your code in production is a good part of selfdogfooding, security precautions should still be taken. Showing errors, warnings and notices usually reserved for dev environments is a huge security risk due to the fact that things like paths, usernames, secret keys, etc. might be inadvertently shown to anyone who cares to look. It’s also not a great idea to have confusing error messages intermingled with content.

Rather, you should log all such messages somewhere where only you can see them, or only show them in-page if you’re logged in as an admin.

In PHP, there are several ways to go about this.

  • Setting display_errors off in your php.ini
  • Within PHP: ini_set('display_errors', 'off');
  • For a single line: @codeWhichIsCausingErrors();
  • If you’re logged in as an admin:
    if ($user->isAdmin()) ini_set('display_errors', 'on');

see also

Created by on January 27

Harry Reeder


Created by on January 29

  • Thu, January 29 Created page with "<dfn>Moderation</dfn> is the process of holding [[comments]] for review by a human. == Moderation Status == Under the current [[webmention]] specification there is no indicati..."

Moderation is the process of holding comments for review by a human.

Moderation Status

Under the current webmention specification there is no indication for when a comment is held for modification.

In many systems, however, there is a response for human commenters that is visible, indicating that a comment has been accepted and is awaiting moderation by a human.

Moderation Criteria

  • Blacklist
  • Whitelist


Created by on January 27

Harry Reeder


Created by on January 27

  • Tue, January 27 Created page with "<span class="h-card">{{sparkline|}} [[|Reid Beels]]</span>"

Reid Beels


Created by on January 27

just starting this page as a free form space to organize notes etc.


  • Need another co-organizer, I am too far out of town to do everything. Ben Roberts
  • Figure out food
    • Breakfast Day 1:
    • Lunch Day 1:
    • Group Dinner Day 1:
    • Breakfast Day 2:
    • Lunch Day 2:
  • It looks like Aaron Parecki won't be joining us in person so we need to figure out a plan for streaming / Live interaction.
  • Get update on exact location from Template:sandro, currently assumed to be same as last year. Need to update 2015/Cambridge, 2015/Cambridge/Guest_List, and Main_Page if room changes.
  • Find Sponsors

Changed Pages

2015/Germany/Guest List

5 edits by,,,


5 edits by,,
  • Tue, January 27 lock down dates, move other events to Nearby Events section, expand summary, add interested remote participation section
  • Tue, January 27 /* Remote Participation */ add myself
  • Tue, January 27 sandro confirmed venue, this is happening
  • Tue, January 27 moved Interested section to official guest list
  • Thu, January 29 dfn, better h-event markup, explicitly note Thursday Friday, lots of de-duping


4 edits by,,

Getting Started-ko

2 edits by


2 edits by
  • Mon, January 26 /* de-duplication */ Silo examples Twitter
  • Mon, January 26 /* de-duplication */ likely needs its own article, set out the reasons for now


2 edits by
  • Fri, January 30 /* Origins */ make it actually link to origins, the other stuff here is more like design considerations, subhead it accordingly
  • Fri, January 30 /* Origins */ quote

Main Page

2 edits by,
  • Tue, January 27 update with 2015 IWC reference
  • Wed, January 28 Undo revision 17046 by [[Special:Contributions/|]] ([[User|talk]])


2 edits by


1 edits by

POSSE to Facebook

1 edits by


1 edits by
  • Mon, January 26 Korean now up to 6 articles! (including [[Main_Page]])


1 edits by


1 edits by

1 edits by
  • Thu, January 29 /* MobilePub */ update with things i've completed, download link


1 edits by


1 edits by


1 edits by
  • Wed, January 28 change back to static profile image URL. webvatar seems to be down.


1 edits by
  • Wed, January 28 /* Articles */ Added article: My Favorite Database is the Network


1 edits by


1 edits by perpetual-tripper
  • Tue, January 27 perpetual-tripper /* See Also */ xfn-hcard-supporting-friends-lists

IRC People

1 edits by


1 edits by
  • Mon, January 26 features: create UI, character count, deduplication