@unarist @Clworld 相互運用についての仕様がないので

@Clworld @unarist 😇

@unarist @Clworld ところでこのtag schemeって参照可能なんですかね。参照可能ならなんでも良いとActivityPubの仕様にはあります。@abcang さんが (いきなり投げる) あるGNU Socialのインスタンスがtag schemeでURLを返してくるせいでエラーが出てうるさいとか以前言っていて、そのときにも話題になったのですが、もしかすると参照可能なのかも？流石にそれはないか。

@fn_aki @Clworld @abcang なるほどになった
https://freezepeach.xyz/.well-known/webfinger?resource=tag:freezepeach.xyz,2017-08-15:noticeId=3580063:objectType=note

@unarist @Clworld @abcang あー、標準にない仕様かー…

@unarist @Clworld ところで、無理やりURLを入れるとした場合、GNU SocialではURLを解決する方法としてrel=relatedを参照する方法があります。Mastodonの場合にはないのでまずい。
https://github.com/tootsuite/mastodon/pull/4116

@Clworld @unarist 多分Mastodonであることをmastodon:scope要素などで特定して、それからtagを解析するというworkaroundをやるしかないはず。

@fn_aki @Clworld rel=alternateとの違いがよくわかっていない...

@unarist @Clworld rel=alternateだとActivityPub representationを入手できなかったはず。

@Clworld @unarist s/ActivityPub/ActivityStreams 1/

@unarist @Clworld さっきの
> rel=alternateだとActivityPub representationを入手できなかったはず。
これは正確じゃなかった。rel=alternateだとHTMLが手に入るから、更にそのHTMLにあるrel=alternateでActivityStreamsのURLを取得することになる。
rel=relatedだとActivityStreamsが直接手に入る。

@Clworld @unarist 同じようにデータベース保存されているHTMLへのURLからActivityStreamsを特定できるからそれで良いのか（というかそれが先のPRでやっていることだった）

@fn_aki @Clworld 例えばActivityPubのidしか知らない投稿をブーストしても、urlからOStatusで取得できるので、両方対応しているMastodonでは問題にならないようです。逆はidでfetch仕様としてtag:にはまるのだけど。

@unarist @Clworld ActivityPubではidがURLとして解決できると仕様にあるので、idにtag:が入ってはいけません。配信側でURLを用意し、それをidに代入しないといけません。

@fn_aki @Clworld ですよねえ。activity+jsonが取れないURLでよければOStatusのurlでいいだろうけど、ねえという。

@unarist @Clworld OStatusなら良いんじゃないでしょうか。標準では解決できれば何でも良いとあるのですが、他のOStatus実装と互換性を保つにはOStatusのURLをidとして持ち、それを参照して元のOStatus representationが取ってこれたほうが良いでしょう。

@fn_aki @Clworld 確かにHTMLにatomへのlinkがないインスタンスは普通にありますね。 https://gnusocial.de/notice/10972888 → https://gnusocial.de/api/statuses/show/10972888.atom

@unarist @Clworld https://shitposter.club/notice/4163783 にあるので大丈夫だと思います。