I wanted shorter permalinks for my instance, so I added configuration options for using a newBase60-encoded timestamp - and for using precision to the minute instead of the second, both because it's shorter and because it allows me to plan when to post something and predict my permalink, which can come in handy if I want to syndicate it and include a syndication link on the original, although I haven't done that so far.
I'm not sure whether there would be any demand for that, but I thought I'd ask whether you'd like it contributed upstream.
I think this is a more appropriate representation of the nature of the surrounding context, but that's definitely an opinion and could be wrong. If you agree and you'd like me to do so, I could figure out how git-send-email works and send a patch. (the three issues I submitted before this one are such small changes that I questioned whether it would be simpler just to recreate the fix, but I wouldn't mind sending those too.)
display_og_metamacro in app/templates/utils.html, the og_meta.title gets used as anchor text. Because Tantek Çelik often uses the entire text of his notes as the title, I noticed there was no length restriction on this, which can get quite messy. My personal solution was to replace
og_meta.title | truncate(200).
If I remember correctly, this was specifically the case for some users of Bridgy Fed, and the result of this was that trying to look up an actor with an array of urls would cause a 500 error because the url property might or might not return an array. My local fix was just to take the first one in such a case - changing
ap.as_list(self.ap_actor.get("url")). And then I forgot I'd meant to report the issue and offer my fix back upstream.
I'm pretty sure those invoke the tasks defined in tasks.py (and implemented in the corresponding files in app/) that do the actual inbound and outbound federation of activities.
I almost replied without double-checking, because you did it almost exactly the same way I tried. (logging whose lookup failed is an improvement over my quick fix.) But yes, verified this prevents the error. Thanks!
I think you're correct that it is not technically needed; the h-feed documentation says to do that to aid in discovering the "feed or feeds" if your home page doesn't contain your primary feed, and the "feed autodiscovery" section had given me the impression that if the home page contained a feed but there were also links on the homepage that went to other feeds, they should be marked that way. On further inspection and reading, I think:
- I may just be straight-up doing it wrong. I think, to the extent it's supposed to be correct, it may be supposed to be for a
head, not for an
a, for one thing, and what I'd done was mark up the anchors in the header, not the links in the head.
- I'm pretty sure the only use-case in which what I thought I was doing would matter would be someone using a reader or browser that actually detected, from looking at the home page, that there were multiple h-feeds available...and in that case I think I should be marking up leads to tags the same way.
I'm probably going to back that part of my changes out for now and ask around.
Heya, Sorry for the late reply, I've been travelling. I think option number two makes sense. It might also make it easy to allow subscription to h-feed and rss content in the future?
On Sun, Jan 1, 2023 at 8:39 AM ~x3b0b email@example.com wrote:
For what it's worth: Since all the appropriate microformats markup for IndieWeb replies/likes/favorites/reposts go inside the h-entry, I had previously concluded that this should be possible already - it just isn't convenient, because without any special UI for it, you have to write the HTML yourself. And, as you alluded to, it currently appears as an AP note (or article, presumably) with a link in it. Which, of course, is an entirely reasonable thing to post, but doesn't convey the same meaning.
I had already been meaning to test that conclusion, so I did: https://bw3.dev/o/7e024e0ff6f34dee8c93e976887b899c
That said, I'm all for lowering the barrier of "you can do it, but you have to write your own markup" if you are happy with your idea for how.
As for the visibility option, I can definitely see how this and other purposes might make it nice to be able to say "don't send this to my followers" without also having to say "don't let anyone I didn't mention see it." I had to look at some posts and how-tos to try to be sure I was remembering this correctly, but while favorites/likes/reactions in the Fediverse are public information, in that you can look and see who has liked a post; but unlike boosts/reposts/replies, they don't turn up in your followers' timelines. So on top of AP not supporting such actions on non-AP objects, what I described above is inherently more visible to your followers than the equivalent AP action.
After doing some more tests, I've now thoroughly confused myself as to whether or not I think it potentially makes sense to want to skip sending a post to the AP stream without also making it unlisted, partly because my thoughts on that bleed over into two completely separate (but slightly related) enhancements I've been thinking about trying to implement myself.
-- View on the web: https://todo.sr.ht/~tsileo/microblog.pub/49#event-219475
-- regards, Ashton McAllan http://acegiak.net
Doggone it, I said that wrong. This was technically an attempt to reply to a post that mentioned the unavailable profile, not one of that actor's posts, but I suspect the result would be the same, since either way my server would try to look him up and fail.