tesaguri 🦀🦝 @tesaguri@fedibird.com

なお、完全に削除できないというのは、なんらかの理由で削除リクエストが他サーバーに送られなかった場合に起きる現象で、そうそう頻繁に起こることではない。

Xからの移住先の比較と移住のためにやるべきこと https://anond.hatelabo.jp/20241018060206

Preface: This is a long, technical post so I apologise in advance. Please avert your eyes if such things offend you.

Hi everybeings!

Overview

@Ada and I have discussed many areas where we see problems in the way the Fediverse currently works and where would like to see improvements made to improve safety of the fediverse.

Safety on the fediverse is one of the topics we hold most dear.

One of these areas (and one that has recently garnered a lot of attention) has been in the area of full-text search, and despite the option for account-wide no-crawl options in many pieces of fediverse softwares, this option is not-federated, non-specific, non-granular and not-for-purpose with regards to fediverse searching. It's specifically designed and worded for crawler bots at a html scraping level, and while we could repurpose it for fedi-searching, it just doesn't feel right or quite fit.

There's been a lot of talk on a lot of different levels out there, but nobody's come to a concensus. A lot of people are talking about how we should do it and what standards we should use, and generally making the whole concept a lot more complicated than it needs to be.

In this post, I want to share with you some of the ideas that I've gathered through my research, and implemented in a way that is simple enough (KISS), not overly complicated (YAGNI) yet still fit for the purpose I need as both a software engineer and an instance admin, and that anyone accessing the content will need.

The idea in sharing this is not to convince me that it shouldn't be done, or to create the absolutely most perfect solution possible that's going to take 20 years to build and will be outdated by the time we get there.

This will be getting built and going out in weeks, not months, not next year. It's needed now. This is my current plan how to implement something we needed months ago, now. This is your chance to change my mind and help refine this plan before I start really coding it up.

Technical/implementation details

A lot of these options will be settable as a default value in your settings as well as at an individual post / file level during composition or afterwards at editing stage.

In terms of inbound federated AP objects which do not support these new fields, we will try to infer the intent based off existing AP fields and other metadata when present.

Specifically, we will be using the Mastodon Account Lookup API (GET /api/v1/accounts/lookup?acct=) to get and store the noindex flag during actor creation/refresh. This will also allow us to put the noindex meta tag on any HTML pages containing that actor's posts.

Searchability

So you don't want people to be able to search for you. But is that everybody? Maybe you want your followers to be able to find your posts? Maybe the people you mention should be able to find your post? What about actual users on your local instance? Maybe a particular post you never want to appear in searches? Maybe a particular post you write contains stuff you want everyone to see?

We will be adding a global default and per-post override federated in AP as hk:searchableBy which will be settable to public, private or a combination of followers, mentions or local. This is different to the currentvisibility in that you can have a public visibility post that is searchable by followers and mentions for example.

{
    ...
    "searchableBy": ["followers", "mentions"]
}

{
    ...
    "canReply": ["mentions"],
    "canInteract": ["public"]
}

{
    ...
    "license": "https://creativecommons.org/licenses/by-sa-nc/4.0/",
    "attribution": [
        "https://github.com/supakaity/icons"
    ]
}

{
    ...
    "crawlable": false
}

{
    ...
    "canQuote": ["followers"]
}

@hongminhee@fedibird.com 当該PRがCloseされたのでMisskeyにはまだ取り込まれてないです

これ取り込むか
https://github.com/misskey-dev/misskey/pull/14109/files

#fedibird #fedibird_info FedibirdもPleroma / Akkomaも、便乗リアクションができます。

既に投稿についているリアクションであれば、自分のサーバに登録されていない絵文字を使ったリアクションが可能になる機能です。

この際、他のサーバの絵文字情報を添えてリアクションのActivityを送信します。

受け取る側は、既に知っている絵文字であればそのまま受理しますが、知らない絵文字は、いったんリモート絵文字として登録した上でリアクションとして受理する流れになります。

このとき、他サーバの絵文字の情報が虚偽であるとマズイので、リモート絵文字を登録する前に、本来の絵文字の帰属サーバに問い合わせて存在確認をします。

ところがPleroma / Akkomaは絵文字の情報（Object）を取得できるurl（ID）に絵文字の画像URLを返してくるので、Objectを取得して照合することができません。

このため、未登録の第三者の絵文字を登録する処理を安全に行うことができず、この絵文字リアクションは失敗することになります。

あまり頻度の高い状況ではないのですが、制限ではあるので、一応気に留めておいて下さい。

#fedibird #fedibird_info 絵文字リアクションの連合まわりについて、実装上の不備や仕様の変更を行いました。

・Pleroma / Akkomaに対し、絵文字リアクションを送ってもお気に入りとして届く問題を修正

・Holloからの絵文字リアクションを受け取れない問題を修正

・リアクションに添付する絵文字の情報をID（URI）のみで表現しても受理できるよう変更

・絵文字リアクションに対応したサーバへは、EmojiReact Activityを送信するよう変更

・お気に入りのみ対応のMastodonなど、絵文字リアクションに未対応のサーバへは、Like Activityで送信する（従来通りの仕様）

また現在、Pleroma系の仕様により、既についているPleroma系他サーバの絵文字を使ったリアクションに便乗した際、相手サーバがまだその絵文字を一度も受け取っていない場合は失敗します。

うん、何を言ってるかわかりにくいね！ リプライで詳細を説明します。