Indiweb Principles: Unpacked

I thought it would be nice to “un-pack” the indieweb principles, in order to become more familiar with their associated ideas.

This page is an attempt to reproduce the main topics related to indieweb principles, found in the IndieWeb Wiki, on a single page.

This saves myself from jumping around the wiki, and wondering which links I already visited.

The reader is advised to visit the wiki, and not to count on this as authoritative in any way. Found on, these resources will generally be more up to date, and accurate.

This article was quoted nearly verbatim in WIRED in 2013

2013-12-01 WIRED/Bruce Sterling IndieWeb principles


The IndieWeb Community is largely based on principles (AKA tenets) such as own your data, scratch your own itches, build tools for yourself, selfdogfood, document your stuff, open source your stuff, UX design is more important than protocols, visible data for humans first and machines second, platform agnostic platforms, plurality over monoculture, longevity, and remember to have fun!

Code of Conduct

The IndieWeb community has a code-of-conduct.

IndieWeb is an intentionally positive community that recognizes and celebrates the creativity and collaboration of independent creators (and independence) and the diversity of people, cultures, and opinions that they bring to IndieWeb.

IndieWeb spaces are an inclusive environment, based on treating all individuals respectfully, regardless of gender (including transgender status), sexual orientation, age, disability, medical conditions, nationality, ethnicity, religion (or lack thereof), physical appearance, politics, ideology (real world or tech), or software preferences.

We value respectful behavior above individual opinions.

Respectful behavior includes:

  • Be considerate, kind, constructive, and helpful.
  • Avoid demeaning, discriminatory, harassing, hateful, or physically threatening behavior, speech, and imagery.
  • If you’re not sure, ask someone instead of assuming.

Key Principles

Key principles of building on the indie web, numbered for reference, not necessarily for any kind of priority.

  • Own your data. Your content, your metadata, your identity.
  • 🔍 Use & publish visible data for humans first, machines second. See also DRY (Don’t Repeat Yourself).
  • 💪 Make what you need. Make tools, templates, etc. for yourself first, not for all of your friends or ”everyone“. If you design for some hypothetical user, they may not actually exist; if you make for yourself, you actually do exist. Make something that satisfies your needs (also known as scratch your own itch), and is compatible for others, e.g. by practicing POSSE, you benefit immediately, while staying connected to friends, without having to convince anyone. If and when others join the indieweb, you all benefit.
  • 😋 Use what you make! Whatever you build you should actively use. If you aren’t depending on it, why should anybody else? We call that selfdogfooding. Personal use helps focus your efforts on building the indieweb around your needs and consistently solving immediate real world problems. AKA eat your own dogfood. selfdogfooding is also a form of “proof of work” to help focus on productive interactions.
  • 📓 Document your stuff. You’ve made a place to speak your mind, use it to document your processes, ideas, designs and code. Help others benefit from your journey, including your future self!
  • 💞 Open source your stuff! You don’t have to, of course, but if you like the existence of the indie web, making your code open source means other people can get on the indie web quicker and easier.
  • 📐 UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols & formats sufficient to support that UX, and nothing more. AKA UX before plumbing.
  • 🌐 Modularity. Build platform agnostic platforms. The more your code is modular and composed of pieces you can swap out, the less dependent you are on a particular device, UI, templating language, API, backend language, storage model, database, platform. Modularity increases the chance that at least some of it can and will be re-used, improved, which you can then reincorporate. AKA building-blocks. AKA “small pieces loosely joined”.
  • 🗿 Longevity. Build for the long web. If human society is able to preserve ancient papyrus, Victorian photographs and dinosaur bones, we should be able to build web technology that doesn’t require us to destroy everything we’ve done every few years in the name of progress.
  • Plurality. With IndieWebCamp we’ve specifically chosen to encourage and embrace a diversity of approaches & implementations. This background makes the IndieWeb stronger and more resilient than any one (often monoculture) approach.
  • 🎉 Have fun. When the web took off in the 90’s people began designing personal sites with tools such as GeoCities. These spaces had Java applets, garish green background and seventeen animated GIFs. It may have been ugly and badly coded but it was fun. Keep the web weird and interesting.

Principles Expanded

Own your Data

own your data is an IndieWeb principle with two key parts: 1) your data lives primarily on your own domain, and 2) you maintain usable access to it over time. Why

A personal domain is a domain name that you personally own, control, and use to represent yourself on the internet. Getting a personal domain is the first step towards getting on the indieweb, and is therefore a requirement for IndieMark Level 1.

First, using your own domain gives you control over where people find and interact with you online. When you migrate to a new hosting provider or CMS, if your site stays on the same domain, everyone will still find you, regardless of whether they follow your site in a reader, land directly on your permalinks from other sites or search engines, or even type your domain directly into a browser.

Second, they say that change is the only constant, and web sites are no exception. Whether you stick with a host or CMS for a year, a decade, or a century, you’re likely to change something eventually. When you do, you’ll need usable access to all of your existing data. This includes export and import, data formats and standards, tools, protocols, permissions, rate limits, and more.


This is another page that is really long, you should visit the wiki.

“You’re here because you know something. What you know you can’t explain, but you feel it. You’ve felt it your entire life, that there’s something wrong with the world [wide web].” — Morpheus, The Matrix

Whatever the reason, you’re done with others owning your content, your identity, and your self.

Our online content and identities are becoming more important and sometimes even critical to our lives. Neither are secure in the hands of random ephemeral startups or big silos. We should be the holders of our online presence.

Note: Perhaps at the next IndieWebcamp we can reframe the above definition and summary in a primarily positive way. We need a good writer to attempt to integrate and cleverly summarize the most potent of the existing positive why reasons.


dogfood in the context of the indieweb, refers to the software practice of “eating your own dog food” but in particular with using your own creations on your own personal site that you depend on, day to day.

Selfdogfooding in particular is one of several indieweb principles.

Since colloquial usage is a bit broader and (mis)biased toward a “a company [using] its own product”, thereby implying people using work creations on work sites (rather than their own individual/personal sites), and not necessarily depending on them, it’s helpful to have a more specific, more meaningful term to use in broader contexts:

Self Dog Food

😋 selfdogfood is the act of using your own creations and depending on them personally yourself, beyond just self-testing or dogfooding a work project; on the IndieWeb, it means using your creations on your personal site as an aspect of your primary online identity, day to day.

Build what you need. Use what you build. John Seely Brown quoted at eLearning 2015[1]

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


Get started faster. What do you really need? Selfdogfooding helps you better understand what you really need rather than just what you think you need.

By building what you need, it constrains what you think you need with the practical limits of time, ability, and cost, thus forcing you to come up with a more efficient design than you likely thought you needed originally.

Prioritization. Fix more important problems first. Selfdogfooding helps you empathize as a user and fix the important problems first.

By using what you build, you see and feel the impact of problems in what you have built, and in particular feel the difference between minor problems and major problems, thus helping you prioritize fixing the more important problems.

Faster iteration. Fix the more important problems faster. Selfdogfooding helps motivate you to fix the important problems faster.

By using what you build as your personal identity on the public web, when there are visible problems, you will feel self-conscious about it, and strongly motivated to fix them quickly.

If you don’t build it, you’re just talking theory.

If you design/architect etc. without building, you’ll likely come up with ever higher level abstractions, AKA the architecture astronomy anti-pattern. That being said, it’s helpful to publicly brainstorm what you’re thinking of building because others can review, provide feedback, help you simplify, etc.

If not you, then who?

[should bother using your stuff]

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?

Creations tend to break (stay broken), when their creators don’t use them.

In general it is a good idea to use code that the author is using themselves. Those are less likely to be broken.

Scratch your Own Itch

Scratch your own itch is a key indieweb principle that helps everyone focus on working on things that make a difference to their own lives.

Make tools for yourself first, not for all of your friends or ”everyone“. If you design tools for some hypothetical user, they may not actually exist; if you make tools for yourself, you actually do exist. It’s extremely hard to fight Metcalfe’s law: you won’t be able to convince all your friends to join the independent web. By making something that satisfies your needs, and is backwards compatible for others, e.g. by practicing POSSE, you benefit immediately, without having to convince anyone else. If and when others join, you all benefit. This principle is also known as scratch your own itch.


There may be more broadly appealing ways of saying “Scratch your own itch”. It’s worth brainstorming about such potential replacements.

Make What You Need

More direct than a metaphor, make what you need, expresses a method of focusing that parallels well with another principle, use what you make. In addition as a metaphor, we could use “cook what you want” or “cook what you hunger”. +1 Tantek Çelik proposed

Or variant “make what you want”. Not sure about need vs want as a focusing framing. Which is more similar to “itch”? Which is more broadly appealing?

Be The Change

“scratch your own itch” is as much as admonition to actually do the “scratching” yourself, as well as prioritizing “your own itch”.

In this regard it is expressing the “Be the change” expression common in forms like:

  • “Be the change you want to see in the world” (misattributed to Gandhi)
  • “Change yourself and you have done your part in the changing the the world. Every individual must change [their] own life if they want to live in a peaceful world”, from “Para-gram” by Paramahansa Yogananda
  • “If you want to make the world a better place, Take a look at yourself, and then make a change” - Michael Jackson, “Man In The Mirror” (all profits from that single went to charity apparently, per


This page is quite full, with plenty of live examples. You’ll want to visit the wiki for the full piece!

POSSE is an abbreviation for Publish (on your) Own Site, Syndicate Elsewhere, a content publishing model that starts with posting content on your own domain first, then syndicating out copies to 3rd party services with permashortlinks back to the original on your site.


Let your friends read your posts, their way. POSSE lets your friends keep using whatever they use to read your stuff (e.g. silo aggregators like Facebook, Tumblr, Twitter, etc.).

Stay in touch with friends now, not some theoretical future. POSSE is about staying in touch with current friends now, rather than the potential of staying in touch with friends in the future.

Friends are more important than federation. By focusing on actual social relationships that matter to people rather than architectural ideals, from a human perspective, POSSE is more important than federation. Additionally, if federated approaches take a POSSE approach first, they will likely get better adoption (everyone wants to stay in touch with their friends), and thereby more rapidly approach that federated future.

POSSE is beyond blogging. It’s a key part of why and how the IndieWeb movement is different from just “everyone blog on their own site”, and also different from “everyone just install and run (YourFavoriteSocialSoftware)” etc. monoculture solutions.


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).


(Redirected from UX)

User experience, often abbreviated as UX, refers to the total experience a user has with a tool, or even an entire company, across all methods of communication and interaction with that tool, including both direct interactions using a tool UI and indirect interactions via other tools such as email, SMS, phone calls, in-person human representatives of the tool or company, etc.


Why UX? A good UX should/will make you more productive, more in control (user agency), while minimizing frustration.


Iterating with your own use-cases (scratching your own itches, per principles) helps you at least build a good UX for yourself, as long as you do use it yourself (selfdogfood).

Then if/when you have a second user, watch how they use your software, and take notes. Watch where they get stuck, or frustrated. Listen to them verbalize what they want to get down, but be very ware of anything they say about how they want to do it, or any opinions about tools etc.

Beware of

Beware of just “asking” users what they want. They’re usually wrong (they don’t have sufficient self-cognition plus design skills to do so, not their fault) and you’ll usually get bad outcomes if you try to build accordingly.


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

  • Graphic design (including site icon)
  • User interface design (UI design)
  • User experience (UX)
  • Information architecture (IA)
    • URL design

IndieWeb Examples


modularity is one of the IndieWeb principles, sometimes expressed as “Build platform agnostic platforms”, that advocates designing and building modular code and services composed of pieces that can be swapped to reduce dependencies on a particular device, language, API, storage model, or platform.

Modularity increases the chance that at least some of it can and will be re-used, improved, which you can then reincorporate. AKA building-blocks. AKA “small pieces loosely joined”.


Encouraging a plurality of projects with a self-motivated incentive to interoperate is a key principle of the indie web, in contrast to monoculture efforts which require or even encourage everyone to install the same software, or use the same online service, in order to interoperate.

Project diversity over monoculture

With IndieWebCamp we’ve specifically chosen to encourage and embrace a diversity of approaches & implementations. This background makes the IndieWeb stronger and more resilient than any one (often monoculture) approach.

One of the key things we recognize with IndieWebCamp is that no one project is likely to be the answer.

Simultaneous exploration and evolution

We’re much more likely to advance the state of the art by encouraging everyone to build what works for them, and then figure out how to interoperate between different coding/implementation approaches. This is what makes IndieWebCamp different (more inclusive) than all other such “open source” efforts out there.

Multiple implementation efforts help to simultaneously explore different parts of the indieweb problem space as we’re all choosing to focus on building the particular aspects of what’s important in an indie web site for ourselves. Additionally, multiple approaches to the same problems in essence A/B(/C/D/…) test different approaches simultaneously, each of which can then learn from and evolve in response to the others.

This parallel diversity both produces better indie web solutions faster, and allows for the incorporation of new approaches to address new problems, adapting as the needs of an indie web site change over time.


Longevity is the goal of keeping your data as future-friendly and future-proof as possible; it is one of the indieweb principles.

If human society is able to preserve ancient papyrus, Victorian photographs and dinosaur bones, we should be able to build web technology that doesn't require us to destroy everything we've done every few years in the name of progress. 



Mehtab Bagh, 49 6e 64 75 73
Email me

Full-Time Independent Web-Worker. Research, Skyscraper Publishing, IndieWeb ⧉ Crypto-Curation and Histories ⧉ Bitcoin, Blockchain, DecentralizedID ⧉ her/him