From IndieWeb
Jump to: navigation, search

Jacky Alciné

“Hey look,” [thumps table] “Microformats.” [laughs].

I really enjoy working on software and making it more simple to use for anyone interested. That said, I really like keeping my content on my own terms. You'll see that a lot of sections below might be out of date but will point to parts of my personal site that you can reference for more up to date bits.

At the time of writing,, my personal site is Level 1. However, work is being done to skip to Level 3 by means of Koype.

Reasoning for IndieWeb

I (Jacky) can't remember how I stumbled upon the IndieWeb. My blog posts did show a transition but now it's become something I'm very passionate about. It's potentially the tooling we can use to help remove the heavy corporate influence in social media as well as making for more organic and natural places to be ourselves on this big world wide Web.


I work on a few projects to make my experience of the IndieWeb more pleasing and easier.


This is a place for me to drop some itches, ideas and thoughts around IndieWeb building blocks that I'd want to build and/or add to my personal site and projects.

  • Event management site dedicated for IndieWeb members
  • IndieWeb compatible (or -first!) app store
  • Native libraries to interact with IndieWeb sites
  • Simpler detection of what text formats a site can accept for Micropub
  • Elixir library for general purpose IndieWeb stuff
  • CLI tool for generating code snippets that are posted on my site
  • Question support [1]
  • List of other sites presented on my site
  • Protected content
  • Micropub media endpoint that allows me to use Nextcloud as my storage layer.
  • integrity of posts in the IndieWeb
  • Implement a tool to generate some common Wiki templates from user provided information to reduce barrier to contributing to the Wiki

Interactive Canonical Guides

As mentioned lightly in chat, having a site / set of pages that can serve as living examples of how the IndieWeb can work for one's site. Ideally, this would be concepts / ideas that have been implemented and works on a diverse array of sites and architectures. Things we can do for this would be:

The pages could be both descriptive and interactive, similar to but in our case, we'd encourage people to use their own sites to do the "interactivity" and have these pages respond in real-time to their changes (like when they send Webmentions or handle rel-me verification).

The goal of the page is allow people (namely developers or code-friendly people) to "tinker" on their site in real-time and get immediate feedback.

Post Type "Linting"

In hopes of improving theme creation for Koype, I wanted a way to hit a service and determine what kind of post type information it'd determine the page to have.


  • Visit the service
  • Enter the URL I want to 'validate'
  • Report back on the discovered post types as well as the properties discovered

Wrote a bit about this on my site.

Syndication to my Newsletter

I currently keep a newsletter by using Buttondown. I'd like to leverage their ability to add a entry by using their privileged e-mail addressing service.


  • Sign up on Buttondown
  • Get the private email
  • Provide a Webmention endpoint that knows what email address to use

I wrote the initial idea on my site.

2019-04-06: Piloting this idea under the project name "driftcask".

Gitea + IndieWeb Support via Webmention

I want to see if I hack the following features into Gitea (and maybe use it as a test bed for other kind of version control projects):

Opening Issues via Webmention

I'd want to be able to open an issue on a project by sending a Webmention to the repository's URI! This will require a new "issue-of" property / type so I can open them up there.

  • TODO: Figure out flow and response.

Replying Issues via Webmention

Submitting a response should be just as easy!

  • TODO: Figure out flow and response.
  • TODO: Figure out how to handle idempotent messages.

Submit Patches / Changes to a PR

Send changes to a PR that an author has permission to update with the provided patches in the sequential order specified.

  • TODO: Figure out flow and response.
  • TODO: Maybe leverage git-send-email.

GitLab supports sending patches and opening tickets via (privileged) e-mail

Send Webmentions in Linkable Text Regions

Final step would be to receive said mentions whenever a URI of the user or the nickname of the user is mentioned:

  • Text in a commit message
  • In a comment made in
    • Merge request
    • Issue text

Syndicator Detection

I'd want to have a way to detect and authenticate with a site that provides h-x-app information to expose what kind of syndication targets it can provide. The MF2 could look something like:

<section class="h-x-app h-syndicator">
  <h3 class="p-name"><a href="" class="u-uid u-url">App</a></h3>
  <p class="e-content">This service can retrieve syndication requests to the following sources:</p>
    <li><a href="#" class="u-target p-name">Twitter</a></li>
    <li><a href="#" class="u-target p-name">GitHub</a></li>
    <li><a href="#" class="u-target p-name">Mastodon</a></li>
    <li><a href="#" class="u-target p-name">Newsletter</a></li>

The above would expose to a site in question that the app can syndicate to a particular set of destinations. One could then use these values (u-target) in their syndication endpoint. Ideally, the app would know which user it's coming from based on the host name provided or via a webmention to determine the user in question.

Format Detection

A request to one's Micropub endpoint can give information about the kind of formats in which one can set information to for creating new contet.


Another option to query from a Micropub client. The fields that come back under 'formats' would have the keys:

  • name: The name to show to the client
  • uid: The unique ID that the Micropub server would recognize.
  • help: Link to help information about formatting options.

If we use common UIDs all around then clients can switch to compatible editors with no problem.

GET /micropub?q=formats&for[]=entry

  "type": ["h-entry"],
  "formats": [
      "name": "GitHub Flavored Markdown",
      "uid": "markdown+ghe",
      "help": ""
      "name": "Gruber's  Markdown",
      "uid": "markdown",
      "help": ""
      "name": "Liquid",
      "uid": "liquid",
      "help": ""

Posting With it

Similar to the create flow for Micropub.

POST /micropub?h=entry&content[type]=markdown-ghe&content[formatted]=<FORMATTED>

201 Created

Updating the Clients Page

One thing that's clear is that both Micropub/Clients and Microsub#Clients have a lot of information but it's not uniform. Here are some ideas:

Leveraging Tables

I'm proposing that we have a Clients page that does something like the table below:

Clients for the IndieWeb
Name Platform Supports
Indigenous (Android) Android Micropub, Microsub, IndieAuth
Indigenous (iOS) iOS Micropub, Microsub, IndieAuth

The cons to this flow is that it makes it hard to view and edit over time for those not too familiar with the Wiki syntax.

Leveraging Template

We use templates for highlighting people Jacky Alciné and chat boxes; we could implement one for clients and make it easy to have them present just enough information to get going. Some information we'd need:

  • a decent screenshot of what a high traffic / activity of the app looks like
  • (optional) a video of app launch, sign in and use
  • mentions of the things it supports spec-wise

See Also