Article

Less Clutter, More Cwtch

Tŵt’s going mobile!

We love the community we’re building here on Tŵt. It’s a warm, friendly space on the Social Web. But we also know that for many of you, social happens on your phone.

Connecting to Tŵt on your phone has always been a bit of a bother, especially when it comes to plugging in our domain instead of the default or suggested services. These apps work great, but they aren't built for the average everyday person. They're all a bit techy, and they don't reflect our […]

Article

WordPress Federation: Recap of 2025

With 2025 behind us, this post looks back at the roadmap we set out last year, what we worked on, and what shipped along the way. It reviews progress across core areas like moderation, following, and the experimental Reader, and highlights additional work that emerged throughout the year as we look ahead to 2026.

Maximally Semantic Structure for a Blog Post

https://shkspr.mobi/blog/2026/01/maximally-semantic-structure-for-a-blog-post/

Yes, I know the cliché that bloggers are always blogging about blogging!

I like semantics. It tickles that part of my delicious meaty brain that longs for structure. Semantics are good for computers and humans. Computers can easily understand the structure of the data, humans can use tools like screen-readers to extract the data they're interested in.

In HTML, there are three main ways to impose semantics - elements, attributes, and hierarchical microdata.

Elements are easy to understand. Rather than using a generic element like <div> you can use something like <nav> to show an element's contents are for navigation. Or <address> to show that the contents are an address. Or <article><section> to show that the section is part of a parent article.

Attributes are also common. You can use relational attributes to show how a link relates to the page it is on. For example <a rel=author href=https://example.com> shows that the link is to the author of the current page. Or, to see that a link goes to the previous page in a series <a rel=prev href=/page5>.

Finally, we enter the complex and frightening world of microdata.

Using the Schema.org vocabulary it's possible to add semantic metadata within an HTML element. For example, <body itemtype=https://schema.org/Blog itemscope> says that the body of this page is a Blog. Or, to say how many words a piece has, <span itemprop=wordCount content=1100>1,100 words</span>.

There are many properties you can use. Here's the outline structure of a single blog post with a code sample, a footnote, and a comment. You can check its structured data and verify that it is conformant HTML.

Feel free to reuse.

 HTML<!doctype html>
<html lang=en-gb>
<head><title>My Blog</title></head>
<body itemtype=https://schema.org/Blog itemscope>

<header itemprop=headline>
<a rel=home href=https://example.com>My Blog</a>
</header>

<main itemtype=https://schema.org/BlogPosting itemprop=blogPost itemscope>
<article>
<header>
<time itemprop=https://schema.org/datePublished datetime=2025-12-01T12:34:39+01:00>
1st January, 2025
</time>
<h1 itemprop=headline>
<a rel=bookmark href=https://example.com/page>Post Title</a>
</h1>
<span itemtype=https://schema.org/Person itemprop=author itemscope>
<a itemprop=url href=https://example.org/>
By <span itemprop=name>Author Name</span>
</a>
<img itemprop=image src=/photo.jpg alt>
</span>
<p>
<a itemprop=keywords content=HTML rel=tag href=/tag/html/>HTML</a>
<a itemprop=keywords content=semantics rel=tag href=/tag/semantics/>semantics</a>
<a itemprop=commentCount content=6 href=#comments>6 comments</a>
<span itemprop=wordCount content=1100>1,100 words</span>
<span itemtype=https://schema.org/InteractionCounter itemprop=interactionStatistic itemscope>
<meta content=https://schema.org/ReadAction itemprop=interactionType>
<span itemprop=userInteractionCount content=5150>
Viewed ~5,150 times
</span>
</span>
</p>
</header>

<div itemprop=articleBody>
<img itemprop=image src=/hero.png alt>
<p>Text of the post.</p>
<p>Text with a footnote<sup id=fnref><a role=doc-noteref href=#fn>0</a></sup>.</p>

<pre itemtype=https://schema.org/SoftwareSourceCode itemscope translate=no>
<span itemprop=programmingLanguage>PHP</span>
<code itemprop=text>&amp;lt;?php echo $postID ?&amp;gt;</code>
</pre>

<section role=doc-endnotes>
<h2>Footnotes</h2>
<ol>
<li id=fn>
<p>Footnote text. <a role=doc-backlink href=#fnref>↩︎</a></p>
</li>
</ol>
</section>
</div>
</article>

<section id=comments>
<h2>Comments</h2>
<article itemtype=https://schema.org/Comment itemscope id="comment-123465">
<time itemprop=dateCreated datetime=2025-09-11T13:24:54+01:00>
<a itemprop=url href=#comment-123465>2025-09-11 13:24</a>
</time>
<div itemtype=https://schema.org/Person itemprop=author itemscope>
<img itemprop=image src="/avatar.jpg" alt>
<h3>
<span itemprop=name>Alice</span> says:
</h3>
</div>
<div itemprop=text>
<p>Comment text</p>
</div>
</article>
</section>
</main>
</body>
</html>

This blog post is entitled "maximally" but, of course, there is lots more that you can add if you really want to.

Remember, none of this is necessary. Computers and humans are pretty good at extracting meaning from unstructured text. But making things easier for others is always time well spent.

#blogging #HTML #schemaOrg #semanticWeb
Article

There Is One Fediverse. There Are A Thousand Ways To Join It.

When I showed my sister-in-law my toot.wales feed, she gave the response I believe most people genuinely feel: "It is lovely! If only there was an app." She does not want a protocol or a lesson in the Fediverse; she just wants a simple way to connect with her community. That is why we have built the Tŵt app. It is a straightforward, bilingual, and jargon-free front door for Wales on the social web. Here is why we are choosing clarity over complexity to build a better social experience.

Vendor lock-in is hostile to the Fediverse

I’ve just had to part ways with my previous Mastodon server for ethical reasons, so I thought I’d take the chance to write up why and also how.

One of the defining features of legacy social media platforms is the reliance on inertia to keep users trapped. All your friends are on Facebook, so you don’t want to leave because you’ll lose touch with them. You’re used to the way the Instagram app works and you don’t want to learn your way around a new one. Yes, Twitter/X is a cesspit full of the sort of things you’ve specifically created laws against, but you have a lot of followers and no spine so you’re still there when other governments are banning it entirely because of all the CSAM and deepfake porn. Legacy social media weaponises your fear of change and the mental bandwidth needed to get used to something new.

Federated social media like Mastodon is different. The server your account lives on can communicate with any other server that runs the ActivityPub protocol, you can interact with it using any compatible app and at any time you can pack up and move to a different server without losing your connections and having to start over from scratch. You can use the same app you used to use on mastodon.social to connect to beige.party or jorts.horse.

The Mastodon instance I used to be on recently announced that it’s getting its own mobile app:

Connecting to Tŵt on your phone has always been a bit of a bother, especially when it comes to plugging in our domain instead of the default or suggested services. These apps work great, but they aren’t built for the average everyday person. They’re all a bit techy, and they don’t reflect our community the way we want to be presented. So, we’re building our own app.

I should stop here to say that I don’t believe plugging in a server’s address once when you first set up an app is “a bit of a bother” or “a bit techy”. The “don’t worry your pretty little button head about it” tone is incredibly patronising and an insult to your intelligence, but what I believe is not the important part.

If that’s what Tŵt Cymru believes, then releasing an app that’s locked to their instance is a cynical attempt to make it more difficult for less technical users to migrate away from their server, because leaving means they’d have to find, install and get used to a whole new app. The exact same shady tactic that legacy social media sites use to keep people locked into their service.

We envision a future where many other communities have their own branded, custom apps just like this one, apps that tie directly to their server and remove the hurdles that keep people apart.

Once of the greatest strengths of the Fediverse is the decoupling of the server from the app you use to connect to it. Interfering with that decoupling is a disservice to you, the user, in service of a site operator who wants to parasitically benefit from federation while making it more difficult for users to leave.

So what do you do if your instance’s admin joins the Dark Side?

In the spirit of “educate, don’t patronise”, here’s the process I went through to migrate from toot.wales to beige.party.

The first thing to do is to visit https://yourinstance.com/settings/export in a web browser, and download all your data. You should probably do that periodically whether you think your instance admins are up to shenanigans or not. Instances can offline without warning, and it’s best to be prepared.

Screenshot of the Export page in Mastodon settings

The posts archive isn’t very useful yet, as there’s currently no way to migrate the content you’ve created to a new instance. The important bit for migration is the CSV files in the right column.

Once you’ve found a new instance to move to, you first need to create an alias by entering your old account in the account settings of your new account.

Screenshot of the account settings of the destination account, showing the alias

Once you’ve done that, log into your old account and confirm the move from that end by entering your new account’s handle. You’ll need to enter your password to confirm it, because once you hit the “Move followers” button your followers will be permanently moved to the new account.

Screenshot of the old account's settings page showing the account migration from the source end

A bit of manual tidying up

Unfortunately moving your followers is as far as the automatic migration process goes, but you can use the CSV files you downloaded from your old server in the first step to manually import the people you’re following, your lists, mutes, blocks, and bookmarks. Ideally this would all be automatic too, but this flow doesn’t seem to be much of a priority for Mastodon. I’m going to make the charitable assumption here and say they’re prioritising features that people will use every day over ones that people should hopefully have to use rarely if at all, but this is one of those things that’s quite important despite how infrequently it’s going to be used so I think it would benefit from a little more love.

You’ll also have to fill in your profile details again, because those don’t migrate either.

 

#fediverse #mastodon
Article

New Social Web Working Group at W3C

Today the W3C standards organization announced a new working group to advance the ActivityPub and Activity Streams standards. The Social Web Foundation, as a W3C member organization, will be participating in the group. The working group's goal is to release a backwards-compatible iteration of each specification in Q3 of 2026.

Activity Streams was released in 2017, and ActivityPub was released in early 2018. Since that time, the experience of hundreds of implementers and millions of users has […]

Fediverse Report – #148 – On Protocol Governance

The W3C has announced a new Social Web Working Group, starting January 15, 2026, to maintain and update the ActivityPub protoocol. The group will be chaired by Darius Kazemi, who created Hometown Mastodon fork and the Fediverse Schema Observatory. The aim of the Working Group is to release updates to ActivityPub, and its specifications such as Activity Streams and Activity Vocabulary. Most of the work on the protocol is scheduled to be done by Q3 2026, with the Working Group running until January 2028.

To understand why this matters, some context on how the W3C operates is necessary. The standards organisation distinguishes between Community Groups and Working Groups. Community Groups are open to anyone and serve as incubation spaces for ideas. Since 2018, the Social Web Incubator Community Group (SocialCG) has been the steward of ActivityPub. While Community Groups serve as a grass-roots place, they are very limited in publishing official documentations and formal updates to protocol standards. Working Groups, by contrast, are the bodies that can actually publish official W3C Recommendations, meaning formal standards. Participation in Working Groups is restricted to representatives of W3C member organisations (which pay membership fees on a sliding scale) and invited experts approved by the chair.

ActivityPub became a W3C Recommendation in January 2018, and the protocol work was done by a Working Group. After ActivityPub became an official W3C specification, this Working Group disbanded, and the SocialCG was formed. Since then, the specification has not been formally updated, despite significant implementation experience revealing ambiguities and missing features. The SocialCG has maintained an errata document and developed extensions through the Fediverse Enhancement Proposal process, but these carry no official W3C status. The new Working Group changes this by providing a formal path to update the core specification.

Fediverse advocates regularly point to ActivityPub being a W3C standard as a mark of legitimacy, but for the past seven years the organisational structure that created the protocol has also prevented necessary updates to it. The W3C has done a massive service to the community by holding space for the creation of the protocol in 2018. But since then, the same organisational structure that allowed the protocol to be created also slowed down necessary further work on ActivityPub. This shows up both in errata documents not becoming part of the formal documentation, but also larger work on the Client-To-Server part of the ActivityPub needing more work in order to be suitable for larger adoption.

The new Working Group for ActivityPub changes this situation, and there now a formal path to update the core specification, incorporate errata, and potentially advance new work like LOLA (Live Online Account Portability) to official status. LOLA is a proposal for server-to-server account migration that would allow users to move between ActivityPub servers while retaining both their posts and their social graph. Unlike the current Move activity that only migrates followers, LOLA would enable full content portability. The charter includes LOLA as a potential deliverable, which means it could become an official W3C specification rather than remaining a community proposal.

The are some major complicating factor however, and that is about who actually gets to make decisions. The Community Group lacked power to make official chances to ActivityPub, but it did provide an open place for anyone to participate. In contrast, the Working Group requires participants to either be a paid W3C member or to be an Invited Expert. There are only two organisations that are active in the fediverse that are a paid member of the W3C: Meta and the Social Web Foundation. With the Social Web Foundation also receiving funding from Meta, the company that built Threads now has more institutional standing in ActivityPub governance than any of the organisations actually building open fediverse software. Mastodon gGmbH, Framasoft, and others are not W3C members and cannot participate in the Working Group unless they are invited.

This is by all accounts an extremely funny outcome for a network that aims to be independent of Big Tech’s power.

A few nuances to this. It is unclear if Meta will actually participate in the Working Group, and considering they recently put their Threads<>fediverse integration on maintenance mode, there is a good change that Meta has no interest in actually participating. The Working Group also has yet to communicate who the Invited Experts will be. It could theoretically be that Meta is absent from the group, while Mastodon and Framasoft employees are invited to be part of the Working Group.

Another challenge for the W3C Working Group is that there has long been a disconnect between ActivityPub protocol development and the people creating ActivityPub software. While the above makes it sound that fediverse developers are excluded from the protocol development process, the practical reality is also that the developers of the main fediverse platforms like Mastodon, PeerTube and Lemmy have shown very little interest in engaging with the process when it was openly accessible under the SocialCG. This is illustrated by the meeting last year in which the SocialCG voted to charter a Working Group, where no member of any of the fediverse platform developers was actually present. There has long been a disconnect between the people who develop ActivityPub software and the people who maintain the ActivityPub protocol, with only a few notable exceptions.

This matters because of how W3C standards work. The charter’s success criteria states that updating the Recommendation requires “at least two independent implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites.” The Working Group can propose whatever changes it wants, but for those proposals to become part of the official ActivityPub standard, they need to be implemented in actual software.

LOLA, the proposal to improve account portability, is a clear example of this challenge. Already in fall 2024, Lisa Dusseault, the author of the proposal, said that the specification was ready for developers to start testing implementations. The main bottleneck since then has been getting organisations like Mastodon interested in actually building it. The protocol work is largely done, but what remains is the persuasion and coordination to get implementers interested in using it.

The importance of protocol maintenance and further development of ActivityPub points towards responsibilities for software implementors, especially Mastodon as the dominant ActivityPub implementation. Mastodon’s choices become de facto standards whether or not the project engages with formal standardisation processes. The most clear example is how the Mastodon API has effectively taken over from ActivityPub’s Client-to-Server as the dominant protocol that other softwares have to implement. That position comes with obligations, and when Mastodon doesn’t participate in protocol governance, it creates a vacuum where the largest implementer (in this case also Mastodon) is able to set standards for the rest of the network, but without the governance or formal documentation. When protocol development and maintenance in the Working Group happens disconnected from the largest implementations, the specifications that may not reflect implementation realities.

What this situation reveals is that using network architecture to solve issues of power distribution simply shifts bottlenecks rather than eliminating them. A decentralised protocol does not automatically produce decentralised governance, it also moves power to different, less visible places. The W3C membership structure concentrates formal power in ways that don’t reflect the fediverse’s values, while the implementers who could counterbalance that power have largely opted out of the process. The new Working Group creates an opportunity to address both problems, but who gets to shape the specifications of ActivityPub depends on both who is allowed to participate, as well as who is willing show up and do the work.

#nlnet

https://connectedplaces.online/reports/fediverse-report-148-on-protocol-governance/