Add support for non-silo replies through tag markup?

[fancypantalons]

I absolutely appreciate how important it is to keep the Bridgy Publish model as dumb as possible while putting the onus on the publisher to get the formatting right and so forth.

I've run into the "u-reply-to" problem when replying to someone else's blog while syndicating to Twitter, but I see all the issues related to that have been closed for very good reasons.

That said, today, Bridgy supports "p-bridgy-<bridge>-content" as a way to affirmatively point Bridgy to a specific part of the page to use for a particular bridge.

However, this requires creating fully formatted content block for each syndication target.

I wonder if something like "p-bridgy-<bridge>-omit" or "p-bridgy-<bridge>-ignore" could be considered.

For the "u-reply-to" problem, the publisher could include "p-bridgy-twitter-omit" for all "u-reply-to" links that aren't links to tweets. The publisher, in this case, would be responsible for getting the formatting right, Bridgy just follows the instruction to ignore the tags entirely.

I could see this being useful in a wide range of circumstances where the publisher wants to selectively omit parts of a page during syndication without replicating the rest of the content.

Is something like that an option?

I'm more than happy to throw together a PR if that's something that might be considered for inclusion.

Thanks!

[snarfed]

Interesting! Thanks for the kind words, and for following the previous discussions and examples on this (#362, #896, https://indieweb.org/Twitter#original_lacks_POSSE_tweet).

Out of curiosity, have you ever done this, ie syndicate a non-tweet-reply to Twitter, manually? How did it look? Do you think it worked ok and read ok? Got any examples handy? I wonder about the usability. The IndieWeb wiki has some thoughts, but I don't know that anyone there still does it regularly.

[snarfed]

Specifically, it sounds like you'd expect Bridgy to syndicate just the post's text into a tweet, and ignore the original post URL entirely? Or you'd just always render your own p-bridgy-twitter-content? Which is fine, but we'd still need to come up with a reasonable way to render non-silo replies when p-bridgy-twitter-content isn't provided, and I'm not sure what that is yet. (https://indieweb.org/Twitter#original_lacks_POSSE_tweet does have some proposals and examples.)

[snarfed]

Sorry, I guess with your proposal, Bridgy wouldn't even try to render non-silo replies, it would just ignore the reply and treat it like a normal post. Understood.

...but if we did this, we'd probably switch the current behavior to allow non-silo replies after all, instead of adding even more complexity. We'd just need a reasonable default rendering.

[fancypantalons]

So, on your first question, I've not manually POSSE'd posts out to Twitter for non-Twitter replies (e.g. replies to blog posts syndicated to Twitter), but I have syndicated those posts out to Micro.blog. When I do it I'm pretty careful to make the reply meaningful outside of the silo context, and I think they work pretty well! My goal, in doing that, is to bring attention to the post on other silos like Twitter while adding some commentary, so it's kinda both a bookmark and a reply at the same time the way I'm using them.

Taking this post as an example: https://blog.b-ark.ca/2021/08/04/nice-for-my-blog-i-have-a.html

You can see at the top of the post the link marked up with the u-reply-to microformat indicator.

What I'd change in this post, with this proposal, is that that first link would change from this:

<a href="https://www.jvt.me/posts/2021/08/01/books-microformats/" 
   class="post-meta-url u-in-reply-to">
    https://www.jvt.me/posts/2021/08/01/books-microformats/
</a>

to this:

<a href="https://www.jvt.me/posts/2021/08/01/books-microformats/" 
   class="post-meta-url u-in-reply-to p-bridgy-twitter-ignore">
    https://www.jvt.me/posts/2021/08/01/books-microformats/
</a>

And then I'd add a hidden link in the post body, so the text would turn from this:

<div class="p-name e-content">
  <p>Nice!  For my blog I have a Calibre db containing metadata, covers, etc, for books. 
Then I wrote a Jekyll plugin that uses calibredb to pull the data out and populate my pages at build time. 
This reminds me I need to write a post about this…</p>
</div>

Into this:

<div class="p-name e-content">
  <p>Nice!  For my blog I have a Calibre db containing metadata, covers, etc, for books. 
Then I wrote a Jekyll plugin that uses calibredb to pull the data out and populate my pages at build time. 
This reminds me I need to write a post about this…</p>
  <p hidden>
    <a href="https://www.jvt.me/posts/2021/08/01/books-microformats/">
      https://www.jvt.me/posts/2021/08/01/books-microformats/
    </a>
  </p>
</div>

The "p-bridgy-twitter-ignore" indicator on the first link would cause Brid.gy to just skip over the link entirely and do nothing with it. Then, the addition of the second, hidden link in the post body would be picked up by Brid.gy and included in the POSSE'd tweet as just a normal link as part of the text.

A little hacky, to be sure, but you can imagine this being generally useful if a blogger wanted to selectively exclude content from a POSSE copy without replicating the entire content of the post.

Does that make sense?

Of course, if we could switch the behaviour to allow non-silo replies some other way, even better! But reading through the comments in the other issues, it seemed like that wasn't an option, so I was looking for some way to support it without having to bake specific handling into Brid.gy.

[snarfed]

Thanks for the details! Definitely understood. I'm open to it, with the caveat that we'd probably just switch to allowing non-silo replies entirely, without a new "ignore" mf2 class. Thanks for reading the previous issues and conversations, I know this would be a change from those conclusions, but it gets requested regularly enough that I'm open to trying it and seeing how it goes.

We're in the middle of migrating to Flask right now, so it's going to be tough to land other changes for a bit, but after that migration I'd definitely be open to a PR for this. I'll keep you posted!

[Ryuno-Ki]

Perhaps worth to add a label or to a milestone, so this issue won't get lost.

[snarfed]

Maybe! So far this is the only "do after Flask" task, so I'm not too worried, but if we start to accumulate more, I can definitely consider it.

[fancypantalons]

So, in terms of design here, the idea of something like "p-bridgy-ignore" as a way to tell Bridgy to ignore a non-silo reply link strikes me as still a possible option.

The nice thing about that is it still allows Bridgy to catch errors in the case where someone accidentally screws up a u-reply-to link, which I know was a concern in previous proposals, as it requires the user to affirmatively indicate it's a non-silo reply link, as opposed to having Bridgy try to figure it out (or have Bridgy just not flag these as an error).

That said, are there other ideas for approaches, here, that might be preferred?

I only ask because if I'm feeling motivated I might try to cook up a PR, but obviously it'd be better to do that based on an agreed-up proposal!

[snarfed]

@fancypantalons true! Good point, p-bridgy-ignore does allow intentional non-silo replies while still preventing unintended ones. I do like that, but I'm still reluctant to add much more complexity and cleverness to Bridgy Publish, since its headlessness and lack of a dedicated API channel continue to make it an awkward fit for logic like this.

[snarfed]

Done. Feel free to try it!

[fancypantalons]

Ooo! And almost a month ago, too... this is what I get for not paying attention.

I will absolutely give this a try! Thank you!