22:38:02
icon

ねもい。寝るか……

17:05:33
icon

FiraCodeっていう、リガチャ(合字)によって、==>などが一体の字形になって表示されるステキフォントがあるんだけど(使ってる。オススメ)
github.com/tonsky/FiraCode

だんだん欲が出てきて、>< とか ><; を合字で表示する機能が欲しくなる……。 @orange_in_space さん専用。

カスタム絵文字と違って、元の情報には一切手を加えないのが魅力。

Web site image
GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures
16:08:08
icon

@achi 仕組みを作っていて、本当にメーリングリストそのものなので、これは……と思いましたw

アーカイブはされないですが、代わりに、各地のサーバに分散して保存されます。

15:42:58
icon

@achi 個人で(送信だけ)ハッシュタグリレーに参加できるようにしたので、ぜひおすすめしたい。タグ付きトゥートだけ拡散されるようになるよ。

relayctl@hashtag-relay.dtp-mstdn.jp にjoinってメンションすると、relayの本体がフォローバックしてくるので、それで完了。解除するときはleave。公開範囲はDMがおすすめ。

普通のリレー参加と違って受信しないので、負荷はフォロワーが一人増えるだけ。ぜひお試しを……。

15:13:12
2019-01-29 14:27:11 らりお・ザ・何らかの🈗然㊌ソムリエの投稿 lo48576@mastodon.cardina1.red
icon

フォロー返しとかいうのを義理でやるとろくでもないことになるので、ちゃんと興味のあるユーザだけ選別してフョヨーすべき

12:16:01
2019-01-29 12:06:15 Alberto Colemanの投稿 i_sparkling@rainyman.jp
icon

このアカウントは、notestockで公開設定になっていません。

12:14:27
2019-01-29 11:45:11 あきょぜの投稿 akyoz@gochisou.photo
icon

このアカウントは、notestockで公開設定になっていません。

11:06:05
icon

さて、豆を買いましょう。

ブラジルセラード・ペルシード
store.shopping.yahoo.co.jp/nel

ヤフーから注文入れますね! @nelsoncoffeeroaster

10:59:51
icon

Samsung NEXTから70,000 USDの寄付を得た件で話題になったOpenCollective、新しい資金提供と貢献者への分配のプラットホームですが、公式のドキュメントにも記載が追加されましたね。
QT: [mastodon.social/@Gargron/10149]

Web site image
Eugen Rochko (@Gargron@mastodon.social)
10:32:59
2019-01-29 09:21:48 Maya Minatsuki :neko_smiley:の投稿 mayaeh@taruntarun.net
icon

このアカウントは、notestockで公開設定になっていません。

10:31:12
icon

Pleroma、リレーの受信は問題なさげ。

relayctlが送信するActivityの何かが原因でタイムラインの読み込みにエラーが発生する症状がでているので、原因解明までPleromaあての送信は失敗するようにしておくことにする。

Mastodon FE(PleromaのMastodonの見た目のフロントエンド)では問題が起きないので、Pleroma FEを調べる。

09:55:57
2019-01-29 08:52:48 刺繍屋🐏おっちょこちょいの投稿 emb@gingadon.com
icon

このアカウントは、notestockで公開設定になっていません。

06:02:46
icon

ふむ。pleromaインストール簡単だなぁ。実質、brew install elixir しただけやん……。

05:18:11
icon

【DTP-Mstdn.jp】
HEAD is now at 28866d329 Bump version to 2.7.1 (#9932)

Mastodon v2.7.1になりました。
github.com/tootsuite/mastodon/

05:05:49
icon

まぁ、非互換性といっても、一つ一つは些細なモノです。

ただし、どんなに些細な違いでも、エコシステムに致命的な影響を与えることがあります。

APIの破壊的変更を伴って、辛うじて生き延びていた古いバージョンのサーバやクライアントが死滅するかもしれません。まぁ、隕石が衝突したみたいな話ですね。

リレーの話で言うと、PleromaのinboxにPOSTする(Activityを送信する)際に、Content-Type : application/activity+json をちゃんと送信する、というのがありました。

pub-relay、何も送らないんですが、そうするとPleromaがHTTP 500エラーを吐きますw

Mastodonは動いちゃう。

いま、MisskeyからのPublicKeyがデコード出来ないってエラーでハマっています。解決方法は確認中です。まぁ、そういう話です。

なんか難しい話してる、としか思えないかと思いますが、恐らくActivityPubを扱っている人ならだいたい同じトコで悩むことが多いと思うんですよね……。

04:48:10
icon

ハッシュタグリレーは、Mastodon本家のリレー(pub-relay / Crystal言語で書かれた配送にsidekiqを用いるバージョン / 作成者はChris Hobbs)から派生して書かれているのですが、

この本家リレー、ActivityPubベースでやりとりするようになっていて、一応はFediverseに向けた汎用目的になっていますが、実際はMastodonの実績はなく、そのままで機能するようにはなっていません。細かなところで非互換があって、実装間の差異を埋めていくには、ActivityPubの実務に詳しくなっていくしかなさそうです。

現在、少しずつActivityPub対応のコードを書く人が増えてきているように観測していますが、情報交換を行ったり、その記録を残したり、非互換の解消を働きかけたり、一緒にやれることについては協力できるといいなと思ったりします。

04:29:44
icon

ちょっと簡単に言い直しますw

現状、Pleromaのハッシュタグリレー対応には、ちょっとPleromaの改造が必要になりそうです。
dtp-mstdn.jp/@noellabo/1014958

Web site image
のえる :cava_red: DTP鯖管 (@noellabo@dtp-mstdn.jp)
04:26:52
icon

信頼できる署名(LDS)があれば、どれだけ多くのリレー先に届けても、送信元の負荷は一定です。リレーに預ければ、それで終わりです。

ところが、リレー先が一斉に送信元にデータを確認しにいく実装となると、リレー先が増えれば増えるほどアクセスが集中することになり、多大なる負荷となります。(nginx等でキャッシュすることで大幅に負荷を軽減できますが、依然としてリレーより負荷が高くなります)

やはり、PleromaにLinked data Signaturesのサポートを追加するのが現実的であるように思います。

04:26:33
icon

Mastodonの場合、LDSが含まれるため、信頼できると確認できますが、Pleromaではこれができません。

Mastodon側で対応する方法としては、Activityに含まれる本来の送信元へ問い合わせして、裏付けをとるという方法があります。

投稿であれば、実際の投稿内容を取得して、一致しているかどうか確認すればいいわけです。動作としては、おおよそブーストの場合と同じです。(我々はフェッチしにいく、という言い方をします)

削除であれば、HTTP 404 Not Foundか、Tombstone(削除されたことを示す《墓石》)になっていることを確認すればいいわけです。

ただし、この実装は著しく非効率です。

Pleromaのリレー実装が、このようなブーストベースのものになっているということですが(詳しく見ていません)、コンセプトはともかく、実用上は現実ではないと言われています。

雪餅(2018) 連合リレーと Activity Relay
blog.yukimochi.jp/2018/12/fedi

04:26:10
icon

リレーのPleroma対応、現在の結論としては、PleromaにLinked data Signatures(LDS)のサポートを追加するのが最善という判断です。

--

PleromaのActivityには、LDSによる署名が含まれておらず、リレーから送信されてきたActivityが信頼出来るかどうか判断できません。

そのため、リレーから送信するところまでは動作するのですが、受け取ったサーバが拒否します。

通常の連合では、HTTP Signaturesによって、送信元、送信先、日時、送信内容(Activity)のハッシュを署名して送信し、受け取った側でそれを検証することで、改ざんされていない内容であることを確認しています。

Pleromaでは、これで必要十分であるとして、LDSのサポートを省略しています。

ところがリレーの場合、送信元が元の送信元ではなくリレーになるため、Activityの送信元と不一致で信頼できません。