allow updating a published post

[snarfed]

we already store the source URL and silo post/comment id in the Publish entity. just need to look it up on a publish attempt and translate to the silo API call for updating or deleting instead of creating.

cc @kartikprabhu

[kylewm]

Note: Facebook's API docs make it look like you can edit/update a post via the API, but when I actually tried to do it, it gave me an error with a message along the lines of "this type of post cannot be edited"

[snarfed]

:sadface: i had a similar experience with instagram's like api. sigh.

[tantek]

For reference: http://indiewebcamp.com/CRUD

And presumably such "deletes" could include "unliking" a post e.g. on FB (including POSSE copies there).

Could be used for for deleting POSSE "retweets" (unretweeting?) as well, by the author deleting the original, sending a webmention to Bridgy publish, then responding to Bridgy's request to the original permalink with a 410.

[kylewm]

Hey, I learned from a question to @scripting that it is possible to edit posts on Facebook using the graph API! You simply POST to the /{post-id} edge. I'm not sure if this is a new undocumented feature or if I was doing something wrong in April when I first tried it.

See here for proof: https://www.facebook.com/kyle.mahan/posts/10101004398903469

[snarfed]

👏 🍎

[tantek]

I definitely want this (Bridgy Publish POSSE CRUD) for updating a POSSEd photo post to add person-tags to it, but that may also require implementing #459

Encountered: http://indiewebcamp.com/irc/2015-09-01/line/1441139228600

[snarfed]

starting to look at this again.

silo support:

• Facebook: yes, update and delete posts. docs. only posts that we created, though.
• Twitter: yes, delete tweets and favorites.
• Instagram: yes, delete likes.
• Flickr: yes. replacing/updating/deleting photos, updating/deleting comments, and deleting likes.

[snarfed]

there's also using u-syndication to detect and update a POSSE post that we didn't originally create. that only works for update, though, since deletes return 410, and Flickr is the only silo that supports updating things (photos, comments) that we didn't create with our own app.

(technically a delete 410 could also return an HTML body that includes the original u-syndication(s) we could use...but in practice, i doubt many implementations do that, if any.)

[snarfed]

re-deprioritizing. update would take a fair amount of refactoring all of the logic in the _create methods so it could be used for both posting and updating.

delete is more straightforward, but i suspect there's much less demand for it than for update.

(... and we barely hear any demand for update either, honestly.)

[tantek]

FWIW I just had a use-case for Bridgy Publish POSSE Update to Flickr. Enough to look up the API call needed https://www.flickr.com/services/api/replace.api.html and then come here to file an issue but found this instead.

Would it be worth splitting this into separate issues for update vs delete per Publish destination to at least track feasibility / demand per each?

Or is there so much general refactoring needed that that would have to happen first?

[snarfed]

@tantek thanks! hmm... maybe? update for FB and Flickr are both similar scope right now. i suspect they're also both squarely in "manual until it hurts" territory. i haven't yet heard a use case (or desire) for updating often or regularly. or do you have one?

[scripting]

FWIW, Facebook's API supports updating.

…

On Tue, Dec 26, 2017 at 9:33 AM, Ryan Barrett ***@***.***> wrote: @tantek <https://github.com/tantek> thanks! hmm... maybe? update for FB and Flickr are both similar scope right now. i suspect they're also both squarely in "manual until it hurts" territory. i haven't yet heard a use case (or desire) for updating often or regularly. or do you have one? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#84 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABm9O2iSkhpd949B3hFsCdxk9W7kSFeXks5tEQPKgaJpZM4BoKzU> .

[asuh]

My use case for deleting and updating: I published a post that was supposed to include a link back from silos; no link back published to silo posts. I deleted said post and silo posts and then republished as new post, same as before, this time with link back enabled. Received notice of this issue and that it's not possible to POSSE with same URL already in Bridgy.

[snarfed]

thanks for the note @asuh!

the short answer to your use case is, if you give the second post a new URL, e.g. with a different slug, bridgy publish will be able to POSSE it.

since you deleted and recreated instead of editing in place, i'm guessing this silo was twitter? for twitter specifically, i've considered letting bridgy publish re-create a tweet for a post it's already tweeted before...

...but i'm reluctant, since CMSes and other webmention sending code generally consider webmentions to be idempotent, and happily re-send them if you e.g. fix a typo in a post or make any other innocuous change. i expect bridgy publish users would be unpleasantly surprised if those suddenly started sending new tweets each time.

otherwise, bridgy would need some way for you to tell it that you deleted the silo post, so it's ok to tweet it again.

also, out of curiosity, does your CMS support returning HTTP 410 for https://indieweb.org/deleted posts? that's the straw man we've considered here, but so far it seems like very few people actually do that much in practice.

[asuh]

I had never heard of HTTP 410 status but I like it. I'm on WordPress and there is no built-in support yet. Is this something Bridgy Publish or Webmentions WP plugins could add?

if you give the second post a new URL, e.g. with a different slug, bridgy publish will be able to POSSE it.

This is the disappointment I learned. I started with a decent title/permalink/slug that I liked, realized that Twitter and Facebook both didn't have the expected link back, I removed everything, and then hoped it was possible to resubmit the original post, with same title/permalink/slug, this time to include the link back on the social media posts.

The permanence of Bridgy's connection to posts, while it makes sense, is limiting when an error is made from the original source. Even the ability to manually remove the original post from Bridgy could be useful enough for this to work, but I suspect that'll never happen.

I understand the hesitance of updating a post to update the POSSE posts. However, completely removing and reposting, this should not cause the issues I had.

[snarfed]

definitely understood. out of curiosity, have you read https://snarfed.org/2015-11-29_keep-bridgy-publish-dumb ?

[asuh]

I had not seen this post, thank you. I agree the goal should be simplicity, keeping it mostly "dumb".

I hope the ability to remove posts from Bridgy could be enabled, at the very least, without it being a new "feature" per se.

[snarfed]

i'm trying to use twitter's API to delete a tweet, and it keeps returning a 401 error:

POST https://api.twitter.com/1.1/statuses/destroy/1053010007829110784.json {}
401, response body: {"errors":[{"code":32,"message":"Could not authenticate you."}]}

i can use the exact same code paths and access token/key to create a tweet. (i used it to create the tweet id above.)

haven't yet found an answer on the twitter developer forum, stack overflow, or web. grr.

[snarfed]

(for the record, i got twitter API delete to work by including the tweet id in the POST body instead of the URL.)

[snarfed]

for those following this issue: i've tentatively shipped delete for twitter. feel free to beta test ! just follow https://indieweb.org/delete and return HTTP 410 for a post that you previously published with bridgy. let me know how it goes!

[petermolnar]

hi @snarfed
I have a bridging (sorry) idea while there is no update option: apart from returning the error and the error code in the response, would it be possible to return the original response as well?
eg instead of:

{\n \"error\": \"Sorry, you've already published that page, and Bridgy Publish doesn't yet support updating or deleting existing posts. Details: https://github.com/snarfed/bridgy/issues/84\"\n}

include the
{\n \"url\": \"https://www.flickr.com/photos/petermolnareu/48527276102/\", \n \"type\": \"post\", \n \"id\": \"48527276102\"\n}
as an additional element in the JSON.

[snarfed]

@petermolnar hmm, interesting! maybe! can you describe how this would help you? do you not store the results of bridgy publishing your posts?

[snarfed]

actually, this was easy to do, so i've gone ahead. the original response is now in the original field, eg:

{
  "error": "Sorry, you've already published that page, and Bridgy Publish doesn't yet support updating or deleting existing posts. Details: https://github.com/snarfed/bridgy/issues/84",
  "original": {
    "url": "https://www.flickr.com/photos/petermolnareu/48527276102/",
    "type": "post",
    "id": "48527276102"
  }
}

[petermolnar]

I'm using those responses to pull in POSSEd URLs. If I made a mistaken, and overwritten or missed the original, so far I had not way of tracing it down easily. With this, it's much simpler, thank you very much.