Two weeks on Micro.blog, and some discussion of "likes" micro.jayeless.net
@jayeless
Geez. What’s it with providers “selecting” what features are best for people? This is a huge let-down by micro.blog. The standard on Likes is well defined and used by many peoples and platforms. The beauty about Webmentions is _that_ the user has the choice what to do with them (and how). Not supporting this officially for a higher cause as a provider is highly opinionated (read BS). And since it’s just HTML you can do it anyway if you’re willing to jump the hoops.
You _could_ e.g. redefine your Webmention endpoint, and use another one. Self hosted or e.g. from webmention.io – may be a pain in the neck to integrate on a foreign platform though.
( And while on it could connect to backfeeding services like brid.gy 🙂
@beko.famkos.net You're not wrong, and I'm sure there are ways to work around the official lack of support. Like if I stripped the e-content class from the div that contains my post, I could manually code a conforming webmention "like" (but then I'd also need to manually add the e-content div to every normal post). I'm not sure if there's a way to specify a different template for a specific category, but if that is possible, that'd help a lot – then I could have the flexibility to manually code webmentions in a "Responses" category, while not causing extra friction for myself making normal posts. Although this would still be more work than just leaving a comment when I'm tempted to leave a like.
The other thing I considered was having a "Responses" folder on my static site, with manually coded responses that I'd then use Telegram or something to send. I think that would work technically, it's just it'd be such a laborious process that I don't think I'd ever bother. Responses are also the kind of content that I think would be better placed on a blog.
I believe you're right that I could switch out the default endpoint for Webmention.io (and maybe integrate Brid.gy), and then receive likes as well, but I feel like that might introduce bugs I lack the expertise to fix, and I'd also probably lose the comments made before the switchover. Really I'd prefer it if the platform itself could at least receive and find some way to show me webmention "likes", even if they don't want neat "like" buttons on their site.
@jayeless I see they even broke reply-to. What is going on with micro.blog? This was not a reply to your own micro post o0
How would my endpoint know what to make of this when in-reply does not refer to the origin? This is killing me (and this worked nicely before) :-(
(Not your fault, of course)
@bekopharm Hmm, surely that has to be a bug. Based on what I'd read about Micro.blog's Webmention handling, I thought your post was supposed to be alerted that I'd replied 😔 After all, even if there should be a u-in-reply-to back to my original post (so all the discussion shows up there), my understanding is that there can be multiple u-in-reply-tos, so one back to your comment seems like it should also exist. What's more, based on what I've read about Micro.blog's implementation of Webmentions, I thought it did work that way, or at least used to. I wouldn't think it'd be too hard to fix. On the backend, the system knows full well the link your comment came from.
@jayeless I'm not absolutely sure how my CMS handles this but afair(!) each reply gets it's own tiny html snippet that the parser gets to see while the user gets redirected via html meta refresh (not JS) to a threaded view (that also has all the data and could be parsed as well so here you get multiple nested in-reply-to (and probably h-cites)). This (or different request from text/html) is probably here the case as well so the parser gets not multiple or nested u-in-reply-to when beeing triggered by a Webmention but a single h-entry comment.
What I get from comments with others are in-reply-to (and reply-of) links pointing to an individual comment h-entry allowing my system to make a threaded comment ouf of it on my end again. This works and allows for threaded comment views.
Thing is that this in-reply-to here seems to point to your original post not to an individual comment you actually replied on. Your comment (10667116) has no trace of beeing a reply to 10668107 when parsing it's source origin (url), see php.microformats.io (this is what the parser sees following the source link)
So I only got a notification (mention, alert, whatever) and comments never show up on my end, which kinda defeats the purpose of this (e.g. allowing me to read comments and reply in my own reader or display them on my own website).
See also: indieweb.org/reply
- Link to the original
This is from my understanding broken :-(
For reference a working example: php.microformats.io
A CC @manton may be in order.
@bekopharm @jayeless Thanks, I'm trying to unravel what is going on here... There is definitely a reply-to in the HTML, but I think it always points to the original post. We could change that, but I want to make sure there wasn't a reason for it to work that way so I don't break anything. (As for likes, I think it's worked out well not to have any. It's good to revisit that every once in a while, though!)
@khurtwilliams is there a reason you’re @‘ing me on Manton saying in 2020 how he handled webmentions which appears to be the same comment of comment things?
@jsonbecker, I wanted to gently point out something that might have been a bit unclear in our earlier exchange. It seems there's a bit of a hiccup with the external u-in-reply-to Webmentions linking to micro.blog comments. I've shared that thread where others have encountered a similar issue. I know they were functioning before but now there's an issue. Perhaps @manton could take a peek to see if the solution might be on the micro.blog side of things? My WordPress logs indicate that the Webmentions are being sent out successfully.