[Social-discuss] Proposal: Federating attachments

[Stephen Paul Weber]

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 <http://singpolyma.net> for how I prefer to be contacted
edition right joseph