[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Social-discuss] Proposal: Federating attachments

From: Stephen Paul Weber
Subject: [Social-discuss] Proposal: Federating attachments
Date: Mon, 2 Nov 2015 13:42:48 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

After a bunch of testing and code reading, I have discovered that by default GNU Social does not federate attachments. They get added to Atom packets as rel="enclosure" links and these links are parsed out by receivers, but they do not get added as attachments unless $config['attachment']['process_links'] = true; This config additionally controls if URLs in a notice should be scanned for attachment and if URLs in a notice should be expanded before being linkified.

Furthermore, they are unlikely to be displayed as attachments unless addPlugin('StoreRemoteMedia');

I would like to propose changing the way these things work (I am willing to do the code, but would like some feedback before I dig in and write something no one wants).

1) I would like to have URLs in notices *always* expanded when linkified. If this is really too much of a burden on some servers I would then propose a new config be made seperately to control this, since it has nothing to do with attachments. 2) I would like to have explicit enclosures picked up from feeds always processed as attachments. They are not "maybe attachments", the source has intentionally marked them as such and they should be processed as such. 3) In all cases I would like the stored "final url" for a File object to be the last target of a 301 redirect. 302, 303, and 307 can be followed to get the headers, but the URL recorded should be up the chain from them (since they are temporary redirects and subject to future change). 4) This leaves $config['attachment']['process_links'] = true; controlling only if URLs in locally-posted notices should be scanned for possible attachments. This seems like its intended purpose and the default-off seems appropriate. 5) When scanning notice body URLs for attachments, we should define some media types (I propose at least: image/*, audio/*, video/*) to be treated as attachments, and use a new Event to allow plugins to determine that any given URL they might be able to help handle should be treated as an attachment. All other URLs should *not* be treated as attachments and no File object should be saved for them. Links to random webpages are *not* attachments and the data model should not treat them as such. 6) Thumbnails should be generated for attachments we find when doing the process_links step and for rel="enclosure" attachments where possible. 7) All attachments should be shown. If they do not have a title, show using their URL. Currently plugins have to hack useless titles in to the data model to force attachments to show. This is because most attachments are *not* attachments but are just links from the notice to some webpage. But the above parts should fix this, and thus allow us to show all marked attachments as such. 8) The TwitterBridge should import photo tweets as photo attachments, if it does not already. Thumbnails should be generated for the photo tweets. This should not depend on any config.

Stephen Paul Weber, @singpolyma
See <> for how I prefer to be contacted
edition right joseph

reply via email to

[Prev in Thread] Current Thread [Next in Thread]