Replied to https://jan.boddez.net/notes/fa768af33f

May one day port some of the tricks … May one day port some of the tricks I’m using to “greatly” simplify my “WordPress IndieWeb experience” to an add-on plugin, or a theme, or both. Or at least better document how I do things like set titles (yet “hide” them on the front end) for notes, to make for a more convenient back-end browsing experience. As an alternative to Post Kinds, perhaps, and existing themes. (And then make the whole thing Gutenberg-compatible. 😬) By Jan Boddez on Sep 8, 2020 Also on Mastodon Replies Jan Boddez on Sep 8, 2020 Always said I much preferred my Laravel setup over proper WordPress, because of all the control I’ve got over the front-end markup, but my web host has sort of made things much more difficult to maintain. And fully custom code’s way harder “to share to the world,” too. And I’ve been way overthinking things—what’s new? Via jan.boddez.net, in reply to May one day port some of the tricks ….

May one day port some of the tricks I’m using to “greatly” simplify my “WordPress IndieWeb experience” to an add-on plugin, or a theme, or both. Or at least better document how I do things like set titles (yet “hide” them on the front end) for notes, to make for a more convenient back-end browsing experience. As an alternative to Post Kinds, perhaps, and existing themes. (And then make the whole thing Gutenberg-compatible. 😬)

Comments

Jan Boddez on Sep 8, 2020

Replied to https://jan.boddez.net/notes/fa768af33f

Always said I much preferred my Laravel setup over proper WordPress, because of all the control I’ve got over the front-end markup, but my web host has sort of made things much more difficult to maintain. And fully custom code’s way harder “to share to the world,” too. And I’ve been way overthinking things—what’s new? Via jan.boddez.net, in reply to May one day port some of the tricks ….

Gutenberg compatibility would be killer. All the tools are there in Gutenberg to make awesome IndieWeb friendly posts, but might be difficult to get it to play nice with the current plugins & themes.

Replied to https://jamesg.blog/2020/09/08/rethinking-the-blog.html

Rethinking the Blog

The reason this blog still exists today, after going through so many iterations, is that I always self-dogfood. This is a term in the IndieWeb community that means that I use my own creations. On my blog, everything has been built by me, for me. I haven’t thought about whether my code could be used by other people. It probably could. It’s all on GitHub for anyone to use. I have licensed my code under an MIT license so anyone can use it.

Over the last two days, I have found myself frustrated by this blog. My primary concern is scalability. When I say it out loud, I do wonder why I am so worried about how my site will scale. With all of the computing power available today, it would take a very long time for me to reach a point where my website rendered slower than a point I deem acceptable.

I am worried about scalability because I want this code to be lean. I don’t want to be bogged down by slow rendering times that make changing my site difficult on my local machine. I like speed. It’s the very reason that I moved from a site powered by React.js and Next.js to a static website. The way I see it, I have three options: build my own dynamic site, continue to use Jekyll, or look into another dynamic site generator.

The Dynamic Option

When I had a spare moment yesterday, I noted down what benefits of having a dynamic website are most important to me. The highlight was that I would have more control over the content that I share on my site. I would be able to experiment with new types of content because I’d have access to a database. My database could keep growing to support thousands of entries. I believe that if I had the option, I would be creating content on a similar cadence for this website between my blog posts, reviews, quantified self reports, and other data that I would generate.

Having a database gives me a lot of options. I know how powerful SQL is. I could use it to analyze how I post data over time. I could use it to easily support multiple post types. I could integrate my site with tools like Micropub to share my content on the internet. The question is not whether databases give me options. I am wondering whether they are giving me the right options.

I must note the educational benefit of building a static website. I am unsure what technology stack I would use. Flask seems to be the most appealing. I have quite a bit of experience with Flask and so I could probably get quite far in a short period of time. This is speculation. When I look at what I would need to do to set up a Flask site, I see tons of work that is, when I am really honest with myself, unnecessary.

The Static Option

I chose a static website for simplicity. My last site made API calls to Airtable to analyze my coffee data. I had a button on my desk which, when pressed, updated a counter on my site which said how many cups of tea I had drank that day (back in the days where I was more of a tea drinker). These were features. They were good additions to the website.

I can remember myself getting stressed about the state of my site. React, for a blog? It may work for some people but for me it seemed like too much. What’s more is that I got lost in components. I did not really understand how the site worked on a nuts-and-bolts level. I knew that it worked and that was good enough for me.

Static websites introduce new constraints. I cannot create database tables for new types of content. Do I really want to have that option? I’m not sure. I like the current structure of my site. Everything is so visible. All of my posts are stored in markdown which I believe is easier to maintain than a database. A few days ago, I went and updated all of the titles on my blog posts to use the correct capitals. It was bugging me for a while that Jekyll just capitalized the first letter of each word.

I went back and made the requisite changes to all ~60 or so posts. It was manual but it was so easy. With a database, I would have had to write individual queries for each post. That would have been a pain to do. I probably would have given up on the task before I had finished. Maybe that would have encouraged me to find a way to update my posts that I cannot presently envision. Who knows.

I like having a Jekyll site. I am proud to be on Jekyll. My content is easy for me to understand. I have a folder called _coffees where I am going to store my coffee reviews. I have a folder called _posts where my posts live. Adding new content to the site is simple. That’s what I like and need. The more difficult it is for me to update my site, the less likely I am going to do it.

Other Generators and Next Steps

I came across Jamie Tanna’s personal website yesterday. It was not the first time I have been a guest. 1 I read that his site was powered by Jekyll and I got excited. I thought someone had cracked the issues I was facing with scalability. It turns out that he moved to another generator, Hugo. His Jekyll site took him far but he felt like a change was necessary. Jamie documented the process of moving over to Hugo on his blog.

I tried to set up Hugo yesterday to see how it works. One of the thoughts that came to mind is “why am I doing this?” That is a very good question. Why am I looking for another static site generator? What I have right now works fine. It may not work if I have ten thousand pieces of content on this site. That could happen if I build more elaborate bookmarks feeds, or write a lot of webmentions over the years. But what I have now works. It works. It works. 2

As a programmer, I have a tendency to over-complicate my work. I spoke about this in a recent blog post. There are so many ways I can improve this site. When I built support for my coffee reviews, I added support for the h-review microformat. I enjoyed doing it. I took my work a step further and I learned a lot in the process. I didn’t need to be using Flask to learn what I learned. So, for now, I am going to stick with Jekyll.

I am somewhat tempted to place a bet with a friend that if I move to another generator I’ll have to give them $100 or something. I haven’t quite made my mind up on that one just yet.

  1. I do not want to admit how many times I have surfed the IndieWeb webring. It’s more than I can count. 

  2. I am still somewhat trying to convince myself not to take this further than it needs to go. What I have right now is fine. 

You have hit upon one of the great conundrums of the IndieWeb - everyone loves static sites until they want to do something dynamic 😄

I know you already moved off Next.js but I use that now, and it can actually be a mix of statically generated and dynamic content which works great for me.

The other thing to look into is basically fancy build steps. I don't really know if it is common in Jekyll, but in things like Gatsby and 11ty it is quite common to have a build step that pulls data from external sources, then new builds can be fired by webhooks.

Replied to https://v2.jacky.wtf/post/f1fb82cb-3c43-4ec7-81e8-4d2153d175b6

The only reason why I have Windows on this PC is for games and to be nosy about the progress of the Insider Preview (so much stuff in KDE/GNOME is popping up in Windows now!)I might, however, just throw it into a VM - attempting to run Python or Node on Windows is a joke. And terminal emulators are still very supbar. Even with the Windows Terminal preview.

The only reason why I have Windows on this PC is for games and to be nosy about the progress of the Insider Preview (so much stuff in KDE/GNOME is popping up in Windows now!)

I might, however, just throw it into a VM - attempting to run Python or Node on Windows is a joke. And terminal emulators are still very supbar. Even with the Windows Terminal preview.

Tried wsl2 yet? I've found it works with pretty much anything I've thrown at it. Only issue is the slow windows filesystem - but apparently it's way better if you use the specific wsl file system

Replied to https://fireburn.ru/posts/1585393501

Why a centralized Microsub server might be a good idea

Even though we have a lot of trouble with SPOA when @aaronpk breaks something accidentally, I think a centralized Microsub server could do some stuff that could be tricky to accomplish without it.

Centralized feed fetching

If one server fetches and sorts feeds for several people, we get a reduction of bandwidth for popular websites, which may be important in IndieWeb because some people like me host their sites on a low-power machines such as a Raspberry Pi.

Also we get some degree of anonymization for public feeds because feed is fetched only once without revealing the IP address of a person reading it - only the Microsub service owner’s IP is revealed.

Recommendation feeds

A Microsub server hosting several people’s feeds would be able to match categories that people are reading often and recommend blogs that post often with the same categories.

This one could be done with an external service too. It would also have the advantage of being able to work across Microsub servers, but may be not integrated so well.

The workflow I’ve envisioned requires a Microsub client that could subscribe you to a person by clicking on a button near their author card: 1. The user goes to a special “recommended” feed 2. The server gives them a preassembled feed of posts matching following criteria: author isn’t in any other feeds and the post tags are similar to tags appearing on the user’s feeds. 3. The user reads the feed and if they’re interested in a person, they click on their h-card and the reader prompts them to subscribe to this person.

Category feeds

A variation on the previous one: the user could subscribe to a category instead of a URL, and the server would be able to construct a feed of all posts it knows of with the same category.

This one, though, could also be replicated by syndication and external feed services.

This is actually pretty close to some ideas I had for a microsub "middleware".

With the way microsub is built it would be possible to generate recommendations and category feeds without a centralized server. You can create a "client" that can automatically read channels from any server and create feeds / modify existing items.

I already have a decent working example in removing like posts from a feed and sending them as a daily rollup instead at https://glitch.com/~microsub-middleware

With this middleware idea there is also no need for specialized servers and clients, it should all just kind of work (hopefully)

Replied to https://twitter.com/mxbck/status/1181196276962119680

Max B�ck on Twitter

Yeah there might be workarounds, and there is the idea of a micropub media endpoint for that sort of thing. But it doesn't feel as nice to have one part serverless and the other part not.

Replied to https://twitter.com/mxbck/status/1180885522601926656

Max B�ck on Twitter

People have at least thought about this, not sure if there are any working examples out there though.

A common problem people ran across was serverless functions enforcing a maximum post body size, so no real media posting.

Replied to https://adactio.com/notes/15860

September 25th, 2019, 4:21pm

Sitting by the square.

Sitting by the square.

CC Attribution   40° N , 4° E

Also on Twitter Flickr

Reply Retweet Favourite

Older »

# Liked by Nat'l Hispanic Heritage Month on Wednesday, September 25th, 2019 at 4:30pm

# Liked by Colin Howells on Wednesday, September 25th, 2019 at 4:30pm

# Liked by Daniel Burka on Wednesday, September 25th, 2019 at 4:30pm

# Liked by Barney Carroll in Brighton on Wednesday, September 25th, 2019 at 4:30pm

Oh hey, you're just down the road from where I live! Enjoy!

Replied to https://v2.jacky.wtf/post/c794aea6-a029-475c-86ce-f0113a90f1f0

I was going to try out BitWarden but I have to try to install a bunch of .NET stuff on docker which usually I’m not opposed to but I can’t be bothered to right now.

I was going to try out BitWarden but I have to try to install a bunch of .NET stuff on docker which usually I’m not opposed to but I can’t be bothered to right now.

Comments

https://mastodon.social/users/trwnh posted  •  received 2019-09-05T05:30:50.715Z

Try bitwarden_rs instead! I've been running that for a year or so and loving it.

Replied to https://mxb.dev/blog/indieweb-link-sharing/

IndieWeb Link Sharing

A pain point of the IndieWeb is that it's sometimes not as convenient to share content as it is on the common social media platforms.

Posting a new short “note” on my site currently requires me to commit a new markdown file to the repository on Github. That’s doable (for a developer), but not really convenient, especially when you’re on the go and just want to share a quick link. Twitter and other social media platforms literally make this as easy as clicking a single button, which makes it tempting to just post stuff straight to them. That’s why I wanted to improve this process for my site.

A quick Google search revealed that smarter people have already solved that problem. I came across this blog post by Tim Kadlec who describes adapting someone else’s link sharing technique for his (Hugo-powered) blog. That just left me the task of adapting it for my setup (Eleventy, Netlify) and customizing a few details.

The new link sharing basically has three main parts:

  • a small Javascript bookmarklet to act as a “share button”
  • a form that collects and sends the shared link data, and
  • a serverless function to process it and create a new file.

Here’s how they work together:

The Bookmarklet

The button to kick things off is just a small bit of Javascript that takes the current page’s title, URL and optionally a piece of selected text you may want to quote along with the link.

It then sends these things as GET parameters to mxb.dev/share by opening a new window to it.

function(){
// get link title
var title = document.getElementsByTagName('title')[0].innerHTML;
title = encodeURIComponent(title);

// get optional text selection
var selection = '';
if (window.getSelection) {
selection = window.getSelection().toString();
} else if (document.selection && document.selection.type != 'Control') {
selection = document.selection.createRange().text;
}
selection = encodeURIComponent(selection);

// generate share URL
var url = 'https://mxb.dev/share/?title='+title+'&body='+selection+'&url'+encodeURIComponent(document.location.href)

// open popup window to sharing form
window.open(url,'Sharer','resizable,scrollbars,status=0,toolbar=0,menubar=0,titlebar=0,width=680,height=700,location=0');
})()

That bookmarklet looks like this:
Share on MXB

…and can then be dragged to the bookmarks bar for quick access.

The Sharing Form

At mxb.dev/share, I’ve created a small preact app. It will take the GET params passed in via the URL and generate a live preview of the resulting note, so I know what the end product will look like.

There’s also a form that will be pre-populated with the values, which lets me include additional information and edit everything before posting.

The form also has fields for the Github username and security token, necessary for authentification. My password manager will fill those in automatically.

The sharing form with a live preview of the note

The Handler Script

When I hit the submit button, the form will send the data along to another endpoint. I’ve built a serverless function to handle the processing, so I could theoretically send data from other sources there too and keep the posting logic in one place. Netlify Functions seemed to be a nice fit for this.

Here’s the full script if you’re interested. It reads the posted data and generates a new markdown file from it, called something like 2019-08-11-amphora-ethan-marcotte.md:

---
title: "Amphora - Ethan Marcotte"
date: "2019-08-11T16:57:13.104Z"
syndicate: false
tags: link
---


...we've reached a point where AMP may "solve" the web's
performance issues by supercharging the web’s accessibility problem.
(via [@beep](https://twitter.com/beep))

[ethanmarcotte.com/wrote/amphora](https://ethanmarcotte.com/wrote/amphora/)

It will then use the Github API to post that file as a base64-encoded string to a predetermined location in the site’s repository (in my case the folder where I keep all my notes).

Here’s the core function responsible for that:

const postFile = async data => {
const { title, token } = data
const fileName = getFileName(title)
const fileContent = getFileContent(data)
const url = API_FILE_TARGET + fileName

const payload = {
message: 'new shared link',
content: Buffer.from(fileContent).toString('base64'),
committer: {
name: 'Max Böck',
email: 'hello@mxb.dev'
}
}

const options = {
method: 'PUT',
body: JSON.stringify(payload),
headers: {
'Content-Type': 'application/vnd.github.v3+json',
Authorization: `token ${token}`
}
}

return await fetch(url, options)
}

That’s pretty much it! After the file is committed, Netlify will kick in and re-build the static site with the new content. If I have marked the “syndicate to Twitter” flag, another script will then cross-post the link there. (More on that in Static Indieweb pt1: Syndicating Content).

Mobile Share Sheet

A caveat of this technique is the use on mobile. Javascript bookmarklets are not as easily available in mobile browsers, which complicates the process again.

Thankfully Aaron Gustafson recently pointed out that it’s possible to define a “Share Target” for Progressive Web Apps. That means if your site is a PWA (it probably should be), you can add an entry like this to its manifest file:

// site.webmanifest
{
...,
"share_target": {
"action": "/share/",
"method": "GET",
"enctype": "application/x-www-form-urlencoded",
"params": {
"title": "title",
"text": "text",
"url": "url"
}
}
}

That little bit of JSON registers your site as an application that can share things, just like Twitter, WhatsApp and the others. So after I “install” my PWA (read: create a shortcut link on my device home screen), it shows up as an option in the native Android “share” dialog:

PWA Share Sheet on Android
The "Max Böck" share option is available after installing the PWA.

Selecting the “MXB” option will grab the current page title and URL and send them as GET args to my sharing form, just like the bookmarklet would on desktop. There’s still a small bug in there where the URL will be sent as the text parameter, but that can be corrected with a bit of Javascript in the form app.

I’m quite happy with how this turned out, as it feels really simple and straightforward. One step closer to IndieWeb bliss!

Looks like you've come up with a nice solution that works for you 👍

You should check out micropub it's kind of a open specification for what you've already built, then you can use any micropub client to post to your own website!

Replied to https://twitter.com/Melophilus/status/1154375154044231680

Robin on Twitter

418 "I'm a teapot" of course! https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418