Post or posts may refer to individual pieces of content published on an indieweb site such as notes, articles, & responses, or the act of creating the aforementioned content (present tense), or Posts about the IndieWeb.
In list form:
- IndieWeb posts, e.g. notes, articles, etc.
- The act of creating the aforementioned content (present tense)
- Also used elsewhere, e.g "posts a comment", "posts a photo"
- The act of creating the aforementioned content (present tense)
- Posts about the IndieWeb
Having multiple posts on your own site is a requirement for IndieMark Level 1.
Why you should publish posts on your own site: see why.
How to publish a post.
- create content (write something, upload a photo, etc.)
- in HTML marked up with h-entry
- posted at a permalink
- on your personal domain
Kinds of Posts
Experience has shown that there are different kinds of posts on indieweb sites, and publishing and display interfaces for them vary by type. Here are a few kinds of posts that indieweb community members are currently publishing:
Roughly ordered by apparent/anecdotal indieweb posting frequency across different sites / implementations:
Posted by only three indieweb sites, worthy of consideration for post type discovery
Posted by only a couple of indieweb sites so far
Posted by only one indieweb site so far:
Posts of various types may also be implicit mentions of other posts by linking to them, but the difference only matters to the receiver — i.e. there is no dedicated UI for people to publish a “mention” of something.
Indieweb community members are working on publishing these real soon now:
Merely gleams in various eyes:
Inferring post kinds from properties
Alternative perspective: instead of explicit post kinds, infer the post kind (and thus presentation/UI) by what aspects/properties a post has. E.g.:
- a post with just plain text content -> note
- with an explicit post name (title) -> article
- with an embedded image (
h-entry) -> photo
- with one or more in-reply-to links -> reply
- with a p-location venue -> checkin
- an h-event event -> event
- with a p-rsvp -> RSVP
- with a u-like-of -> like
- with a u-repost-of -> repost
- with a p-invitee -> invitation
- with a u-tag-of -> tag-of response
The above list is very roughly ordered and likely requires implementation experience (of multiple post types/kinds) to better understand which properties should more primarily determine a post type than others.
Combinations of the above will also have to be explored to see if they make sense, and given multiple possible inferred post kinds, which should "win" in terms of driving the presentation/UI. E.g.
- with an embedded image and with a p-location venue -> checkin with photo. E.g. this post by aaronpk should be considered a check-in. Reasoning:
- the p-location applies to the whole h-entry, not the specific u-photo, thus making the h-entry primarily a checkin, and secondarily, happening to have a photo
- the alternative, a photo post tagged with a venue location, should be expressed by having the p-location be a property of an object nested on the u-photo, e.g. a "u-photo h-item" or "u-photo h-photo" which then has a "p-location h-card" inside it. The actual nested root class (h-item or h-photo, these are (mostly) just brainstorms) matters less than there happening to be such a nested root class.
Articles about implied post types
- 2013-06-23 Ben Werdmüller: The tyranny of content types #indiewebcamp
- 2012-10-22 Aaron Parecki: Creating Content on the Indie Web: IndieWeb Posts
New Post Types
In general, we should avoid creating new post types/kinds.
Both individually and as a community. Simpler is better and all that.
The key is whenever you think you have something new to post, try posting it as your simplest existing post type, which are likely just notes, maybe with tags, e.g. what User:Waterpigs.co.uk does with steps, and User:Sandeep.io does with tags as well. Then document here on the wiki why/how that doesn't work if you run into problems.
One reason why re-using an existing post type might "not work" is that you really want to present it differently, provide a specific UX for a particular kind of posts differently from any existing post type. This is the *primary* reason that should drive any desire to create new post types.
If there's no reason to present a different UX, then you likely shouldn't be thinking about a new post type.
And even if you do want to present a different UX, consider simply using the existence of specific properties (e.g. in-reply-to for replies) to drive the presentation of a different UX, rather than creating a new post type.
If you get that far, step one, document real world examples of such new UX (even from silos) with screenshots/mockups embedded on this wiki.
After you've documented existing UX of a post type, see if you can find something similar in ActivityStreams's similar concept of "object types", and thus re-use their name/terminology.
Related IndieWebCamp discussion sessions:
Pieces of a Post
At a minimum, indieweb posts should have:
- permalink URL
- contents of the post
- date published of the post
- author of the post - even if it's self-evident from the domain.
- avatar of the author of the post
Additional information about the post:
- date updated
- name - (AKA "title") of a post (articles typically have titles)
- location - (AKA "geo") that the post was created or published from, e.g. tweet location. This can be different from the location that a post is about, e.g. photos of a location, Instagram locations are "locations" that the photos are of, Wikipedia uses the geo microformat on pages to indicate location information about the subject of the page, even checkins (which are usually posted at the location, but sometimes after e.g. postsq).
- changes - specifically, notable content updates since original publishing, ideally marked up with
<del>and then styled to be apparent.
- using - tool or application that was used to author / publish the post.
Footer sections. Posts sometimes have footers with links, references etc. Here are few known footer sections with a real world indieweb example in the wild of each.
- Previously - links to previous posts by the author on the same or similar subjects. E.g. 
- References - explicit list of citations supporting the post, from inline hyperlinks in the post, and/or [number] references inline in post text.
- Elsewhere - a list of links to POSSE syndicated copies of the post on other services. E.g. 
- Elsewhere of this Translation - a list of links to POSSE syndicated copies of a post which is a translation of another post.
- Translations - links to translations of the post. E.g. 
- comments - a list of comments (in time sequence order) about or replying to the post. E.g. 
- Referencing Articles / Mentions - other discussions / articles spawned as a result of (after) the post, or other related reading that cites the post. A that reader already took the time to read it and have the post in mind as context, may want to read articles that build upon it. E.g.: .
- likes/favorites - primarily on silos but capturing here as something that indieweb community members have expressed an interest in implementing on their own posts
- tags - often parsed from hashtags within the post. Examples:  
- navigation - usually previous/next links between posts. Examples:    
- ... have a different section in the footer of your posts? Add it here with a link to a real world example.
Inline and other references
Some post to other post or page references are inline in a post or elsewhere but not in a separate footer per se.
IndieWeb community members' thoughts on some of the details of how they post and why:
There's many ways to style and display posts, on their own on permalink pages, as part of a stream (e.g. a home page or feed), and in a collection in an archive.
Here are some posts about post display design:
Here are some tools for testing indieweb posts: