2026/Micropub
The Micropub session was conducted on 2026-01-31 via Zoom.
Watch: ▶️ 01:53:28s
- Notes archived from https://etherpad.indieweb.org/2026-01-31-micropub
Participants
Anthony CiccarelloDavid Shanske
Aaron Parecki
benjiJoe Crawford
Ross A. Baker, distracted by a broken furnace- ... add names
Proposed Issues on the Micropub Spec to Discuss
https://github.com/indieweb/Micropub/issues
- https://github.com/indieweb/Micropub/issues/12 - The actual spec does not discuss how extensions may become part of the spec, if they should, and process for extensions could use some refining in general.
- Several extensions could be absorbed into the spec, most specifically
- https://github.com/indieweb/Micropub/issues/13 - Standardizing some query returns using established extensions
Main Micropub Extension Lists
- The process for stable extensions becoming official does not need to be part of the spec
- there are a short list of relatively-stable extensions that should be moved into the main spec
Reviewing Stable Extensions
- mp-slug:
- Wiki permalink
- Resolution: Agreement to add to spec
- post status
- Wiki permalink
- GitHub Issue
- Resolution: Agreement to add to the spec
- Do not close off the option for other statuses
- Visibility
- Wiki permalink
- GitHub Issue
- The definition of how to implement "private" or "unlisted" is left up to the server
- Options could be displayed in a different language
- Wordpress has a "sticky" checkbox but that is out of scope
- Resolution: Agreement to add to the spec
- Query for supported vocabulary
- Wiki permalink
- GitHub Issue
- What should happen when a post type is not supported by a client (ignored?)
- There are lots of additional discussions around this feature
- The spec references the post type discovery types
- Someone may want to add additional post types but clients would not be be expected to show unsupported types
- Post type discovery can/should continue to evolve (e.g. watch types)
- Resolution: Agreement to add to the spec
- Query for post list
- Wiki permalink
- GitHub issue
- Resolution: Too few implementations: (micro.blog not present to confirm, Indiepass for Android has been deprecated)
- Tag List
- Returning all tags might be too much
- Could add auto-complete string matching with a filter
- Resolution: Too few implementations but lots of interest in experimentation (quill, omnibear)
- Limit parameter
- Wiki permalink
- GitHub issue
- Quill only uses this from the media endpoint
- Benji uses on media endpoint on server/client
- As defined it is too generic
- Doesn't make sense for some queries (e.g. post-types)
- Resolution: Due to ambiguity, this should be moved out of stable, consider focusing only on media endpoint
- Destination
- Wiki permalink
- GitHub Issue
- Different from syndication (also sharing to Twitter)
- Aaron uses this to share to different websites than his main site
- Resolution: Too niche. Move out of stable
- Media endpoint extensions
- Lots of discussion history but nothing stable
Standardization of Extensions
- We say "the core Micropub spec isn't expected to change" but should that change?
- The config query is core but can be extended
- mp-slug is a suggestion for the server
- Anthony Ciccarello doesn't support private post to post visibility but knows that when using a client
- For users who don't control client/server there could be confusion if client indicates a feature not actually supported
- Could add a way for clients to negotiate if a feature is supported
- All clients should be expected to implement the whole spec
- Extensions are optional
- Stable extension definition should be amended to require projects are actively developed
- Features like querying contacts or location should probably never be in the core spec
- Missing understanding of if clients support current stable extension (e.g. post-status)
- To be brought into core, it should have interoperability
- Do extensions need to be stable for a certain amount of time before being made official
- ITEF has 3 annual meetings for discussion, but those aren't where they are standardized
- Decisions can be made async
- This meeting is more like a working group
- Other organizations usually have more organized leadership (e.g. a chair to determine concensus)
- Who can make the judgement call
- MCP group has "sponsors" of extensions to represent it
- Could have a shepherd/sponsor for micropub extensions who are responsible for pushing things forward
- To standardize as official, get a minimum number of people (implementors?) on a call
- Shepherd/sponsor is responsible for scheduling
- There could be a long time to get things standardized, but that is acceptable
- Should define what group of people is authorized (implementors & spec involvement)
- David will continue gardening
- W3C Social Web Working Group is spinning up again, could try to standardize there
