Bot fails to forward loads of working attachments

[JuniorJPDJ]

I'm getting messages like this:

#1357031 This content is no longer available: The content you requested cannot be displayed right now. It may be temporarily unavailable, the link you clicked on may have expired, or you may not have permission to view this page.

on pretty big amount of media which works in messenger.

Part of them are forwarded from other people on messenger and part are probably shares from private groups. It seems like it's problem with bot trying to load non-public image/media without using authorized user credentials (session)?

[spantaleev]

Probably the same as #94 which already got fixed?

[JuniorJPDJ]

That's other issue. Message I sent is message from chat, not from logs. Still - I'm not sure if it started working or not.

[Dzordzu]

The issue is still present. Same message from time to time

[Dzordzu]

When it comes to logs: no errors are reported on the side of mautrix facebook (log level: DEBUG)

[Dzordzu]

Ok. I think I've managed to fix SOME problems with attachments. It appears to be my misconfigured synapse server.

1. Check file limits in the server config.
2. Check file limits on the side of the reverse proxy (body file size limit)

It should solve some problems. Some attachments are still dropped (but less frequently)

[wvffle]

Seems like it happens to me with some stickers as well as with some photos.

[JuniorJPDJ]

Ya, now it's better, most of photos are getting forwarded, but sometimes it still happens.

[spantaleev]

By bridge stopped working for other reasons a few days ago (to be reported as a new issue).

About this, in the past few weeks/months it was the opposite experience for me -- most photos/videos would not get forwarded, only some would (but so rarely, that it didn't matter much).

[kujeger]

I have this as well, pretty frequently. I haven't been able to see any pattern to it; file sizes do not appear to matter (e.g. 100KB may not load, while 1MB works fine)

[spantaleev]

I think it should be possible to work around this with some effort.

It seems like the bridge tries to retrieve the attachment image using fbchat's fetch_image_url: https://github.com/tulir/mautrix-facebook/blob/594ed830dab2cd67adb0e3aafc0135d6c261fbc8/mautrix_facebook/portal.py#L843-L847

.. which does this: https://github.com/tulir/fbchat-asyncio/blob/476b7b0f1c9dc26ab2e515887febf6afcc6b4e91/fbchat/_client.py#L486-L490

.. which fails for some reason (bad cookies, etc.)

---

However, the original MQTT payload is something like this:

{'deltas': [{'attachments': [{'fbid': 'zzzz', 'filename': 'zzzz.gif', 'genericMetadata': {'fbtype': '5248'}, 'hash': 'zzzz', 'id': 'zzzz', 'imageMetadata': {'height': 343, 'width': 498}, 'mercury': {'blob_attachment': {'__typename': 'MessageAnimatedImage', 'attribution_app': {'id': 'XXXX', 'name': 'Tenor GIF Keyboard', 'square_logo': {'uri': '..'}}, 'attribution_metadata': None, 'filename': '....', 'animated_image': {'uri': '....', 'height': 343, 'width': 498}, 'legacy_attachment_id': 'zzzz', 'preview_image': {'uri': '.....', 'height': 343, 'width': 498}, 'original_dimensions': {'x': 498, 'y': 343}}}, 'mimeType': 'image/gif', 'titanType': 8, 'useRefCounting': True}], 'data': {}, 'irisSeqId': 'X', 'irisTags': ['strict_user_privacy_enforcement', 'iris_post_process'], 'messageMetadata': {'actorFbId': 'X', 'cid': {'canonicalParticipantFbids': ['A', 'B']}, 'folderId': {'systemFolderId': 'INBOX'}, 'messageId': 'mid.$mmmm', 'offlineThreadingId': 'X', 'tags': ['source:chat:light_speed', 'app_id:X'], 'threadKey': {'otherUserFbId': 'A'}, 'threadReadStateEffect': 'MARK_UNREAD', 'timestamp': '1609254676063', 'unsendType': 'deny_for_non_sender', 'skipBumpThread': False}, 'requestContext': {'apiArgs': {}}, 'class': 'NewMessage'}], 'firstDeltaSeqId': 123, 'lastIssuedSeqId': 123, 'queueEntityId': 123}

(this is for some sticker).

Reaching into something.something.animated_image.uri gives you a URL which is publicly reachable (no need for authentication), which directly serves the attachment data we need.

---

The above example was for a sticker, but it's similar for images as well (the property path is different though).

For image attachments, the whole message payload is like this:

{'deltas': [{'irisSeqId': 'xx', 'irisTags': ['strict_user_privacy_enforcement', 'iris_post_process'], 'newMessage': {'attachments': [{'fbid': 'XXXXXX', 'fileSize': '118772', 'filename': '.....', 'genericMetadata': {'fbtype': '1586'}, 'hash': 'XXXXXX', 'haystackHandle': 'XXX-XXX::', 'id': 'XXXXXX', 'imageMetadata': {'height': 960, 'width': 720}, 'mercury': {'blob_attachment': {'__typename': 'MessageImage', 'attribution_app': None, 'attribution_metadata': None, 'filename': 'image-XXXXXX', 'preview': {'uri': '.....', 'height': 373, 'width': 280}, 'large_preview': {'uri': '.....', 'height': 640, 'width': 480}, 'thumbnail': {'uri': '....'}, 'photo_encodings': [], 'legacy_attachment_id': 'XXXXXX', 'original_dimensions': {'x': 1536, 'y': 2048}, 'original_extension': 'jpg', 'render_as_sticker': False, 'blurred_image_uri': None}}, 'mimeType': 'image/jpeg', 'titanType': 4, 'useRefCounting': True}], 'data': {}, 'irisTags': [], 'messageMetadata': {'actorFbId': 'AAAAAAA', 'messageId': 'mid.$mmmmm', 'offlineThreadingId': 'AAAAAA', 'tags': ['source:chat:jabber', 'app_id:AAAAAAAA'], 'threadKey': {'otherUserFbId': 'AAAAAAA'}, 'timestamp': '1609259744022', 'unsendType': 'deny_for_non_sender'}, 'requestContext': {'apiArgs': {}}}, 'replacedMessageId': 'mid.$mmmm', 'requestContext': {'apiArgs': {}}, 'class': 'ReplaceMessage'}], 'firstDeltaSeqId': 123, 'lastIssuedSeqId': 123, 'queueEntityId': 123}

something.something.large_preview.uri seems to provide some relatively large image via a publicly accessible URL. It's a "large preview", smaller than the original (480x640 in this case, compared to 720x960 for the largest original that one can download), but it's still something.

---

One of the problems with implementing this is probably that the Attachment model (coming from fbchat-asyncio) does not contain these raw properties? Otherwise, it'd be nice if the bridge could try and reach into some property like this and use it as a fallback (in case downloading the original attachment fails.. which it often does).

It probably also makes sense to look into why downloading attachments fails sometimes and not others, and whether that can be fixed, instead of doing such hacky workarounds.

[Moto-John]

Can confirm. I also have the same exact problem. Most pictures don't get through with the same error

[tulir]

This might still exist with the new version, but the error is most likely different now. Open new issues if it still happens.