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

syndicate posts despite "Could not find a tweet to reply to." #362

Closed
dissolve opened this issue Feb 9, 2015 · 13 comments
Closed

syndicate posts despite "Could not find a tweet to reply to." #362

dissolve opened this issue Feb 9, 2015 · 13 comments

Comments

@dissolve
Copy link

dissolve commented Feb 9, 2015

I often reply to websites but would like to post the reply to twitter, even though it is out of context.
Readers to follow the link to find out what i am talking about.

If I reply to a web-url and specifically tag it to syndicate to twitter, I would like it to still syndicate to twitter.

@snarfed
Copy link
Owner

snarfed commented Feb 9, 2015

interesting idea! definitely sounds reasonable to support.

the catch is, people also often try to use bridgy publish to POSSE a reply to a tweet but get the in-reply-to link wrong, or accidentally use brid.gy/publish/twitter when they meant to use brid.gy/publish/facebook, etc. this check helps them. i'm not sure yet how to reconcile the two use cases.

@dissolve
Copy link
Author

I think its better to assume the user is doing things correctly than to assume incorrect.

There are probably some situations that can be filtered. If a in-reply-to is a twitter URL or Facebook URL, then perform by current methods, otherwise ignore the in-reply-to and post as a standard note.

@snarfed
Copy link
Owner

snarfed commented Feb 10, 2015

i wish that was true! sadly, there are dozens of bridgy publish attempts every day that are wrong in various ways, and mismatched in-reply-to and bridgy link is one of the most common. (i can tell because invariably the person fixes it and makes another attempt with the right in-reply-to or bridgy link minutes later.)

@snarfed
Copy link
Owner

snarfed commented Feb 10, 2015

one possible workaround is to publish your post without the in-reply-to link, trigger bridgy publish (via either webmention or the form on your user page), then add the in-reply-to link after. annoying, but it'd work.

@dissolve
Copy link
Author

thats what i have done in the past, the most annoying is when it is on an article which i edit via html rather than just text (on notes etc) and I don't have edit functionality for it yet, so "Editing" an article post is actually just changed the DB directly

@tantek
Copy link
Contributor

tantek commented Nov 15, 2015

My analysis of this use-case (POSSEing a reply to something that is not a tweet nor has a POSSE tweet copy) is here, and is roughly what I've implemented in Falcon's code to POSSE reply posts to Twitter: https://indiewebcamp.com/Twitter#original_lacks_POSSE_tweet

@snarfed
Copy link
Owner

snarfed commented Nov 19, 2015

@singpolyma also votes for this for reposts in #555.

@singpolyma
Copy link
Contributor

For the accident use case. Could add force_any_context=1 optional param (similar to include_link) to enable this

@kylewm
Copy link
Contributor

kylewm commented Nov 20, 2015

I'm -1 on this proposal, per #527 (comment)

It adds a lot of decision making (based on personal preferences) that Bridgy just isn't at the right layer to make.

@snarfed
Copy link
Owner

snarfed commented Nov 20, 2015

agreed, sorry. #527, definitely. i already regret the two user facing options bridgy publish does have, whether to include a link and (especially) whether to ignore formatting.

@kylewm
Copy link
Contributor

kylewm commented Nov 20, 2015

to be clear, I'm -1 on this whole issue, not Stephen's force_any_context proposal specifically ;)

@snarfed
Copy link
Owner

snarfed commented Jan 15, 2019

related: https://snarfed.org/2015-11-29_keep-bridgy-publish-dumb

i'm doing a sweep and closing issues that i don't plan to do myself or accept a PR for, including this one. apologies for the bad news, or if this is a surprise. feel free to reopen if you feel strongly.

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

No branches or pull requests

5 participants