Well this thread went absolutely nuts. Thanks to everyone who tested things out! I’ll have to write an update or a follow-up post, but after a way-too-late-night hacking session, my implementation now supports:
• Better configuration options
• More reusable OP/verified badging
• Link cards
• Spoilers/content warnings
Hm, we hit the default limit for a single Mastodon API call… it looks like I have to figure out how to handle HTTP headers and perform follow-up API calls to grab more than 60 replies!
Thanks to everyone in this thread stress-testing with me; I’ll get it sorted out. :)
Unfortunately, it appears to be an intentional, undocumented limit for unauthenticated API calls to the context endpoint… however, including an authentication token would require me making people sign in to view more comments, or leaking a token that would enable people to read my private statuses.
@knu I meant folks shouldn't comment "me too!" on the linked issue; discussing whatever here is fine. 😃
Yeah I understand why it would have some limiting… it's just frustrating that it was entirely undocumented AND the only ways to provide authentication client-side would either require folks to log into a Mastodon account or for me to leak my own private statuses…
This may just lead me to build the thread at build time which is a lot more work and necessitates storing folks' posts in my repo.
@knu I guess it should be totally possible to use a dedicated bot account without any statuses to authenticate the API without leaking private statuses. It basically undoes the DoS protection, though, as anyone could find that access token.
@cassidy At least DoS attack by a bot (or its stolen access token) can be stopped by the admin of the attacked server, by disabling the account. (just my 0.02, I have little experience)
Good news, everyone! I’ve added support for an access token to my code which means we’re back in business.
For those who want to re-use the code, creating a token requires a dedicated bot account on your origin Mastodon server unless you want to leak your private statuses. And using the token effectively lets anyone make authenticated API calls, though harm should be relatively limited.
It’s better than nothing—and if omitted, you’ll still get 60 replies as before.
@mathieucomandon ha no it’s definitely a “me” problem! By default, the status/context API call seems to limit the response to 60 replies, because that is a LOT of data to send in a single request—each API response is basically a document not just of the content of the replies, but of everything you would need to make a social media client app. So every user’s public profile is included with every post, including all their links and their full bio and links to all the images for all emoji, etc.
@mathieucomandon however, the API helpfully includes a pointer to the next “page” of results in the header of its response if the response is limited… my code just doesn’t handle that response at all yet. 😅 It should be straightforward once I figure out how to actually read and process that header. I just haven't even looked into it yet.
@mathieucomandon ha, it turns out I was wrong; it is an intentional (but undocumented) limitation of the unauthenticated API. Which makes sense, it’s a heavy API call.
I’ve reported the issue to Mastodon, proposed an update to the Mastodon API documentation, AND pushed an update to my site to use an authenticated API call. :)
@cassidy that comment system is really cool and I'd like to give it a shot on my Pelican based blog. But if I understand correctly, you need to manage your own Mastodon instance, is that right?
@mathieucomandon no, not at all! You can use it with any Mastodon account, and don’t even need an API key in most cases.
If you expect to have more than 60 comments on a post and/or your server has authenticated fetch enabled, then you will need to provide an API key from an account on the same server—I would recommend a throwaway/bot account because that API key will allow anyone to read THAT account’s private posts/DMs.
@mathieucomandon I originally used “any account on my own Mastodon instance” as a sort of “verified” shortcut since I do have my own instance, but I have since changed it to distinctly style the original poster’s account, and also support an arbitrary list of “verified” accounts that can get styled distinctly.
@cassidy that's really cool! I don't think Fosstodon would let me run a bot account but I could do it from another instance... or run my own, which is something I'm considering more and more.
@mathieucomandon I think the bot account would have to be on the same instance, but I haven't tested that theory. But again, only needed if you expect to have more than 60 comments per post or I believe if your instance has authenticated fetch enabled (since I believe that doesn't allow unauthenticated API requests).
@cassidy 60 posts seems to be a good default. To avoid overcrowding the blog page, I could add a "Continue the conversation on Mastodon" link when that limit is reached
Thanks again for your post and your tremendous work, @cassidy! I just implemented your code on my website ^_^ I made some minor tweaks and added the additional option to check whether a Mastodon post is associated with the blog post or not. If no Mastodon post is found (id is empty), an appropriate message will be displayed (details and code can be found here: https://www.fabriziomusacchio.com/blog/2023-07-31-mastodon_blog_comment_system/). Huge thanks again 🙏 I really love this implementation, and I'm happy to have it running on my website now 😊
As a small UX thing: my first instinct was to try to figure out how to interact with this by scrolling to the very bottom of the page — but the instructions are at the top of the comments in the middle of the page. Would it be easy to duplicate the instructions / link to them, if there are enough posts to fill a few screens?
I’m only toying with different approaches and I can’t tell if a middle layer amounts to more hassle or more control (moderation, various sources) over time.
@cassidy Have you looked at the Lemmy API? I don't think it's as stragithforward as Mastodon, but I feel like Lemmy (and kbin) are better suited for being commenting systems.
Anyway... I think it's great that you did this and I hope this approach gets more popular among tech writers.
@cassidy@jwildeboer@julian@drahardja very interesting, thank you for sharing! I’m partly commenting just out of curiosity to see if my response shows up on your site 😀
@bhaugen replies in this thread show in the comments at the bottom of the blog post linked in the first post—however, we’ve exceeded the number of replies received with a single API call, and my code doesn’t handle automatically making follow-up API calls yet. So new comments on that post aren’t showing until I fix it. 😅
@bhaugen possibly, if @write_as allows arbitrary JS and CSS! I have tried to make it fairly reusable by pulling all of the Jekyll concerns out to the top to be easily replaced.
@GeekAndDad oh for sure. I think if possible, my plan is to actually use my own account for moderation if possible, e.g. if I blocked/muted someone, then hide them from the site.
Gotta figure out if I can do that with an unauthenticated API call or not though; if I need an API key, the integration gets a little more complex.
@cassidy Interesting approach. Sounds ideal if not too difficult. I was thinking you’d just have an extra button as admin and their user handle would get added to a static file that is a list of people who’s comments don’t get displayed (they halt traversal of a given tree branch so replies to their post also don’t show up). Your approach is better :)
I'm really wondering though if there's a way to not have to rebuild and publish the page twice, once to get the post URL to post on Mastodon and then again after adding the Mastodon post ID. 🤔
Like you say, doing it through the build process might be the best option, but you might end up with broken links in your Mastodon posts if the process fails, or at least until the new build is published. 🤔
Add comment