diff --git a/content/notes/real-name-policies.md b/content/notes/real-name-policies.md
index 6aa6b56..163b0b0 100644
--- a/content/notes/real-name-policies.md
+++ b/content/notes/real-name-policies.md
@@ -1,6 +1,7 @@
---
title: "Real name policies"
date: 2023-10-31T06:31:21-07:00
+lastmod: 2023-10-31T18:11:51Z
replyURI: "https://fosstodon.org/@drewdevault/111329549329662520"
replyTitle: "Send me your thoughts on “real name” policies in free software contributions"
replyType: "SocialMediaPosting"
@@ -19,5 +20,5 @@ The primary, hopefully-unintended function of a "real-name policy" is to exclude
There's plural systems. And trans users who haven't made a full break from their deadname(s) yet. And at-risk users who would be doxed by such a policy. And folks who simply feel more comfortable with online handles than meatspace names, for no special reason in particular.
-What incredible benefits could be worth shafting all these people? Assuming you even manage to pull it off; see {{}}{{}} by {{}}{{}}.
+What incredible benefits could be worth shafting all these people? Assuming you even manage to pull it off; see {{}}{{}} by {{}}{{}}.
diff --git a/content/posts/cli-best-practices.gmi b/content/posts/cli-best-practices.gmi
index 510c01b..9e48f63 100644
--- a/content/posts/cli-best-practices.gmi
+++ b/content/posts/cli-best-practices.gmi
@@ -138,7 +138,7 @@ These considerations are far more subjective, debatable, and deserving of skepti
8. Don’t conflate CLIs and TUIs. A CLI should be non-interactive; a TUI should be interactive. Exceptions exist for really simple interfaces (e.g. Magic-Wormhole and others like it) that accept user input; however, as the interface grows more complex, consider splitting the program into two sibling programs, one of which can have a “pure” non-interactive CLI.
9. Go above and beyond by writing separate integrations for environments like Emacspeak.[9]
-=> http://emacspeak.sourceforge.net/ Emacspeak homepage
+=> https://github.com/tvraman/emacspeak Emacspeak homepage
## Name conflicts
diff --git a/content/posts/cli-best-practices.md b/content/posts/cli-best-practices.md
index dfb0e13..c5840b5 100644
--- a/content/posts/cli-best-practices.md
+++ b/content/posts/cli-best-practices.md
@@ -162,7 +162,7 @@ These considerations are far more subjective, debatable, and deserving of skepti
8. Don't conflate CLIs and TUIs. A CLI should be non-interactive; a TUI should be interactive. Exceptions exist for really simple interfaces (e.g. Magic-Wormhole and others like it) that accept user input; however, as the interface grows more complex, consider splitting the program into two sibling programs, one of which can have a "pure" non-interactive CLI.
-9. Go above and beyond by writing separate integrations for environments like [Emacspeak](http://emacspeak.sourceforge.net/).[^9]
+9. Go above and beyond by writing separate integrations for environments like [Emacspeak](https://github.com/tvraman/emacspeak).[^9]
Name conflicts
--------------
diff --git a/content/posts/spoiler-element.md b/content/posts/spoiler-element.md
index f0d5b51..9561561 100644
--- a/content/posts/spoiler-element.md
+++ b/content/posts/spoiler-element.md
@@ -2,6 +2,7 @@
title: "Proposal: an HTML element for spoilers"
description: "An informal proposal for dedicated elements for spoiler tags in HTML: use-cases, syntax, semantics, recommended UA behavior, and comparisons with “details”"
date: 2023-11-12T13:48:00-08:00
+lastmod: 2023-11-29T13:09:39Z
outputs:
- html
- gemtext
@@ -11,7 +12,7 @@ syndicatedCopies:
- title: 'Lobsters'
url: 'https://lobste.rs/s/v1yooo/proposal_html_element_for_spoilers'
- title: 'WICG Discourse'
- url: 'http://discourse.wicg.io/t/standardized-spoiler-tag/5814/15?u=seirdy'
+ url: 'https://discourse.wicg.io/t/standardized-spoiler-tag/5814/15?u=seirdy'
- title: 'IndieNews'
url: 'https://news.indieweb.org/en'
- title: 'jstpst'