how to handle backfeed on threads?

[snarfed]

i often POSSE medium-length posts to Twitter as threads with multiple tweets. I'd like Bridgy to treat the thread as the POSSE copy, not individual tweets inside it. eg likes and retweets on any tweet in the thread would get backfed to my post.

i do this now by including multiple u-syndication links in my post, one to each tweet in the thread, but that's obviously not ideal. should Bridgy just treat threads as whole entities instead, and backfeed responses on all of their tweets?

i expect some people would like this, but others wouldn't. sigh.

[swentel]

I kind of have a related situation: in my case it's a single tweet, which triggers a conversation. I then start replying back from my site and so on. The problem (I don't necessarily see this as a bug from brigy BTW), is this:

Take for instance this reply: https://twitter.com/barbarosso/status/1268935304372764672 It comes back fine on my site (see https://realize.be/comment/4996#comment-4996), but it triggered two webmentions (also on my first reply), and with the functionality in my CMS, it then generates two comments attached at the right comment (being the target of the webmention).

Ideally, it would only trigger a webmention to my last reply. That's less work for me to figure out which comment to publish in the end ;)

Just wanted to document this case. I've been thinking (and tracking at https://github.com/swentel/indieweb/issues/493) to figure out if I can solve this on the Drupal side, which I probably can (but not going deeper into the details).

[swentel]

I was looking at this today, and I can't reliably fix this in my system as far as I can see for a couple of reasons, but the main reason is that it's entirely possible my back end process is already parsing a saved webmention, while the second webmention one is still being saved to the database.

It's been a while since I've looked at the twitter api (and responses), but would there be a way to figure out that only a webmention should be send to the direct parent when it's a reply, and not the main thread for instance?

I have two examples: The twitter message is the same for both, but the first in-reply-to is different.

• https://brid-gy.appspot.com/comment/twitter/swentel/1315542751723823105/1315700638618066944
• https://brid-gy.appspot.com/comment/twitter/swentel/1315700041114431489/1315700638618066944

(thread is at https://realize.be/blog/activitypub-drupal as well - but only one comment is published)

Or is this more of a problem of the way I'm exposing my microformats data on /timeline - /timeline/all on my site?

[snarfed]

thanks for following up! yeah this has come up at least once before, eg #813.

my general philosophy here has been to try to make bridgy promiscuous, ie it generates and sends wms for as many responses, and to as many possible destinations, as is reasonably possible. this is because there's a wide range of logic and sophistication in wm receivers, and i'd rather a response show up on eg two related source posts rather than neither.

in this example, both of the bridgy sources you gave have the same u-uid and u-url, so you could de-dupe them in your wm receiving logic if you want. you could include some prioritization logic for the best place that a given wm should show up, and attach it to the highest priority post that it's been sent to, which could mean moving it after it's initially attached in cases like this...?

[swentel]

in this example, both of the bridgy sources you gave have the same u-uid and u-url

Interesting, I've never thought about using those for checking duplicates. (I currently do that based on source, target and post type which works fine). I store those values too locally, so I could indeed use it as another 'duplicate' check.

I do wonder though: is there a specific order that brid.gy sends the webmentions out? Because in that case, it would become extremely easy if the direct parent of the reply would be the first webmention send. All other ones (I've had cases going 4 levels deep) would then be marked as duplicate. That would guarantee 100% that the process that's parsing the webmentions (it's a separate process than storing the webmention) doesn't miss one.

However, even if the order can't be guaranteed, there's still a way to catch the direct parent I think, I just need to add more logic :) (and there's still a slight chance of a missing one, but that case will be extremely unlikely)

[snarfed]

yes! u-uid and u-url are at the top of the list on https://indieweb.org/deduplication too.

sadly bridgy doesn't guarantee an ordering, and it would be hard (if not impossible) to, given transient network failures, retries, etc. definitely try de-duping and prefer the direct parent, i'm curious to hear how it goes!

[swentel]

I actually have a clue now that I looked at the source again: there are two in-reply-to urls. The first one is a url on my site, the second one is the same in both and point directly to a level on my site which has a syndication url attached to as well, so I actually know where I need to hang this reply in the thread. Woot, it will work!

Thanks for the feedback and thinking along :)

[swentel]

Just tested this tactic and it works!

[snarfed]

I looked at this a bit more just now. Replies should already basically work, but likes and retweets are definitely tricky. I'd need to walk the reply chain during poll and propagate them for the topmost tweet from the author as well as for their own tweet. That's doable, but I'd also need to record that new "original tweet" somewhere, and then look it up during the mf2 webmention source requests and perform original post discovery on it, and I don't currently have an obvious place to store that record. I guess I could put it in a SyndicatedPost in the datastore, but that's an awkward overloading. Sigh.

[gijswijs]

i often POSSE medium-length posts to Twitter as threads with multiple tweets.

@snarfed Slightly off-topic here, but how do you POSSE medium-length posts to Twitter as threads? I was looking in the bridgy docs for this, but couldn't find anything on it.

[snarfed]

Heh, I do it manual until it hurts. I don't tweet a lot, so it doesn't hurt me much personally, and Bridgy is unlikely to implement much more complex POSSE functionality.

[gijswijs]

Fair enough 😸. But how do you do it manually. I assume you still use POSSE? So do you just send out a tweet through bridgy with a bunch of replies to your own tweet, and does that turn into a Twitter thread? Or do you do it really manually, where you post the tweets using the native twitter client, and then link them up to the original posts on your website using u-syndication links?

[snarfed]

The latter! Really manually, on twitter.com or the app.

[ramiro-ruiz]

I was wondering if something like this was possible with Bridgy and it is great to read that it works with multiple u-syndication links. That's pretty much what I need now, I already have some iOS Shortcuts that will help me in speeding the process.

Thank you!

[gijswijs]

Yeah, I feel the same. It actually makes a lot of sense to have a proper (blog)post on your website, with multiple u-syndication links that link to the tweets in the custom crafted Twitter thread.

[gijswijs]

So I've took this approach and syndicated a blog post as a bunch of tweets: But why aren't the webmention targets found? Only the first tweet in the thread is assigned to the correct webmention target, but the others are not.

Also the first tweet gets an error back from Aaron's webmention.io: rate_limit_exceeded","error_description":"Only one request per source and target combination is allowed every 30 seconds (https://brid.gy/log?start_time=1649128976&key=agdicmlkLWd5cjYLEghSZXNwb25zZSIodGFnOnR3aXR0ZXIuY29tLDIwMTM6MTUxMDkxODc4OTQwMzM5ODE0NAw) Maybe that's related? It's probably something I should take up with Aaron.

If you could share your thoughts @snarfed that would be great, but this is by no means critical. Nobody reads my threads on cryptography anyway.

[snarfed]

Thanks for the details! And apologies for the confusion.

The high level problem here is that Bridgy doesn't really understand threads well yet, or how to backfeed to them, and I'm still not sure yet how it should. I'm open to ideas!

Having said that, Bridgy doesn't currently try to backfeed your replies to yourself. It only backfeeds other people's replies and your replies to them.

Thanks for raising the rate limiting, that's probably a bug in Bridgy's "discover" feature that I can fix.

Lastly, the one webmention you see here is odd, and unexpected. I think it was triggered by the same discover bug, but there's probably another bad bit of logic somewhere that I need to find.

Again though, these are mostly all symptoms of Bridgy not understanding threads well yet. Sigh. 😐

[snarfed]

Maybe obsolete, Bridgy Twitter is dead, https://github.com/snarfed/bridgy/issues/1410#issuecomment-1497763725 ...but maybe not obsolete if we also have this issue on Mastodon? Not sure?