Ryan Barrett

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...

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...

@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...

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...

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

i'm trying to use [twitter's API to delete a tweet](https://developer.twitter.com/en/docs/tweets/post-and-engage/api-reference/post-statuses-destroy-id), 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...

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

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...

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

actually, this was easy to do, so i've gone ahead. the original response is now in the `original` field, eg: ```json { "error": "Sorry, you've already published that page, and...