[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 <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Social-discuss] Proposal: Federating attachments,
Stephen Paul Weber <=