Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect originating item <source> on re-sharing #22

Open
fluffy-critter opened this issue Sep 9, 2019 · 0 comments
Open

Respect originating item <source> on re-sharing #22

fluffy-critter opened this issue Sep 9, 2019 · 0 comments

Comments

@fluffy-critter
Copy link
Owner

Currently, items do not track any <source> metadata that's associated with them in an originating Atom feed; fof_db_get_items just does a join on the feed itself to determine $feed_uri et al. and sharing.php just passes that on through.

This means that if an item is shared through an Atom feed, and then a FoF user re-shares that shared item, it looks like it comes from the feed the user got it from rather than from the original feed source.

More importantly, this also means that in a "private" feed (using e.g. an "unguessable" URL), sharing the item reveals the unguessable URL; a private feed should be able to avoid that by setting a <source> on all items that point to the public version of the feed, but that is currently not possible.

It would also be helpful to have an extension to Atom so that the feed itself declares the public version of the feed (like rel="self" except without the implication that the reader should chase that to update its own subscription, so e.g. using rel="canonical" or rel="public" or something) and if that can ever get settled on, that should be used as the <source> on shared items.

Fixing this within FoF itself, in any case, would require adding the feed metadata to the individual items when they're ingested.

This might also help with some UX down the road where if someone sees a reshared item they'd see something like "such-and-such reposted from so-and-so" or whatever. (Which would also be important for mitigating the obvious spoofing attack.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant