Yayaka19 は私のほしいものに近い気がする。ただ、この名前では覚えてもらえないかなあ。
itmedia.co.jp/news/articles/17

ブースト時刻について語っていたらプルリクエストを書いてくださった方が登場

github.com/tootsuite/mastodon/

@tomoya0x00 外見上は似てるんですが、Twitterは唯一表示されている時刻は発言時刻ではなくリツート時刻なんですよねえ。微妙だが重要な違いのような気がします。

@tomoya0x00 そうですね。今、確認したら、たとえばAndroidのSubway Tooterではブースト時刻が表示されますね。でも、標準のWeb UIで表示されない理由がわからない(デザイン上の理由?)

@tomoya0x00 通知で「何分前」とか表示されているのは発言された時間で、ブーストされた時間ではないようです。

言い換えると、「いつ」の発言かも重要だけど、その発言が「いつ」ブーストされたのかも同じくらい重要。しかも、前者はリンクを辿って調べられるけど、後者は他に知る方法がない。

マストドンはなぜ通知に時刻が表示されないのだろう。「いつ」フォローされたのかとか、「いつ」ブーストされたのかとかは重要な情報だと思うんだけど。

@masakiishitani 特にパソコンポケットの発想が良いですね。今日も空港に行きましたが、セキュリティゲートをくぐるときの便利さ

@masakiishitani 愛用してます。私のユースケースだと小さめのポケットがもうひとつふたつあるとベストでした。

Thanks for having me at the Mastodon Kaigi 3, for the questions, for using Mastodon, and for caring about decentralization!

@ogochan NetNewsはねえ、とにかくサーバーの管理が面倒なんですよね。苦労する割に現代風サービスに比べたメリットがない。

結局、いわゆるインターネットがなかった頃の養成から生まれたリレーってのが今風でないんでしょうね。

マストドンのインスタンスは、リレー(と分散)の意義とメリットを提供できる(ような気がする)ってのが違うのかな。

マストドン会議3に登壇したのをきっかけに、改めてマストドンのサービス構成について考えてみた。

ひとつの問題はユーザーやインスタンスが増加するにつれ、連合タイムラインやローカルタイムラインが現実的に眺められない流量になること。

また、インスタンスは非常にわかりやすいコミュニティ単位ではあるが、人間は本質的に複数のコミュニティに参加しているものであり、複数コミュニティに参加するために複数インスタンスにアカウントに持つのが必然という今の構成はいかにもつらい。

つまり技術的な問題ではなく、サービス設計的にスケールしづらい構成になってる気がする。

これを解決するためには、コミュニティ単位のタイムラインを複数購読できればよいのではないだろうか。あるインスタンスに属するタイムラインだけを読み書きできるとか。少なくとも表示に関しては連合タイムラインをフィルタリングするだけなので、実装は簡単。投稿はまた別だけど。

しかし、それをあまり徹底すると結局、古(いにしえ)のNetNewsの復活になるだけで終わったりする危惧もある。

@ykzts@pawoo.net @hortense667 私の権利は主張しません。まあ、通訳もあったのでどう取り扱うかという技術的な問題はあるでしょうが。

#マストドン会議 会場は「ソラシティ アカデミア」3F です。
JR「御茶ノ水駅【聖橋口改札】」より徒歩1分 / 東京メトロ千代田線「新御茶ノ水駅【B2出口】」直通1分 / 東京メトロ丸の内線「御茶ノ水駅【出口1】」より徒歩4分 / JR「秋葉原駅」より徒歩9分 / 都営地下鉄新宿線「小川町駅」より徒歩6分

6/10のMastodon会議3に出席することになりそう

@ogochan さすがに一回りも下ではないと思います。5つくらいかな。

@katsusuke なるほど。console にはいくつかjs関係のエラーが見えます。でも、コネクションとは関係ないみたいだけど。

Show more
mstdn.jp

Mastodon日本鯖です. 10/22(火) 10:07頃より高いアクセス負荷が観測されており、サービスの運営に支障が出る状況のため、一部のアクセスを制限しておりましたが、制限を解除いたしました。(11/18更新)