
The Indie Web movement (2013) - handpickednames
https://www.wired.com/2013/08/indie-web/
======
danirod
The protocols that drive the Indie Web movement are actually open standards
published by the W3C Social Web Working Group [1]. This year, some of these
standards became W3C Recommendations. Webmentions is the successor to
pingbacks and it can also be used for comments and replies in blog posts.
IndieAuth is an authentication system based on OAuth that can be used for
publishing content into your site using applications via Micropub.
Microformats adds metadata to web documents so that applications can also
scrap information from blog posts (in a similar fashion to OpenGraph).

One of the most interesting concepts about the Indie Web movement that I like
is POSSE [2]: you should own your content, but it's OK to then syndicate your
content into silos such as Twitter or Instagram as long as there are links
that trace back to your site so that your site is always seen as the canonical
place where your content lives.

[1]: [https://www.w3.org/Social/WG](https://www.w3.org/Social/WG) [2]:
[https://indieweb.org/POSSE](https://indieweb.org/POSSE)

------
MaxBarraclough
The heroes the web needs. Really.

An example of the kinds of things the IndieWeb folks think about: POSSE,
"Publish (on your) Own Site, Syndicate Elsewhere", where twitter and co are
used as secondary platforms referring back to the non-silo-controlled site.

[https://indieweb.org/POSSE](https://indieweb.org/POSSE)

~~~
52-6F-62
I hadn't heard of this before this thread.

This is actually almost tit-for-tat the MO of digital media corps publication
and delivery roadmaps (well, the outward facing side). I've heard plenty of
this in the media world, and no reference to the Indie Web group.

In hindsight the general design of said system is obvious, but I wonder if
their plans originated with IW, or developed beside it.

------
tscs37
The Indie Web movement is a very interesting one, I personally support some of
their goals, however, the protocols they design seem a bit... too
uncomplicated at times (Microformats2 is impossible to properly parse in JSON
form and you need that for their Micropub protocol. And Micropub has a few
stinks of it's own)

~~~
epeus
That makes no sense. Microformats 2 defines how to parse html into json form,
and there are multiple implementations in different programming languages.

[http://microformats.org/wiki/microformats-2-parsing](http://microformats.org/wiki/microformats-2-parsing)

If you have problems with micropub, file issues with the spec.

[https://github.com/w3c/Micropub/issues](https://github.com/w3c/Micropub/issues)

~~~
tscs37
When you write a Micropub implementation the primary spec involves an unholy
JSON format.

About 80% of the code I wrote was just dedicated to finding out whether or not
I'm updating an article, creating a new one, deleting the article entirely and
which attributes need updating.

The JSON format has an immense amount of issues relating to irregularity, some
fields have html and text sub-attributes but this doesn't seem documented
properly anywhere, not even the MF2 page, everything is an array even where it
makes 0 sense to do so and as an implementer I'm somehow expected to then
process and store this mess as a coherent article.

Part of the spec validation involves storing a publication which contains
almost no text and some user defined elements for some reason. And I'm
expected to understand and properly update these custom elements if requested.

