Proposal: Federating attachments
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
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