フェディバースのタイムラインに定期的に流れてくる「投稿を編集したい」「編集できるの？」

これは

「サーバーが対応していれば」投稿の編集更新はできます。

ということになる。

自分のいるサーバーが

「投稿の編集」に対応しているなら「編集」して書き直した投稿はホームタイムライン、ローカルタイムラインに反映される。

「投稿の編集」に対応していなければ「編集」するリンクがなかったり「破棄して下書きに戻す」になってたりする、はず。

さらには、投稿の編集に対応している自分のいるサーバーで「編集」しても、フォロワーさんのいるサーバーが対応しているとは限らない。

自分は編集して、ホームタイムラインを見たら誤字も直ってるのに、編集更新未対応のサーバーにいるフォロワーさんのタイムラインでは誤字のまま、ということが起こる。

で、どうしてサーバーごとで対応が違うのかということになるんだけど。

(また、なんか前置きが長くなりそうな…)

ActivityPubの仕様に「Update」というActivityがある。

https://argrath.github.io/activitypub/#update-activity-inbox

これを使ってリクエストを投げれば、文字通り、投稿だけじゃなくてプロフィールなども「アップデート」＝「編集更新」することができる。

仕様上できるとはいえ、投稿(Note)の編集更新(Update)はちょっと考えなきゃいけないこともある。

1)1つの投稿には1つのIDが振られる。

2)IDが(No.123)の投稿「タヌキそばとキツネうどん？そりゃタヌキそばに決まってるよ!」がタイムラインに流れてきたのを読んで「おれもだ!」と賛同の「イイネ」

3)後日、ID(No.123)の投稿を見てみたら「タヌキそば？ぷぷぷ、キツネうどんに決まってんじゃん」

4)え？なんで？おれの「イイネ」はたぬきそばにつけたんだが？

投稿の編集更新は、同じIDなのに、中身が全然違ってしまう、ということが起こるかもしれない。

なもんで、Update、投稿の編集の実装には慎重になるということもあるんじゃないかな。

「編集する」ではなくて「破棄して下書きに戻す」(改めて新規投稿する)

という方法で、別IDを振ることで上記の問題は回避できる。

投稿を編集したい・書き直したい、という要求の一番は「誤字脱字の修正」ぐらいだろうし、そんな神経質にならんでも？

とはいえ、不特定多数の参加するコミュニティだし、リスク回避最優先、てことかなあ。

とか、是非の分かれるところがあったりなかったり。

わたしは、ひとつのIDの中身が変わるのは気持ち悪いんで、削除＆新規投稿の方がいいかなあ(誤字なんかは後からいくらでも湧いてきてキリがないので放置)

編集更新と違って、削除はだいたいすべてのサーバーが対応してるし。

とはいえ、NoteのUpdate実装は手間もないので実装済(送信)

(受信については、ウチはそもそも投稿の保存数が上限20個なので、Updateが流れてきた時にはすでに元の投稿は流れた後、ということもあるんで未実装)

UpdateのActivityが以下

{
"@context": [
    "https://www.w3.org/ns/activitystreams"，
    {
        "Hashtag": "as:Hashtag"，
        "toot": "http://joinmastodon.org/ns#"，
        "Emoji": "toot:Emoji"，
        "sensitive": "as:sensitive"，
    }，
    "https://w3id.org/security/v1"
]，
"type": "Update"，
"id": "https://tokoroten.doncha.net/t2aki/d378b480-a8b3-11f0-a5cb-d391bfe3cb70"，
"url": "https://tokoroten.doncha.net/t2aki/d378b480-a8b3-11f0-a5cb-d391bfe3cb70"，
"published": "2025-10-14T04:11:14Z"，
"actor": "https://tokoroten.doncha.net/t2aki"，
"to": ["https://www.w3.org/ns/activitystreams#Public"]，
"cc": ["https://tokoroten.doncha.net/t2aki/followers"]，
"object": {
    "type": "Note"，
    "id": "https://tokoroten.doncha.net/t2aki/items/05976-20251014"，
    "url": "https://tokoroten.doncha.net/t2aki/items/05976-20251014"，
    "published": "2025-10-14T04:04:32Z"，
    "to": ["https://www.w3.org/ns/activitystreams#Public"]，
    "cc": ["https://tokoroten.doncha.net/t2aki/followers"]，
    "attributedTo": "https://tokoroten.doncha.net/t2aki"，
    "content": "編集更新対応の確認\u003cbr /\u003e→ここは対応している"，
    "updated": "2025-10-14T04:11:14Z"，
}
}

Updateのオブジェクトに、編集したNoteのJSONに「updated」を追加して、リクエストを投げると受け取ったサーバーがUpdateに対応してれば、編集更新を反映してくれる。

↑mstdn.socialで受け取って編集が反映してるところを確認。

ちなみに「updated」の追加が必要なのはMastodonで、Misskey系iceshrimpは「updated」は不要だった。

サーバーごとで微妙に違うことが多いので、やっぱり現物合わせになる…

これもホームページの「おひとり様ActivityPubサーバーの自作実装」に追加しておこう。

EPUB3ファイルの編集にSigilを使ってはいけない、という小ネタ。

epubcheck-3.0.1でエラーも警告もないEPUB3ファイルを、Sigilで編集して保存するとエラーまみれになってしまう、という状況。SigilはEPUB2に完全対応を謳っているけど、EPUB3はどうやら中途半端な対応らしい。

なので、Sigilを通して作るとepubcheckではエラーを吐くことになる。

「かんたんEPUB3作成easy_epub」 で作るEPUB3はepubcheckでエラーのないValidなEPUB3ファイル。

このファイルはEPUB3で、

・toc.ncxは生成していない。

・opfファイルでナビゲーションに指定した文書で、目次とlandmarksを記述。

epubcheck-3.0.1のチェックではエラーも警告もない。

ところが、このEPUB3ファイルをSigil (Mac build 0.7.2)に読み込ませると

toc.ncxがない、というエラーが出る。そのままにしてSigilで開いて何もせずに「別名で保存」してepubcheckにかけるとエラーだらけとなる。

・各xhtmlのDOCTYPEがすべて書き換えられている。

・content.opfに不明なattributeが書き加えられている。

・toc.ncxファイルが追加される。

・content.opfにtoc.ncx絡みの記述が追加される。

・Section0001.xhtmlというファイルが要求されているが作られていない。

上記、Sigilが追加したり編集したりしたものすべてが、epubcheck-3.0.1ではエラーのもととなる。

・各xhtmlのDOCTYPEを元のものに戻す。

・content.opfの不明なattributeを削除する。

・toc.ncxファイルを削除する。

・content.opfのtoc.ncxと絡みの記述を削除する。

・Section0001など覚えのない記述も削除する。

Sigilがわざわざエラーをつけてくれるので、その部分をもう一度編集する必要がある。

EPUB3ファイルの編集加工にSigilは使い物にならない（SigilはEPUB2まで）

愚痴になるけど。epubcheckでエラーがないように四苦八苦して作ったEPUB3ファイルなのに、google様謹製のツール、Sigilを使うと滅茶苦茶にされてしまう。google様か野良ITかどっちを信用するかとなると、当然google様。どっちが間違ってるかということになると、当然野良IT、と判断されることになる脱力感。

とはいえ、今のところ、EPUB3でエラーのあるなしよりも「kindleの登録に使えるか」がポイントだろう。

Sigilで編集加工してEPUBファイルを作って、kindlegenでmobiファイルを作成、kindle previewで見る限り致命的なエラーは出ていない。プレビューワーの本の情報をチェックしても、論理目次もHTML目次、スタートページなど問題はない。

EPUB3対応だけじゃなく、ストアごと、リーダーごとの対応が、まだまだいろいろあって、すんなりいかないことばかりでございますです。

[11/09 17:25:10]

ネットで検索してると電子書籍、EPUB制作にSIgilを使ってうんぬん、という記事・ブログが目につくけど、ちゃんと検証してるのかな。EPUB3になってSigilは使えないということをわかって書いてるのか、疑問。ていうか、Sigilを勧めるのはやめてくれ。

[12/11 16:48:02]

今日時点、わたしの知る限り、縦書きのEPUB3にまともに対応しているアプリは「一太郎 2014」

http://www.justsystems.com/jp/products/ichitaro/feature4.html

SigilなどEPUB2までしか対応していないツールで、無理矢理EPUB3を作るために時間と労力を使うぐらいなら、一太郎を購入した方が早い。

[1/22 11:54:05]

InDesign CC も対応してました。

http://www.adobe.com/jp/products/indesign.html

[01/23 13:02:34]

無料で使えるEPUB3の電子書籍作成サービスなど（kindleやibookstoreで販売実績のあるもの）

【WEBサービス】

・EPUB3::かんたん電子書籍作成

・でんでんコンバーター

【ローカルアプリ】

・かんたんEPUB3作成easy_epub

・青空EPUB3

[更新]2014-02-01 10:40:04

あっと驚く新魔獣狩り。いや内容じゃなくて、新刊が出てたなんて気づかなかった。後書きによると、いよいよあと１～２巻で完結らしい。…おいおい無理だろ。キャラたちの決着がつかないぞ。今回は文成も猿爺も出せなかったじゃないか。てのに、平賀源内なんてのを新たに登場させてページを割く余裕なんてあるのか。

とりあえず話は決着させて、キャラの決着はその後の外伝で、という魂胆か。うん、それならそれでＯＫにしてやろう。

久しぶりに読んだのが「新魔獣狩り11」ここんとこまったく本が読めてなかったんだけど、これは別だった。やっぱりおもしろいなあ。

読書snsのリニューアルも忘れてるわけじゃないんだけど、書き込み系はやることが多くてしんどい、のでひとやすみ。データ取得部分、perlで、ループの中で取るより、sqlで副問い合わせを入れた方が早いところがあってちょっと愕然。体感できる早さの違いなのだ。もしかすると他のところでも同じようなことがあるかも、と思うとまたそれを調べて直していくのがホネっぽくてメゲた、というのも休憩の原因だったりして。とほほ。

どうやら風邪っぽくて、ふしぶしが痛くてだるい。困ったもんだ。

[更新]2012-11-26 12:37:03

とか思ってたら、prototype.jsとrico.jsは便利かもしれん。

ドラッグがうまくいかんのはあきらめた。というか、某大手ショッピングサイトにも納品するページで、テーブルで囲えとかブラウザ互換がとか、レギュレーションと称するものがうるさいので、ベタっとしたページでいくことに方針変換。

別件のリニューアルが伴うページの方で使ってみることにした。いわゆるリキッドスタイルが求められて、ついでにセンタリングもやめたことだし、この手のJavaScriptのライブラリの使いどころだろ、と。

メニュータグの角丸が、画像も使わず簡単に作れちゃうし、ドラッグ＆ドロップも1行で済むお手軽さ。

メニューとかナビゲーション部分を残して、ページ遷移せずに使ってもらうこともできて面白いなぁ。…て、それすると下層ページの実体がなくなってしまう＝SEO的にヤバイ。うーむ、面白いんだけどね。これはこれでそのうち読書SNSとかココとか、時間的気持ち的余裕ができたら使ってみよう。

ただ、デバグするのがメンドーなことにかわりはなくてうっとーしー。FireFoxを使って、エラーコンソールをみるのが比較的やりやすい、かな。

てことで、せっかくの週末も、やってもやっても終わりの見えないページ作りで潰れるのでありました。しょぼ。

[更新]2026-02-04 10:03:58

プラモデルカメラのチープなプラスチックレンズは予想ができない上がりとなるです。気楽にパシャパシャ（プリント代とかコストも考えず）ここんとこシャッター押しまくり。

地元駅前団地とか秋葉原とかアメ横とか勝どきとか。

被写体が面白いのか、プラモデルカメラが面白いのかビミョーな勝負だけど、面白い写真になってなぁ、と。

[更新]2026-02-02 08:35:48