Misskey: Image not displayed

[emaxmax]

💡 Summary

The image contained in a post is not displayed in Misskey stream

🙂 Expected Behavior

Here is the original post: https://dacha.xmpp.moe/channel/caranistar?mid=b64.aHR0cHM6Ly9kYWNoYS54bXBwLm1vZS9pdGVtLzg1NzM3MThhLTQwOTAtNDNhNC1iYzJiLTRiOGIwMDM3MjVhNg

Here is the post displayed on Misskey: https://misskey.m544.net/notes/716db47547c03666d30253f7

We should see the image

☹️ Actual Behavior

We don't see the image

📝 Steps to Reproduce

1. Create a post with an image embed (like https://dacha.xmpp.moe/channel/caranistar?mid=b64.aHR0cHM6Ly9kYWNoYS54bXBwLm1vZS9pdGVtLzg1NzM3MThhLTQwOTAtNDNhNC1iYzJiLTRiOGIwMDM3MjVhNg )
2. Receive the post on Misskey
3. Look for the image

📌 Environment

Reproducible on misskey.m544.net

[mei23]

The original AP URL is https://dacha.xmpp.moe/item/8573718a-4090-43a4-bc2b-4b8b003725a6

For Image not displayed
It seems that it is not a problem of Misskey because the thing related to image is not included in the pulled AP Article object

なお、Misskeyから該当投稿をPullした場合は、toやccが含まれてないので常にPrivate投稿扱いされる (v10/v11共に)
なぜ、https://misskey.m544.net/notes/716db47547c03666d30253f7 がPrivate以外になっているかはわからないが
おそらくPushされてきてそのPushには別のtoやccが含まれていたか？

[emaxmax]

FYI, it is correctly displayed in Pleroma.

[u1-liquid]

FYI, It is not displaed in Mastodon.

[mei23]

おそらくHubzillaの実装が安定してなくて
少なくともGET等でPullできるObjectについては
toもccもないのでプライベート扱いで
画像に関する情報が付いてないので誰も画像を表示することはできません

{
  '@context': [
    'https://www.w3.org/ns/activitystreams',
    'https://w3id.org/security/v1',
    'https://dacha.xmpp.moe/apschema/v1.8'
  ],
  type: 'Article',
  id: 'https://dacha.xmpp.moe/item/8573718a-4090-43a4-bc2b-4b8b003725a6',
  title: 'This War is Mine',
  published: '2019-10-10T06:57:28Z',
  url: {
    type: 'text/html',
    rel: 'alternate',
    href: 'https://dacha.xmpp.moe/channel/caranistar/?f=&mid=b64.aHR0cHM6Ly9kYWNoYS54bXBwLm1vZS9pdGVtLzg1NzM3MThhLTQwOTAtNDNhNC1iYzJiLTRiOGIwMDM3MjVhNg'
  },
  attributedTo: 'https://dacha.xmpp.moe/channel/caranistar',
  'diaspora:guid': '8573718a-4090-43a4-bc2b-4b8b003725a6',
  content: '<a ' +
    'href="https://www.trictrac.net/jeu-de-societe/this-war-of-mine-le-jeu-de-plateau" ' +
    ' target="_blank"  rel="nofollow noopener" >This War is Mine</a>, le ' +
    'jeu de plateau.<br /><br />Beaucoup trop de hasard dans ce jeu dont ' +
    "les mécaniques sont celles d'un jeu de gestion.<br />Voici par exemple " +
    "la situation finale d'une victoire facile lors d'une partie avec pas " +
    'mal de chance : <br /><img style="max-width: 100%;" ' +
    'src="https://framapic.org/3HyhCgjX9yCb/39pQ8dzAk6bf.JPG" ' +
    'alt="Image/photo" /><br /><br />Alors peut-être que cet aléa fait ' +
    'partie du propos (dans une guerre, on peut tout perdre sur un <em>pas ' +
    'de chance</em>), mais dans ce cas pourquoi complexifier les règles de ' +
    'gestion si au final toute la planification inhérente à ce type de jeux ' +
    'est balayée par une mauvaise pioche ou un mauvais jet de dé ?<br /><br ' +
    '/>#<a class="zrl" href="https://dacha.xmpp.moe/search?tag=jds"  ' +
    'target="_blank"  rel="nofollow noopener" >jds</a> #<a class="zrl" ' +
    'href="https://dacha.xmpp.moe/search?tag=jdp"  target="_blank"  ' +
    'rel="nofollow noopener" >jdp</a>',
  actor: 'https://dacha.xmpp.moe/channel/caranistar',
  tag: [
    {
      type: 'Hashtag',
      href: 'https://dacha.xmpp.moe/search?tag=jds',
      name: '#jds'
    },
    {
      type: 'Hashtag',
      href: 'https://dacha.xmpp.moe/search?tag=jdp',
      name: '#jdp'
    }
  ],
  signature: {
    '@context': [
      'https://www.w3.org/ns/activitystreams',
      'https://w3id.org/security/v1'
    ],
    type: 'RsaSignature2017',
    nonce: '4f0cac22a64968ab9c1dc646868a36602f752545942500ce0b469879973c332a',
    creator: 'https://dacha.xmpp.moe/channel/caranistar',
    created: '2019-10-21T04:09:19Z',
    signatureValue: 'ao8cBQRhlljNIL4ePdAz/A0hu8wGV6nndeP8SCF1ahuLNVEJwClZnjyLMgs8JMDaIwxdhElxXQbiCqPgDsgpCwx0N6xaMXmn+/XLcE2jJqvlcNj2hB7NyzkJXi6Z4p5228RApAwKNbYzVXnabm8PBubH8DflqvDTpQt13ovHzqUPvWRVqUSgN0BT7MimWGYR0u1avHwL2W6+my5lEZxKHEIqZKHOj/7dlErDcswTiY+OzfY1o6wJZJFDtzI7Vc3ZZddeIDdGRi2lTQJ37ll2TgiAOMEM2C/LVnFp4HeFlzZn95L0pT9ZYoGbnGaYjncRguE34Vfpcj+GlJcLbI1Lg5r5aflx0TY59hpB4ERCvzVJ7/c5cF3guEN/WegSgSF9GDYKTjhmK4sixqqVfxiDNhIgZD9LdKOk7jAV0gr965wt1A24HnU6Sg7VGbq2xW0SDiykkW8C/BHL3t2XgQnAROeNpvkd+XFD+q02WjIbOZ+nqqOG6mzfqzdmaay7IIEwkmRpfKnn4JD0kt2w/8j5O3JwDBprcVsWlKwepz0n7IK/qOOaM+YU4RquJbFYZHRXTKTWYFSWEz5/NI6JQKrlfgM67M+ub4L7ZHv2iBYHsJXBmiI/y6an513OLnJ/gEYRMTjGlWGCU7nKNlxp8arUmlghQh+LbAYZIrmaNJBrw6o='
  }
}

これはMisskeyではなくてHubzillaの問題なのでこちらで解決することは出来ません

[rinsuki]

Pleromaは投稿内のimgタグを抜かないがMastodon/Misskeyは抜く？
対処すべきかは謎

[mei23]

imgタグをそのまま解釈してるとすると
3rd party のimgっぽいのでこれをそのまま送ったり表示したりするのはちょっと嫌な感じがします

[rinsuki]

まあ表示するのであれば今のリモートから来た画像みたいに一旦仲介してやればよさそう

[mei23]

APから来たcontent (HTML) はテキスト化してDBに格納するのでimgのまま扱うことは出来なくて
無理やり対応しようとするとimgをattchment扱いで処理しちゃうとかだけど
あまり汎用的に対応できないし 送り側でちゃんとattchmentにするのが一番だと思うので
あまりよくないかなと

[emaxmax]

For Image not displayed
It seems that it is not a problem of Misskey because the thing related to image is not included in the pulled AP Article object

Looking at the code, the image is included:
<img style="max-width: 100%;" src="https://framapic.org/3HyhCgjX9yCb/39pQ8dzAk6bf.JPG" alt="Image/photo" />
It's not an ActivityPub implementation problem, it's maybe Misskey which strips images. If this is the case, you shouldn't strip silently. You should replace it with a link. For instance that is what Mastodon does with embedded audio.