Replies

@matti Me too!

@manton This is awesome! 🎉

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

@warner @pratik Hey! 👋 Just wanted to say that email obfuscation is implemented now.

@sannalund I can paint some eggs maybe? 🐣 Nice work, @hollie!

@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?! 😱

@SimonWoods Install 13.3 and join the fun! 😊

@odd 🫨

@sannalund Yay, I’m so glad you’re finally here, welcome! 🥰

@vincent 👀 Looking good!

@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.

@cdevroe I don’t know about an equivalent for bloggers, but Hacker Stations is a similar thing for computer enthusiasts. 💻

@samgrover Congrats! 🥂 🥰

@news Nice! No more hacky workarounds. 😊

@todor Yeah, there is something magical about that place.

@AndySylvester 🎉

@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.

@AndySylvester I added an object like this to the fields array of plugin.json:

{  
  "field": "params.glossary",  
  "label": "Glossary JSON",  
  "type": "json"  
}

@maique 🥰

@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.

@numericcitizen This is not a plug-in or something that will change the behavior of your blog, it’s about the experimental Micro.blog feeds I provide for use in a feed reader.

@pratik @pimoore @manton Yes, and I’ve made the necessary changes now. Next time the feeds are updated, you should see two links instead of one:

@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?

@brandontreb @V_ Feed readers with Micropub support do exist. Monocle and Together are two examples. Micro.blog is another one, but a bit limited as it expects one (sub) domain to equal one feed.

@crossingthethreshold Yeah, your provider can cache the files for however long they want: minutes, hours, or days. That’s outside my control, unfortunately. 😢

@pratik @crossingthethreshold @help If the in-app browser has an address bar, you can just copy & paste the sign-in URL there. If that’s not the case, you have to figure out a creative way to get around the limitation. 🦹

One solution is to navigate to your email provider in the in-app browser, sign in and click the Sign-in to Micro.blog link from there. For example: click the conversation link, and you should end up on Micro.blog (but signed out). Then click Discover followed by 🔍. Search for the name of a decent search engine, like DuckDuckGo. Find a post on the timeline that links to said search engine and, from there, search for your email provider. Now, sign in to your email account and click the Micro.blog sign-in link. You should now be signed in to Micro.blog in the in-app browser. Celebrate! 🥳

Another alternative is to disable the in-app browser in your feed reader to open links in your regular browser instead.

@crossingthethreshold To avoid overloading Micro.blog’s servers, I cache my version of the feeds for 120 seconds, but that means they shouldn’t lag behind the official feed for much more than a couple of minutes or so. I’m looking at my version of your feed right now, and it’s identical to the official one. The latest post is from 30 minutes ago.

@pimoore So good to see you back on the timeline, by the way. You’ve been missed!

@pimoore Those feeds are for subscribing to discovery, emoji, and user timelines, so it doesn’t really make sense as a plug-in to your blog. But it could be a default option for the official feeds. That’s something for @manton to meditate over. 😊

@pimoore I’m hosting a handful of experimental feeds over at micro.blog.via.dahlstrand.net. They add a Conversation on Micro.blog link to each entry like this:

@toddgrotenhuis Thanks, I’m glad you find it useful!

@AndySylvester @help As an alternative, you could expose the glossary data as a JSON field setting instead of a file. That way, people using your plug-in can just hit the Settings button and edit the glossary data directly, like this:

@pratik The editor will be available at another address (on the subdomain of your test blog) but as long as you use the same theme on both blogs the preview will look identical.

@pratik You can work around this by installing my plug-in on your test blog instead.

@JohnPhilpin Forget about the screenshot for a while, the interesting thing with the post is in the text. Or rather, the length of the text. If you count the number of characters, you will end up at around 600 of them. That shouldn’t be possible on the Micro.blog timeline, only posts containing quotes are allowed to be that long before being truncated.

But the post does not contain a quote. So how can it be that long and still show up in its entirety on the timeline? Thanks to a little HTML snippet, shown in the screenshot.

It’s just a silly trick. Or bug. Or feature. 😊