Replies

@workswellforme My interest is piqued! I will follow along closely. I have dabbled with electronic paper myself but never ended up with a finished project. Yet. 😊 Looking forward to your next update.

@UndamnedOne Are you trying to do headings with the #? If so, add a space after the #.

@toddgrotenhuis This is now fixed in the latest version of my plug-in (1.2.1). I used some modern shenanigans in the templates that the old Hugo (0.54) didn’t like. Thanks again for the report, and sorry for the inconvenience.

@gr36 I had a similar thought the other day - maybe I deserve an OLED Switch to celebrate the next Zelda? 🤔 I don’t strictly need one, as my current Switch works just fine. That screen, though… 🤤

@manton What are your thoughts on enabling cross-origin requests for API endpoints? I’m prototyping a plug-in that makes use of this endpoint, but as the fetching is happening on the client side I hit a wall. 😢

@SimonWoods It’s not a contact form, so your email address will be in the HTML. But as ciphertext (not plaintext).

@SimonWoods There should be a checkbox, Obfuscate email address, in the settings. If you can’t see it, you’re probably not on the latest version (1.2.0).

I won’t go into the implementation details here, as that kind of defeats the purpose of trying to obfuscate the email. I don’t want to help the script kiddies too much. If they absolutely want to scrape email addresses off the lovely people here, at least they have to work for it and figure out the scheme by themselves.

It’s JavaScript-based, though, so if that’s a no-no for anyone, they should disable the feature and the plug-in will revert to the previous version’s functionality.

@Alligator Haha, I laughed so hard at this. 😂 I just arrived home a couple of hours ago. From a cake store. Ordering a custom cake. What have I done?! 😱

@pratik Let me know if there’s an issue with the experimental feeds, and I will look into it. 😊 I need the URL of the feed in question and a description of the issue.

@AndySylvester To convert the JSON string into a map, you can use the unmarshal function:

{{ $glossary := $.Site.Params.glossaryData | unmarshal }}

The value of the key “calculator” is “{{ $glossary.calculator }}”.

@AndySylvester I have no insight into what’s going on behind the scenes, but I do see your plugin.json file is missing a semicolon at the end of line 4. Micro.blog is probably choking on that and that’s why your plug-in won’t update.

When you make changes via Design → Edit Custom Themes they will be reflected right away because you’re circumventing GitHub altogether. But the changes are local to your account. Other users who installed the plug-in won’t see the changes you make there.

@MitchW In most cases you should just have to wait seconds (not minutes) but yes, that is correct. But doing that refresh dance sounds horrible. 😱 If “real-time” updates are that important to you, go with the official feeds instead. 😊 My experimental feeds will always lag behind a bit.

@MitchW It depends. If someone else fetched the feed right before, you might get a fresh copy. If you’re the one triggering the cache bust, you will have to make a new request to get the fresh copy. In the best case, that copy is ready for you in a second or so, but it can take longer.

@AndySylvester @help Up to two hours, according to this post. If you want to see your changes in real-time, you can make them via Design → Edit Custom Themes instead and commit them to git when you’re happy with the result.

@crossingthethreshold @maique Knowing a bit about how caching works for my experimental feeds might shed some light on the phenomena and inform your decision if Feedbin is for you or not. Caches are shared among us, but to make it easier to reason about, let’s pretend that you (or rather your Feedbin account) is the only person in the whole world fetching my experimental feeds… It goes like this:

  1. You make a request to the URL https://micro.blog.via.dahlstrand.net/posts/discover.
  2. If it’s less than two minutes ago since the last request, you will get the cached version of the feed.
  3. If more than two minutes have elapsed since the last request, you will still get the cached version of the feed, but my service will also fetch the latest version in the background and update the cache. The next time you make a request, this newly fetched version will be returned.

So, the maximum age of the feed you get depends on how often you (or Feedbin rather) check the feed for updates. Say, for example, that Feedbin checks the feed every minute, then you will always get a version of the feed that is no older than two minutes. If the feed is checked every 5 minutes, you can get a version of the feed that is up to 10 minutes old. Check it every hour, and you can get a cached version from two hours ago in the worst case. And so on.

As I mentioned earlier, cached versions are shared among all of us. That means, the more people subscribed to a feed, the higher chance that you will get up-to-date content. (Someone else might have already triggered an update of the stale content for you.)

If the freshness of the feed is important to you, you should choose a feed reader service or app with the ability to set the fetch frequency or to manually trigger a refresh. That way, you can make sure to always have the latest possible version of the feed.

@pratik That shouldn’t really be able to happen anymore, but let me know which URL you’re trying to subscribe to in Reeder and I will troubleshoot from here.

@MitchW Hopefully I have now fixed the problem, please try again.

@matti Seeing them in the wild always brings a smile to my face. Thanks for checking out my plug-ins! 😊

@manton I experience a couple of oddities with this URI scheme. Opening, for example, microblog://open/17620435 works as expected on macOS if the Micro.blog app is already running in the background. If not, the app is opened with the timeline showing instead of the conversation thread.

On iOS, the app is opened on the timeline, regardless of the app running in the background or not. Is this just me, or can you confirm this behavior? 🤔

@tomselmes Yeah, some app developers might choose to block certain links and other elements from the feeds. Unless there’s a setting that toggles this behavior, there is not much you can do, I’m afraid, other than making a feature request to the developer or switching to a feed reader that allows links to open other apps.

@sherif Interesting indeed! Maybe @netnewswire can bring some clarity: is NNW on iOS okay with links using URI schemes other than http and https? microblog, for example.

@numericcitizen It’s definitely experimental and might go away at any time. That said, I’m subscribing to some of these feeds myself and have no immediate plans to shut them down. But again, it’s a random free service on the web (just like MySpace, Google Reader, or Twitter) and will cease to exist someday. So don’t depend on it. 😅

@sherif Some services might decide to block the microblog URI scheme that is needed to open the Micro.blog app. I know for sure that Feedbin does, maybe you’re using them to sync your NetNewsWire subscriptions? If so, try adding the feeds directly to NetNewsWire instead.

@pimoore Hmm, good question, I don’t know. Is there support for opening conversation links in the Micro.blog app, @manton? Something like microblog://conversation/12345678 or similar?

Sitemap for dahlstrand.net