I guess the SSIA: I have set my micro.blog to cross-post to my Mastodon account. However, I was under the impression that I would see replies Mastodon users made to the cross-posted items, but that is not what is happening. For example, I made this post to MB:
https://micro.chrislott.org/2023/06/29/im-quitting-reddit.html
Which cross-posted here as expected:
But the reply that you can see at the 2nd link is nowhere to be found in micro.blog – should it be?
I think this (unfortunately) only works if there is a link back to your blog in your post (such as one that is too long and gets truncated). Because then it triggers a webmention.
This has been my experience, but I’d be happy to be educated otherwise and hear about another option.
There are two forms of Micro.blog support for ActivityPub. One is an ActivityStream from your Micro.blog account directly using your Mastodon Compatible username. That is sort of like “RSS for Activity Pub”. If someone subscribes to that and replies, that reply will go to Micro.blog.
Cross-posting is different, and is like cross-posting to Tumblr, Twitter, or any other service. In that case, Micro.blog is publishing your content directly and natively (as feasible) on your behalf to that platform. In that case, there is no link between your blog and that post once it is made (unless it is a long post, truncated, with a literal link back to the permalink with your URL). In that latter case, if the service someone is using to reply to your post supports and issues web mentions on replies (or you use a service like Bridgy to get webmentions from that service when your link is used), Micro.blog will collect that webmention. Webmentions are not replies on Micro.blog although replies on micro.blog do issue a webmention. A webmention could appear on your website using the Conversation.js plug in that will present webmentions as “comments”.
Thanks, that clarifies things. Now I need to think through whether I want to use things as it stands, or essentially move to MB as the place for Mastodon users to follow me and interact. If I go with the latter, it looks like I can migrate using this help doc.
It requires understanding that Mastodon is a product built on a protocol. The question is do you want your content on your blog to be something people can subscribe to using that protocol, just like someone can use RSS to follow your blog versus visit it, or do you want your content on your blog to be copied to the Mastodon product on your behalf?
The difference is crossposting, which works just like cross posting always has and subscribing, which is like RSS.
The underlying protocol that Mastodon (and Pixelfed and Lemmy and whatever other “fediverse” products) build on has a mechanism for subscribing which is meant to be more real time than RSS. Having ActivityPub enabled means people can subscribe to your blog just like they can subscribe to RSS. The main difference between RSS and ActivityPub (other than push v. pull) is that ActivityPub also specifies a means to reply to messages you subscribe to. Micro.blog could have ignored this and just treated ActivityPub as a mechanism for subscriptions only, but it went further and will respect those replies and make them appear like Micro.blog replies so that you can view and interact with them.
RSS has no reply to mechanism. The collection of protocols sometimes called the Indieweb does have an answer to the ActivityPub reply which is both simpler and less robust in some ways, known as WebMentions. This is a separate protocol that Micro.blog has also supported for some time. Webmentions are not as widely adopted as ActivityPub at this point, and are generally not coupled with RSS.
However, it’s entirely possible to build an RSS reader with a reply function that results in posting a reply on your own blog (or someone else’s web service) that sends a webmention that may or may not be handled by the original site. Sites like Bridgy essentially act as a way to convert other forms of replies and mentions into webmentions.
I think a lot of folks on Micro.blog (and off of it) are deeply confused about ActivityPub the protocol, and Mastodon the service. But really, it’s not that different than Micro.blog before versus Twitter crossposting. If you crossposted to Twitter, you just wrote a native tweet that had nothing to do with your original blog post once sent. It was just Micro.blog being a computer in the background who took your post and turned it into a tweet that lives on Twitter and can be replied to on Twitter. That’s what crossposting to your existing Mastodon account does.
Mastodon, however, because it uses ActivityPub, is able to interact with products that are not Mastodon more natively. ActivityPub support means people in Mastodon can see your actual blog post on Mastodon and can reply to it on Mastodon while your experience remains completely contained within Micro.blog’s ActivityPub handling.
I would love to know what is confusing about this support in general, because I think the language that exists is broadly clear, and more than that, the experience “just works” such that very little of this seems to matter, practically. But I’m sure Manton would love to hear what words people are looking for at what stage to help people make a decision (though I don’t really think there are many downsides to just using Micro.blog and not really thinking about it past that).
@jsonbecker I think this is a very helpful explanation to a very confusing situation. Thank you for posting.
I think perhaps a reason why it’s confusing is because many of us have gotten used to a situation where social media is a series of walled cities that have barricaded themselves off for each other. Facebook, Twitter, Reddit, YouTube, etc., are built BY DESIGN so that you have to be a logged-in user to get the full experience. And it’s getting harder and harder for non-logged-in users, or users of other platforms cities to participate. This has been going on so long that it seems to many of us to be natural.
The Fediverse—including micro.blog, Mastodon, Lemmy, etc.—are consciously trying to strike more of a balance, building broad, flat highways between their cities while each still tries to maintain its unique character. It’s a laudable goal, but it can be confusing to those of us who’ve grown accustomed to 10-ish years of walled cities.
Thanks everyone for the discussion and helping clarify how this works.
I think it’s also confusing because there’s no single best way to post to Mastodon from Micro.blog. Unlike most other networks, Micro.blog gives you two options: copy a post to Mastodon via cross-posting, or let Mastodon users follow your blog posts directly via ActivityPub. This flexibility makes things confusing because they work very differently but solve a similar problem.
And it’s a personal preference so I can’t say “this is how you should do it”. I like using ActivityPub because it’s just one blog to maintain and I get replies directly in Micro.blog, but other folks like separating things out with cross-posting because they want to manage Mastodon with its own sign-in, etc.
I do it both ways: I have ActivityPub activated on my Micro.blog site, and I also have a mastodon account. When I post to micro.blog, I then boost it from my mastodon account.
I use my mastodon account to read mastodon, and reply to other mastodon users and boost posts from there.
I’m sharing this in the hope that this perspective proves useful to other folks grappling with the decision whether to activate ActivityPub from micro.blog, or cross-post to Mastodon.
I’m active on micro.blog, Mastodon, Facebook, BlueSky, and Tumblr. I often wish they could all be just one thing, and save me the hassle of cross-posting and cut-and-pasting.
First, props to @jsonbecker for the explanation. I think comparing AP to RSS makes it super clear. Also, @manton saying that X-posting is creating a “copy” makes it clear.
So, for MitchWagner (and anyone else willing to answer) I am wondering about the boosting behaviour. When you boost the Mb post with your person Masto account, and people reply to the boost, do those replies track back to Mb? Or is boosting a Mb post on AP creating another “copy” in the sense of Manton’s above?
Except for Facebook, you can cross-post to the rest, right? But as this discussion explained, you will still have to go to individual platforms to view (and respond) to replies. Otherwise, you can simply use those as a broadcast channel and not worry about responding to replies.
Often replies go back to my Micro.blog account. I don’t know if that’s 100% the truth.
I’ve gone back to cross-posting to Mastodon. It’s just simpler that way.
Cross-posting has its own problem. Each platform has its own cultural and technical uniqueness.
micro.blog posts can be unlimited length. Except for on the timeline, where they can be up to 300 characters, or 600 if there’s a blockquote.
Mastodon is 500 characters, and permits threading.
Tumblr is unlimited length, and encourages link previews, though inline links work fine.
Tumblr and Mastodon have link previews. On Bluesky they’re optional. MIcro.blog does not support link previews.
Speaking of which: A few weeks ago, someone here suggested micro.blog should support link previews. My initial reaction was HECK NO but now I’m starting to like the idea.
Does not this plugin solve this?
He means the MB timeline itself does not use open graph metadata to design cards or other interface elements.
If they’re boosting a post that isn’t cross posted but just from your ActivityPub stream from MB then replies will show up in MB because they are replies to that post.
Cross posting does not preserve a connection back to the original MB post. It’s just a completely native post to that service that is a disconnected copy from the original.
Correct—but not just the timeline. It might also be good to display previews on the web and in RSS feeds.
However, the open graph plugin looks useful and I’ve installed it.
Thanks!
That’s a feature of many RSS readers and I don’t think is a good idea to bake in the feed. For example, using Feedbin and Reeder I get the full content of most links in posts in my RSS reader without having to click through.