Music box repair

I was a bit stressed out earlier and needed a mini-project, so I picked up an old music box from grandma that hadn’t worked in over a decade.

I ultimately ended up taking the entire thing apart to get it working again properly. Nice to have a bit of a distraction.

Here’s a few photos of the Swiss Thorens No 26 1/2 Emmentalerlied Kuhreigen Vo Luzern uf Weggis zue along with a very up close audio that picks up the depth of the inner mechanics. The tune plays through twice before I let the mechanism stop itself.

Perhaps I’ll revisit the positioning of the pins to improve the sound, but at least it’s working again.

ThreadReaderApp now has beta support for the Micropub Spec so you can publish Twitter threads directly to your blog

So… a while back I tweeted about a bit of functionality I’ve long thought would be a cool one to have for Twitter:

I would often see people post tweetstorms, long threads of related tweets, to tell an extended story.

Invariably people see these threads and say “Why don’t/didn’t you just post that on your website as a blog post instead?”

(In fact, why don’t you try it on this very tweet?)

I’ve personally been using the #IndieWeb concept of P.O.S.S.E. (Post on your Own Site and Syndicate Elsewhere) for a while now. I’ll post my content on my personal website first and only then syndicate a copy to Twitter.
indieweb.org/POSSE

But today, for the first time in a very LONG time, I’m posting this particular thread to Twitter first…

Then when I’m done, I’ll roll it all up conveniently using the awesome @ThreadReaderApp which will put a nice readable version on their site.

Presto!

Blogpost, right??

Sadly, I don’t own that copy…

It really needs to be on my blog for that to work, right?!

“But wait. There’s more.” as they say in advertising.

Now with the help of @ThreadReaderApp, and the Micropub plugin for #WordPress, I’ll be able to view my thread on ThreadReader in a brand new bonus feature that’s currently in beta. Screencapture of ThreadReaderApp site featuring a button labeled

Yes, you guessed it! It’s that wondrous “Publish to Blog” button!!

With a quick click, @ThreadReaderApp will authenticate and I can authorize it to publish to my WordPress site on my behalf.

I can now publish the entire thread to my own website!!

Now this thread that I’ve published to Twitter will live forever archived on my own website as its own stand-alone blogpost.

Huzzah!!

I’m not sure how often I’m prone to do this in the future, but I hope we won’t hear that “Why didn’t you just post that on your own website as a blogpost?” as frequently.

With just a button push, I’ll be able to quickly and simply cross-post my Twitter threads on Twitter directly to my website!
#OwnYourData

In #IndieWeb terminology this publishing workflow is known as P.E.S.O.S. or Publish Elsewhere, Syndicate to Your Own Site.
indieweb.org/PESOS

I’ll mention for the masses that this publishing functionality is only possible courtesy of a W3C recommendation (aka web standard) known as Micropub.
indieweb.org/Micropub

Because it’s a web standard, @ThreadReaderApp can build the functionality once & it should work on dozens of platforms including @WordPress @Drupal @WithKnown @CraftCMS @Jekyllrb @GetKirby @GoHugoIO @MicroDotBlog among a growing set of others.
indieweb.org/Micropub/Serve…

Some of these may have built-in or core support for the standard while others may require a simple plugin or module to support this functionality.

Don’t see your platform supported yet? Ask your CMS or platform provider to provide direct support.

It shouldn’t take much work for @Ghost @grabaperch @squarespace @Wix @getgrav @magento @typo3 @Blogger @medium @Tumblr @mediawiki @omeka and others to support this too.

There’s lots of open source implementations already out there in various languages and there’s a fantastic test suite available for developers.

I’ll also give a quick shout out to @iAWriter which also just added Micropub support to let people use their editor to post to their websites.

And of course once you’ve realized that your platform supports Micropub to publish to your website, why not try out one of the dozens of other Micropub clients out there?
indieweb.org/Micropub/Clien…

They support a variety of post or content types from full articles to photos and geolocation to bookmarks. The sky’s the limit.

Some of my favorites are Quill, OwnYourSwarm, Omnibear, and Teacup. And let’s not forget social feed readers like Monocle and Indigenous that let you read and respond to content directly in your feed reader! (I no longer miss Google Reader, now I just feel sorry for them.)

Congratulations again to @ThreadReaderApp for helping to lead the way in the corporate social space for support of the awesomeness that Micropub allows.

Thread away!

Pantheon: A great resource of people and bibliographical data for PAO systems

When creating a Person-Action-Object (PAO) system, sometimes a major issue is having the creativity and perseverance of coming up with a strong repository of names, pictures, and other related data to use.

While doing some research today on collective learning I came across a really well-curated and research-grade system called Pantheon with a wealth of all the sorts of data one could possibly want when creating a PAO.

Naturally if you’re memorizing dates and places for other reasons, there’s a great wealth of data and some useful visualizations hiding in here as well. I suspect that some may find it useful for work with names and faces too.

A hack for using Hypothes.is to annotate on mobile

I do a fair amount of reading on my mobile phone and my addiction to Hypothes.is for annotating and highlighting what I read has finally driven me to the brink. I have typically added via.hypothes.is to the URLs of articles manually so I can use Hypothes.is on my phone. I’ve finally had enough of the manual timesuck that I’ve gone in search of an answer since there is not yet a mobile app solution.

I’ve long been an Android user, so I broke out the URL Forwarder app which uses the ubiquitous share functionality of most phone platforms and adds a thin layer of program-ability.

In short I created a new filter and cleverly named it “Hypothesize”. Then I added the filter url “http://via.hypothes.is/@url” and left the replaceable text alone. 

screenshot of URL Forwarder and settings for Hypothes.is

Now I can take an article from almost anywhere on my phone (reading services like Pocket, my feed readers, or even articles within the browser themselves), click share, choose “URL Forwarder” from the top of the list, select “Hypothesize” and the piece I want to annotate magically opens up with Hypothes.is ready to go in my default browser. Huzzah!

The three taps are ever so much easier than trying to tap a URL to edit it it and then typing. Why didn’t I think of this years ago?

Have you had this problem? Do you have a better solution or work around?

Thoughts on hosting an IndieWebCamp Pop-up Session

A few weeks back, I hosted a stand alone IndieWebCamp pop-up session. I had promised to scribble down some thoughts about the process and how it might be improved based on my experience. If anyone else has thoughts on how it went or how future events like this could be improved, I’d love to read them.

With traditional in-person two day camps on hold for the foreseeable future as the result of the coronavirus, doing some smaller one day or even one session topics seemed like a good idea at the time. After having done it once, I now think they’re an even better idea. A variety of things came out of the experience that I wouldn’t have anticipated.

Process

I posted the notice for the event to my website and to events.indieweb.org about two weeks in advance. This helped give me enough time to invite about 15 people I expected to be interested in the particular topic. A few tweets as reminders helped in addition to the announcement being early enough to make it into two of the IndieWeb newsletters.

I held the session at 10am Pacific so that we might be able to draw people from the late evening time zones in Europe, mid-afternoon people on the East coast of the U.S. but still late enough in the morning so that people on the West coast of America wouldn’t have to be up too early. This seems to have worked out well though I feel bad that we did likely shortchange several people in India, Asia, and Australia who might have attended.

I expected that I would be starting out small and simple and honestly only expected about 3-6 people to show up. I was initially thinking a tiny, one-topic Homebrew Website Club, but on a weekend.

On the day of the event my guess was that we had about 25 attendees, but statistics after the fact showed that 35 people logged into the session. There were still people arriving into the room at the two hour mark! According to the numbers, there have already been 210+ views of the archived video since it was posted later on the day of the event.

I suppose that future sessions will give additional data to bear the hypothesis out, but one of the side-benefits of having a specific topic announced a few weeks in advance seemed to have brought in a large number of people interested in the particular topic and who were generally unaware of the IndieWeb as a group or a movement. I’ve seen several of these people at subsequent Homebrew Website Club meetups, so using these sessions to help spread the principles of IndieWeb does seem to have been generally useful. About half of the attendees hadn’t been to an IndieWeb event previously. I did try to start with a brief introduction to IndieWeb at the start of the session and offered some follow up at the end, but I probably could have planned for this better.

I wish I had collected people’s emails, but I’ll have to do this manually somehow if we do so now. The traditional signup and organization structure for full camps would have done this, but it would be nice to have a simple workflow for doing this on a lower key basis for pop-ups. Emails would also have helped to put together a post-event questionnaire to potentially create a follow up session.

Thanks certainly goes to all the people who have built pre-existing infrastructure and patterns for pulling off such an event so easily.

Wiki Infrastructure

Since the session, I’ve gone into the IndieWeb wiki and created a stub pseudo-IndieWebCamp listing to help make organizing future stand-alone pop-up sessions a bit easier (particularly for documenting the results after-the-fact.)

The key is to make doing these as easy as possible from an organization standpoint. Having pre-existing pages on the wiki seems to help a lot (or at least feels like it from a mental baggage perspective).

Here are the relevant pages:

Execution

One of the things that was generally missing from the program was some of the hallway chatter and getting-to-know-you preliminary conversation. I think if I were doing another session I’d schedule 15 minutes of preliminary chat and dedicate about 30 minutes of introduction time into the process and encourage people to have a cup of coffee or drink to help make the atmosphere a bit more casual and conversational.

On thing that surprised me was that despite scheduling about an hours’ worth of time to the session we still had a sizeable crowd talking about the topic nearly two hours later. I think having more than just the traditional hour of conversation at a camp was awesome. It helped us not only dig in a bit deeper into the topic, but also helped in managing things given the larger number of attendees over the usual camp setting where 5-15 session attendees has been the norm. Doing it again, I might outline a three hour mini-event to allow covering a bit more material but still keeping things small and relatively casual.

I certainly benefited by the presence of a few old hands in the IndieWeb community showing up and helping out on the day of, particularly in terms of helping to manage Zoom infrastructure and format. A single person could certainly plan and execute a pop-up session, but I would highly recommend that at least two people show up to co-host on the day of the event, especially if the attendance goes over 10 people. 

The IndieWeb Zoom set up prevents organizers from allowing users to share their screens during a session. (This issue has popped up in a few HWCs lately too.)  This was potentially helpful in the earlier days when it was easier for zoombombers to pop into rooms and disrupt a conversation. There have been enough changes to Zoom with precautions built in that this part of the lock down probably isn’t needed any longer, particularly given how useful screen sharing can be.

Despite having many places to indicate RSVP’s I had very little indication of how many would show up. Something to improve this would be nice in the future, though isn’t necessarily mission critical.

I’ve definitely experienced the organizer decompression time required after putting together something big. I feel like there was less of the traditional post-event stress for this one session which allowed me to focus more of my time and attention after-the-fact on the content of the session and getting some work relating to it done. For me at least, I consider this a big personal win.

Create day/time

Traditional camps set aside day two for people to create something related to the session(s) they attended on day one. We didn’t do that for this session ahead of time, but I desperately wish we had created a better space for doing that somehow. Later on the afternoon of the session, I posted a note encouraging people to write, create, or do something tangible. I wish I had created a specific time for either the following day (or even a week later) for everyone to reconvene and do a short demo session as a follow up.

Simply having a blog section and demo page on the wiki did help encourage people to write, blog, and continue thinking and working on the session topic afterwards.

Concentration

One of the things I’ve appreciated since the session is the level of conversation in the general IndieWeb chat rooms, on people’s blogs, and peppered around Twitter and Mastodon. Often when couched into a larger IndieWebCamp there are so many sessions and conversations, the individual topics can seem to be lost in all the hubbub. Fifteen sessions concentrated on one weekend is incredibly invigorating, but because all of the concentration was on just a single topic, there was a lot more focus and energy spent on just that one thing. I sort of feel like this concentration has helped to carry over in the intervening time because I haven’t been as distracted by the thirty other competing things I’d like to work on with respect to my website since.

There has been a lot of specific article writing about this one session as some camps get in entirety.

Perhaps pop-up sessions on broader topics and problems that haven’t had as much work or which have only one or two small examples may benefit from this sort of concentrated work by several people.

I do wonder what may have happened if we had had a broad conversation about the top level topic for an hour and a half and then broken into smaller groups for 45 minutes to talk about sub-topics?

Conclusions

In the end, the session went far better than I ever expected for the amount of time I invested into it. I definitely encourage others to try to put together similar sessions. They’re simple and easy enough to be organized by one person and they can be carried out by one person, though I’d recommend two.

I encourage others to suggest topics and set up other sessions.

Even if you’re not interested in the organization portion, why not propose a topic? Perhaps someone else with a more organizational bent will come along and help you make it happen?

I’m happy, as always, to help people plan them out and deal with some of the logistics (Zoom, Etherpad, wiki, etc.) should anyone need it.

What session topic(s) will you propose for the next one?

Thoughts on Wikity for WordPress

I spun up a new instance of Wikity today at http://wikity.chrisaldrich.net/ to test it out for potential use as a personal online wiki. My goal was also to test out how it may or may not work with IndieWeb-based WordPress pieces too.

Below are my initial thoughts and problems.

The /home/ page has a lot of errors and warnings. (Never a good sign.)

It took me a few minutes to figure out where the Wik-it! bookmarklet button was hiding. Ideally it would have been in the start card that described how the bookmarklet would work (in addition to its original spot).

The Wikity theme seems to have some issues when using for http vs. https.

  • Less seems to work out of the box with https
  • The main card for entering “Name of Concept or Data” didn’t work at all under https. It only showed the title and wouldn’t save. Switching to http seemed to fix it and show the editor bar.

I’ve tried copying over from Aaron DavisWikity instance, but the cardbox seems to fail on my end.

  • Nothing seemed to work at all when I had my site as https. In fact, it redirected to a URL that seemed like it wanted to run update.php for some bizarre reason.
  • On http I at least get a card saying that the process failed.
    • Not sure what may be causing this.
    • Doesn’t seem to matter how many cards it is.
    • Perhaps it’s the fact that Aaron’s site is https? I notice that his checkbox export functionality duplicates his entire URL including the https:// within the export box which seems to automatically prepend http://
    • Copying to my own wiki seems to vaguely work using http, but failed on https.

Multiple * in the markdown editor functionality within WordPress doesn’t seem to format the way I’d expect.

Sadly, the original Wikity.cc site is down, but the theme still includes a link to it front and center on my website.

The home screen quick new card has some wonky CSS that off centers it.

Toggling full screen editing mode in new cards from the home screen makes them too big and obscures the UI making things unusable.

The primary multi-card home display doesn’t work well with markup the way the individual posts do.

The custom theme seems to be hiding some of the IndieWeb pieces. It may also be hampering the issuance of webmention as I tried sending one to myself and it only showed up as a pingback. It didn’t feel worth the effort to give the system a full IndieWeb test drive beyond this.

Doing this set up as a theme and leveraging posts seems like a very odd choice. From my reading, Mike Caulfield was relatively new to WordPress development when he made this. Even if he was an intermediate developer, he should be proud of his effort, including his attention to some minute bits of UI that others wouldn’t have considered. To make this a more ubiquitous solution, it may have been a better choice to create it as a plugin, do a custom post type for wiki cards and create a separate section of the database for them instead of trying to leverage posts. This way it could have been installed on any pre-existing WordPress install and the user could choose their own favorite theme and still have a wiki built into it. In this incarnation it’s really only meant to be installed on a fresh stand-alone site.

I only used the Classic Editor and didn’t even open up the Gutenberg box of worms in any of my tests.

Summary

The Wikity theme hasn’t been maintained in four years and it looks like it’s going to take quite a bit of work (or a complete refactoring) to make it operate the way I’d want it to. Given the general conceptualization it may make much more sense to try to find a better maintained solution for a wiki.

The overarching idea of what he was trying to accomplish, particularly within the education space and the OER space, was awesome. I would love nothing more than to have wiki-like functionality built into my personal WordPress website, particularly if I could have different presentations for the two sides but still maintain public/private versions of pieces and still have site-wide tagging and search. Having the ability to port data from site to site is a particularly awesome idea.

Is anyone actively still using it? I’d love to hear others’ thoughts about problems/issues they’ve seen. Is it still working for you as expected? Is it worth upgrading the broken bits? Is it worth refactoring into a standalone plugin?

ONLINE: Homebrew Website Club West Coast on May 13, 2020

Working on your website? Want some camaraderie? Need ideas about what you could build next? Want to share what you’ve built with others? I’m hosting next week’s meetup on Wednesday. Come and join the fun!

May 13, 2020
Wed 6:00 – 7:30pm (America/Los_Angeles)

Join the Zoom call

We will provide a Zoom video conference link 20-30 minutes before the meetup here and in the IndieWeb chat. Here’s the link: https://us02web.zoom.us/j/85315852710?pwd=OGlSSTQxV1A3blVmR2Y3R21XOW1FZz09


Homebrew Website Club is a meetup for anyone interested in personal websites and a distributed web. Whether you’re a blogger, coder, designer, or just someone who wants to improve their presence on the web, this meetup is for you.

  • Demos of personal website breakthroughs
  • Discussion around the independent web
  • Get to know other members of the IndieWeb!
  • Create or update your personal web site!
  • Finish that blog post you’ve been working on!

Join a community with like-minded interests. Bring friends that want a personal site, or are interested in a healthy, independent web!

RSVP (optional)

If your website supports it, post an indie RSVP. Or simply post a comment below. If none of that means anything to you, don’t worry about it; just show up!

Now weekly!

Check https://events.indieweb.org for next week’s meetup! There are some meetups in European and US Eastern timezones as well.

Displaying Webmentions on TiddlyWiki

I’ve previously written about setting up receiving Webmention for TiddlyWiki by logging into webmention.io and creating an account to delegate the receipt of the notifications.
 
Naturally, these notifications can be more fun for cross-site conversations if one has the ability to display the webmentions on the posts to which they relate. There are probably a number of ways of doing this, but following the TiddlyWiki advice of keeping Tiddlers as small as possible, it seemed like creating a tiddler for the response and then transcluding or embedding it into the original would be the best course of action.
 
At the recent Gardens and Streams: Wikis, Blogs, and UI—a pop up IndieWebCamp session there was some discussion on internal bi-directional linking in wikis, but I thought it would also be fun to show off bi-directional linking between my wiki and other websites. To do that will require displaying at least some Webmentions.
My wiki currently doesn’t have very many webmentions or incoming links, but after writing about a Bookmarklet for pasting content into TiddlyWiki, I got an email from Anne-Laure Le Cunff that she’d used some of the code to write a bookmarklet for Roam Research. Since her article didn’t send a webmention, I used Telegraph to manually force her article to send my wiki a Webmention so my account would have a record of it for the future for potential exporting or other use.
Now I’d like to display this webmention on that tiddler. Doing it automatically would be great, but I thought, since I don’t expect to receive many on my wiki that I ought to try out a manual set up to see how things might work and how I might display them if they were automated.
Since I had created that bookmarklet, I used it to copy and paste the text from Anne-Laure Le Cunff‘s website into a new tiddler. I then massaged it a bit to format it to look like a response and I’ve transcluded it into the original post under a heading of Responses.
The side benefit of doing this is that the stand alone tiddler that has the link and the context from her post also sits in my wiki as a bookmark of her post as well. As a result, I get a two-for-one deal: I get the bookmark of her post with some context I’m interested in, but my original post can now also display it as a response! Now I can also use that bookmark in other places in my website as well. If only one could do this so easily in other CMSes?!
I’ve yet to hear of another example of this in the wild, so unless I’m missing something, this may be the first displayed Webmention on a TiddlyWiki in the wild.

Next steps

Data formats

TiddlyWiki has lots of ways to display data in Tiddlers, so perhaps one might use various fields in a bookmark tiddler to create the necessary comment display. This could give a more standardized method of displaying them as well. It could be particularly useful if someone was using a microformats parser to import the data of such mentions. If this were the case, then the tiddler that is being commented on could do a filter/search for all tiddlers in the wiki that mention it and transclude the appropriate pieces in a list format with the appropriate mark up as well as links back to the individual tiddlers and/or the links to the sending site.
I’m curious if others have ideas about how to best/easiest implement the display portion of webmentions on a public TiddlyWiki? Since I’m also hosting my entire TiddlyWiki on GitHub pages, there might be other potential considerations if I were to be hosting it statically instead. This may require some experimentation.
I’ve got a few mental models about how one might implement showing Webmentions in TiddlyWiki, but it may take some more thinking to figure out which way may be the best or most efficient.

Automation

I don’t anticipate a lot of incoming webmentions to my wiki at present, but if they become more prevalent, I’ll want to automate the display of these notifications somehow. This will take some thought and coding as well as more knowledge of the internals of TiddlyWiki than I’ve currently got. If someone with the coding chops is interested, I could probably brainstorm a set up fairly quickly.

Microformats

It would also be nice to be able to have full microformats support in TiddlyWiki so that the stand alone “bookmark” mention works properly, but also so that the transcluded version might have the correct mark up. This may rely on the two things to be properly nested to make them work in both contexts.

A short post mortem, video and note links, and challenge from The Garden and the Stream IndieWebCamp Pop-up session

Thank you everyone!

For those who attended yesterday’s The Garden and the Stream IndieWebCamp session, thank you for participating! I honestly only expected 4 or 5 wiki fans to show up, so I was overwhelmed with the crowd that magically appeared from across multiple countries and timezones.

I’ve heard from many–both during the session and privately after–that it was a fantastic and wide-ranging conversation. (I never suspected memory palaces or my favorite 13th century Franciscan tertiary to be topics of discussion.) Several have suggested we host not only a continuation of the session, but that they’d be interested in other pop-up IndieWebCamp sessions. If you’re interested in future follow ups or sessions shoot me a quick email (you can find it on my home page) and I’ll be sure you get an invite. You can also follow future events via events.indieweb.org or find them in the IndieWeb’s weekly newsletter that is emailed out every Friday afternoon.

If you’re interested in hosting or suggesting other topics for future sessions, there’s a stub page on the IndieWeb wiki for doing so.

Our session went on far longer than I ever could have anticipated and I suspect we could have easily gone all day and still not touched on a fraction of all the topics we all outlined. Special thanks to the larger majority of those who were interested enough and had the free time to stay well past the hour mark and on to the end. I will say it’s nice to be able to cover so much ground and so many ideas without the threat of 5 more sessions following you.

Video and Notes

For those who missed it and are interested or those who have inquired, the video link and the notes from the session have been posted to the IndieWeb wiki. 

If you write up any notes or posts about the session, do add a link to them in the IndieWebCamp Pop-Ups page under blog posts/articles or photos. If you can’t log into the wiki (with your own website), feel free to ping me with the URL and I’ll add them for you.

I’ll  try to write up an organizer’s post-mortem with a few ideas about doing future sessions for others to consider. I hope to rewatch the session myself and add to the growing list of notes and thoughts about it.

Creators Challenge

Because this was just a single IndieWebCamp-style discussion session and we hadn’t specifically planned a traditional creator’s day or hack day, I did want to throw out a small challenge to those who either attended or who are interested in participating. 

For most, the IndieWeb is more about creating something than just talking about it. So in that spirit, I’ll challenge everyone to spend a few hours today/tomorrow or sometime this week and create something on your website or wiki related to the session. It can be a summary of ideas, a blog post about wikis (or anything you like really), a small change you’ve always wanted on your site (a CSS improvement, adding bi-directional links to your wiki, Webmention support, etc.), or anything else you might have found interesting from the conversation. The best part is that you can choose what you create on your own site! Make something you’ll use or appreciate. Have fun!

My personal plan for the challenge is to continue some work to my TiddlyWiki to support bi-directional links using TiddlyBlink. I might also take a crack at doing some design and building work to show some incoming webmentions on my TiddlyWiki. (If anyone is interested in test-driving Mike Caulfield’s implementation of Wikity on WordPress in conjunction with Webmention, I could be game for that too!)

Once you’ve made your creation, post a link to your article or notes or make a quick 2-3 minute demo video of the new feature or write up a post about it and add them to the IndieWeb wiki page for Pop-up Session Demos. Again if you can’t log into the wiki with your own website yet, drop me a note and I’ll add them for you or you can ask for help on how to do it in the IndieWeb chat.

Thanks again everyone! I look forward to seeing what you come up with.


cc: Kailyn Nelson (t), Phil Jones (t), Brian Sholis, Jack Baty

Link between Lullism and the Jesuits’ descent into the particular

While reading The Art of Memory by Frances Yates, I ran across the phrase “descending from ‘generals’ to ‘specials'”and it reminded me of the Jesuit idea of “descending into the particular”.

Yates indicates, I think rightly, that this is:

a notion implicit in Lullism as it ascends and descends on the ladder of being [scala naturae] from specials to generals and from generals to specials. This terminology is specifically used of memory in Lull’s Liber ad memoriam confirmandam in which it is stated that memory is to be divided into specials and generals, the specials descending from the generals.

This seems like it is very closely associated with the Jesuit’s concept of “descending into the particular” (or the specials) within their teaching on thinking. (For those unfamiliar, I recall that Malcolm Gladwell has an interesting podcast episode within Revisionist History on this area of moral reasoning.)

Given that Raymond Lull (c. 1232 – c. 1315) has significant philosophical and religious sway in his lifetime, it is highly likely that the Jesuits (founded 1535) may have picked up the foundation of the concept from him. Yates writes this section in Chapter X, in relation to the ideas of memory with respect to Lullism which assuredly influenced Peter Ramus (1515-1572) and his ideas of memory.

I can’t help but think about why the Jesuits didn’t also include the idea of ascension into their philosophy? Perhaps some additional research into the topic will reveal some more direct associations. I think Yates’ link between Lullism and Ramism are pretty solid. I’d like to see some more direct evidence between Lullism and the Jesuits. I’d love to delve into the use of the art of memory within the Jesuit tradition as well.

The scala naturae or great chain of being has had a profound effect (not necessarily a positive one) on religion and modern culture. Far too many people are completely ignorant of what it is or what it entails, yet it underpins a huge swath of Western thought.

Miniature in an illuminated manuscript of Raymond Lull next to a ladder indicating the the levels of being
Scala Naturae or Ladder of Being in Breviculum ex artibus Raimundi Lulli electum – St. Peter perg. 92 [page 13 (5r)]

Gardens and Streams: Wikis, Blogs, and UI—a pop up IndieWebCamp session

There has been some sporadic conversation about doing impromptu IndieWebCamp sessions and thus far we’ve yet to organize one. Given our physical distancing and the dearth of bigger IndieWebCamps, I thought I would propose this single topic stand alone camp session to get something rolling. I’d invite others to propose and schedule others in the future.

April 25, 2020
Sat 10:00 – 11:00am (America/Los_Angeles)
Meeting ID: 950-1243-4695
Meeting Password: 021089
This is an online only event. We will provide a Zoom video conference link 30 minutes before the session here and in the IndieWeb chat.

Session Topic

We’ll be discussing and brainstorming ideas related to wikis and the IndieWeb, user interfaces, functionalities, examples of wikis and how they differ from blogs and other social media interfaces, and everyones’ ideas surrounding these. Bring your ideas and let’s discuss.

This is just a single one hour IndieWebCamp-like session (though we have the option to go over a bit since there isn’t a session following us) where we’ll brainstorm and discuss a particular topic. Hopefully the weekend time will be convenient for a wide range of people in Europe and North America who have previously shown interest in the topic. Everyone is welcome to attend.

Resources

To prepare for the session we’ll be using the following:

See also: https://indieweb.org/IndieWebCamps/Attending#Technology
This event is covered by the IndieWeb Code of Conduct. By participating, you’re acknowledging your acceptance of this code.

Questions? Concerns?

Feel free to ask in the IndieWeb chat: https://chat.indieweb.org/indieweb/

RSVP (optional)

If your website supports it, post an indie RSVP. Or, log in to indieweb.org and click “I’m Going”. (And if none of that means anything to you, don’t worry about it; just show up!)

Webmention for TiddlyWiki to enable website to website notifications and communication

What is a Webmention?

Webmention is a relatively recent web standard (or W3C recommendation) that allows notifications when one website mentions a URL on another website. Think of it like @mentions on social platforms, but instead of just working within a particular website from one account to another, they work across websites. Your website can now @mention my website!

For those who are interested in delving deeper into the idea and its implications, I’ve written a primer in the past : Webmentions: Enabling Better Communication on the Internet.

The goal is for other websites to be able to reference content in my TiddlyWiki website, and if those websites support sending the notifications as either webmentions (or the older pingbacks), I’ll get a notification that my content was referenced elsewhere on the web. This is just the beginning of allowing two way communication between websites.

My exploration today is how to quickly get these up and running on a public TiddlyWiki instance. The public part is important because webmentions won’t work for non-public URLs which includes private TiddlyWikis. If you’re wondering how to self-host a TiddlyWiki on your own domain, I’ve recently written up a tutorial for doing just that. At the end of this article, I’ll make a few notes about how one might use webmentions, particularly in a TiddlyWiki ecosystem.

I’ll start out by saying that writing a full JavaScript implementation of the Webmention spec is beyond my capabilities presently, but it could be something that TiddlyWiki core might implement in the future. (Maybe something like Lazymention which is written in node.js might be leveraged?)

Here I’m going to focus on using a third party service to do all of the heavy lifting and code our behalf. It’s relatively common, especially in the static website space, for websites to rely on third party or publisher services to either send or receive Webmentions on their behalf. Given my current knowledge of TiddlyWiki and how its internals work and my knowledge of Webmention services, I thought it would be quickest and easiest to look at using the Webmention.io service to handle receiving these @mentions from other sites on my behalf.

While this article may seem long, I’m hoping it’s detailed enough for those who are code averse to follow the recipe and do this themselves. If you can create a Tiddler, cut and paste some text, and follow the tutorial you won’t need to know anything about code. I did the entire thing myself in about five minutes from start to finish.

Receiving Webmention notifications for your TiddlyWiki

As a quick overview, we’re going to cut and paste a few lines of code into a special tiddler of our TiddlyWiki based website. This will allow us to do two things:

  1. Log into Webmention.io to create an account
  2. Allow other sites that send webmentions to us to find an endpoint on our TiddlyWiki website that accepts them on our behalf.

We’ll then rely on the Webmention.io dashboard to show us our notifications or received webmentions.

Logging into Webmention.io

Webmention.io requires you to log in with your domain name/URL and relies on you being able to authenticate yourself using it. Since I’m not aware of an IndieAuth or equivalent mechanism for using TiddlyWiki to log into Webmention.io, the quickest method to accomplish this is to rely on RelMeAuth using IndieAuth.com to log into Webmention.io using either a Twitter or GitHub account. From a non-technical perspective, we’ll be using either our Twitter or GitHub account and it’s OAuth2 security to log into the service.

First we want to put a link to our public TiddlyWiki website into the website field on either Twitter or GitHub using the profile settings of one of those services. Here’s what mine looks like on GitHub:

Screenshot of my GitHub accounts details featuring a link to my website

Next we want to place a corresponding link to the relevant service into the <head> of our TiddlyWiki site using one (it’s okay to use both) of the the following lines of code:

<link rel="me" href="https://twitter.com/username" />
<link rel="me" href="https://github.com/username" />

where you will replace the username in these links with the respective usernames of your accounts. (I’ll note that you don’t need to do this for both accounts, you can use either Twitter or GitHub.)

To place these lines into the appropriate location on your TiddlyWiki, you’ll want to create a tiddler with a name like $:/plugins/indieweb/core/rawMarkup and the tag $:/tags/RawMarkup.

Then cut and paste one or both of these links as appropriate into this tiddler and save it (and your TiddlyWiki).

You should now be able to go to webmention.io and enter the URL for your TiddlyWiki into the web sign in box and click “sign in”. The service will parse your website’s page, find the link to either Twitter or GitHub and present you with the appropriate sign in button for one or both of those services. Click on the button for your chosen service. IndieAuth.com will then take you to that service to log into it, or, if you’re already logged in, it will take you back to webmention.io to your new account.

Creating your Webmention endpoint

Within webmention.io you can now go to the “settings” page which will give you two more links which are your webmention and pingback endpoints. They will look something like this:

<link rel="webmention" href="https://webmention.io/example.com/webmention" />
<link rel="pingback" href="https://webmention.io/example.com/xmlrpc" />

where example.com will be replaced with the URL for your website.

Now you should cut and paste these two <link>s into the same tiddler you created above: $:/plugins/indieweb/core/rawMarkup. Now save the Tiddler and your TiddlyWiki. (Be sure to leave the previous links in case you need to log back into webmention.io in the future.)

You’re done!

That hopefully wasn’t too hard.

But what does this do? When another website links to your website and sends you a notification, the code on your page will delegate the receipt of the webmention to webmention.io which will verify that the sending site has your URL on a publicly viewable page (this helps to cut down on spam problems that pingbacks used to have). It will then store the notification for you.

If you need a reminder to check them occasionally, maybe you could add a Tiddler with the link to your dashboard to appear on your wiki when you open it next.

Perhaps in a future tutorial I’ll delve into the specifics of actually showing these mentions directly within your TiddlyWiki on the Tiddlers to which they relate.

Optional Webmention badge

Some may notice that I’ve put a small Webmention badge into the footer of my TiddlyWiki site to visually indicate to human readers that the site accepts webmentions. You can optionally do this for fun if you’d like.

Sending Webmentions with TiddlyWiki

Sending Webmentions seems to be an issue as the fragment-based URLs that TiddlyWiki uses as permalinks using JavaScript seem to cause an issue with many receivers. They apparently have problems resolving and parsing pages due to js;dr related issues. I would send webmentions manually, but most receivers I’m aware of have this js;dr problem. I’m not sure if there is an easy way around this issue.

Hyperchats, Wikis, and Open Educational Resources

What’s interesting about supporting Webmention, particularly from a TiddlyWiki perspective, is that if my TiddlyWiki is notified of mentions of it from outside sources, I can quickly cut and paste those responses directly into my Wiki pages in a pseudo-comment section similar to the comments section on this post which could serve as a model. If those mentions of a particular Tiddler are from other TiddlyWikis, I could also choose to drag-and-drop (or import) them into my TiddlyWiki!

If I want to go a step further, I could transclude those imported Tiddlers into the Tiddler that they’re in reference to. Perhaps I might do this under a heading of “@mentions” or perhaps “Comments” and suddenly I’ve got a way of displaying two-way conversations on my own TiddlyWiki site.

As is mentioned in Kicks Condor’s post about Hyperchat Modality, one could potentially use custom theming information (cleverly named “whostyles” in that post) from imported Tiddlers (or themes from other platforms) to identify the web identities of the sites they’re received from. I’ll also mention Kicks’ post about Hypertexting which is related and forms an interesting melange of websites, blogs, wikis, and hypertext of all kinds to form a more interesting web medium.

For the broader information collecting and building or academic communities (and here I can’t help thinking about the Open Educational Resources space that uses Creative Commons licensing to build their teaching resources), one could use these webmentions as a means of notifying sites that their content has been used, changed, or updated (typically those using Creative Commons will credit their source using a link). Then the receiver of the notification could optionally add to or change their version or even just collect the changes. This becomes particularly useful when the Tiddlers can be easily dragged and dropped between TiddyWikis!

As an explicit example, imagine a professor who wanted to build a textbook anthology, but who could do so by dragging and dropping a variety of Tiddlers from one site to another to create a quick textbook or reader for their students. This idea is particularly exciting to me when combined with the idea behind TW5-powered ebooks!

What could you imagine doing with webmention notifications on your TiddlyWiki site?

An h-card for my TiddlyWiki

I’m still spending lots of time trying to figure out how TiddlyWiki works, so some of this may seem hack-y, but it seems to get the job done. I’d love it if others who are using their TiddlyWikis as their primary website (and who have more experience than I) weighed in with their expertise or experience.

One of the core IndieWeb building blocks is having an h-card on your website to establish one’s identity, either for others to read or for computers and parsers to know who you are.

A valiant first attempt

To start out, I created an About Tiddler with the appropriate h-card and other microformats mark up and then put it into a tab in my right sidebar to make it easy to find.

Naturally, I ran into a problem when trying to throw this into indiewebify.me. Since TiddlyWiki websites are generated primarily by JavaScript and thus suffer from the js;dr problem, figuring out where to put and display an h-card was going to be an issue. I even tried throwing it into the Site Title in the control panel and hoped for the best, but in the end, the site title is really the shadow Tiddler $:/SiteTitle and like all the rest of the page is generated by JavaScript.

I muddled around a bit and even tried to add an h-card using a <link> in the <head>, but nothing seemed to work.

A hackable solution?

Ultimately, in frustration, I simply threw a simple h-card into the <head> just to see what would happen. It wasn’t terrible—the parser found it and displayed it as a success. Unfortunately I discovered that TiddlyWiki displayed my photo and name at the bottom of my page in the browser. I didn’t expect this, but at least it was a start.

Since this method seemed to work, I thought I’d continue the cheat and just throw in some in-line CSS so that the muddled h-card wouldn’t actually show on my page. I’d use this coded h-card in my <head> for computers and keep the somewhat more elaborate one for people in my about page.

What I did

So, for those who’d like the entirety of the solution, here’s what I did:

  1. I created a plugin tiddler entitled $:/plugins/indieweb/core/rawMarkup and gave it the tag $:/tags/RawMarkup
  2. I added the following lines of code to it and saved the Tiddler
    1. <a style="display:none" class="h-card u-url" href="http://tw.boffosocko.com/">
      <img src="https://www.boffosocko.com/logo.jpg" alt="" style="display:none" />Chris Aldrich</a>
  3. Profit!

Again, this works, but seems very hack-y to me. If you’ve managed to get a h-card into your TiddlyWiki in a different or more elegant way, I’d love to hear your thoughts.

Thoughts on delegated h-cards

Given the difficulty and trouble of all this, I’m sort of left wondering why–particularly since I’m using this site as a secondary one to my primary site–I couldn’t just throw in a link to the h-card for my primary site and call it a day? Unless I’m missing something, for some reason the way that representative h-cards are defined, they expect the h-card to point to the site they’re actually on.

Why couldn’t/shouldn’t I delegate my h-card on subdomains or other personal sites to point to the representative h-card on my primary site? What if parsers could follow other rel=”me” links on my site to find/intuit a representative h-card from one of those? While I could have lots of domains to better differentiate my online identity, why couldn’t I do that, but still have the same primary identity?

Self-hosting TiddlyWiki with GitHub Pages

TiddlyWiki is most often used as a private wiki for personal note taking and creating private journals.

Because it is a single text file usually named index.html written in HTML, CSS and some JavaScript, I thought it would make an ideal candidate for a simple-to-use personal website that can be hosted on one’s own domain. As a researcher who appreciates the IndieWeb and Domain of One’s Own philosophies and uses my personal website as a commonplace book for both work and personal reasons, how could I resist?

TiddlyWiki

TiddlyWiki is easy to use, highly flexible, modifiable, and can be easily copied, backed up, and shared. There’s an active community of users and developers for the platform which dates back to 2004. There are a variety of examples and documentation online and plugins are literally as simple as dragging and dropping some files from one source directly into your own Wiki. For those interested in the OER movement, individual Tiddlers (TiddlyWiki’s name for cards or discrete entries within the wiki) can be easily dragged and dropped from other TiddlyWikis to copy them!

There are some useful instructions for hosting it almost everywhere–except on one’s own domain name.

The few easy options I’ve found for hosting a TiddlyWiki publicly online as a website were rely on someone else’s service as a subdomain. As much as I like the idea of TiddlySpot I really wanted to use my own domain name (not to mention that it’s non-obvious how to host a newer TiddlyWiki version 5 (TW5) instance there). I’d also seen TiddlySpace shut down a few years ago and didn’t want to deal with that potentiality—though I will admit that exporting would be as simple as downloading and moving a single file!

So after a month or so at tinkering around at several complicated solutions that always seemed beyond my grasp, I went back to IndieWeb basics. What is their recommendation for the easiest way to get a website up and running? The fact that an empty TiddlyWiki file is named index.html gave me my answer: set up a GitHub Pages-based website and simply connect it to my domain!

However, as simple as this pathway may seem to some, I thought I’d briefly document the process I took so others can do the same for themselves.

First I’ll presume you’ve got a domain name and a host that will allow you to change the CNAME for where your domain name is pointed. (If you don’t, check out https://indieweb.org/personal-domain for details.)

In short, you’re going to upload a single file to your GitHub account and then point your domain name at it.

The idea of GitHub may scare a lot of people, but you won’t need to use git, know any git commands, or even know how git works since I’ll describe steps that entirely use the graphical user interface and don’t come anywhere near using the command line or any complicated GitHub applications. It’ll be as easy as dragging and dropping.

Let’s start!

Step-by-Step Tutorial

Get TiddlyWiki

  • Go to https://tiddlywiki.com/ and click on the “Download Empty” button on their homepage. This will allow you to save a file called index.html to a convenient place on your computer.
  • This one file is the entirety of your future website! Guard it well.

GitHub

  • If you don’t already have one, create an account at https://github.com/
    • You’ll use this account and their free GitHub Pages service to host your website for free as long as the project folder (also known as a repository) you are hosting is public.
  • At GitHub create a new repository.
    • Name it username.github.io, where username is your username (or organization name if you’re doing it for your organization) on GitHub.
    • Give your repository an optional descriptive name. I named mine “A TiddlyWiki commonplace book”
    • Choose the “Public” option, otherwise no one will be able to visit your new website.
    • Click “Create Repository”
  • Upload your TiddlyWiki to your new repository
    • In the Quick Set Up box click on the link for “uploading an existing file”.
    • On the subsequent page you can either drag and drop the empty TiddlyWiki index.html file you saved on your computer or you can click “choose your files” to find and upload the file.
    • If you like, you can optionally add any additional README, License, or gitignore files as necessary. If you don’t know what these are you can safely skip them or revisit doing this later.
    • Under “Commit changes” give your upload a short title; the suggested “Add files via upload” is fine. You can add an optional extended description if you like.
    • Click on the “Commit Changes” button.
      • P.S.: If you haven’t done so before you’ve just made your first Git commit. Congratulations!!
    • Your https://github.com/username/username.github.io repository folder should now be ready and have your index.html file in it.

Setting up your domain

Setting up your website

  • It may take a while for the DNS system to propagate the changes from your host, but you should be able to visit your website and see your empty TiddlyWiki online. Congrations! You’ve got a new website.
  • You’ll notice in the TiddlyWiki documentation that the first rule of TiddlyWiki is to always save or back up your wiki!
    • (The second rule, in true Fight Club fashion, is–let’s say it together–to always save or back up your wiki!)
    • Since our wiki is on GitHub, we’ll want to use the Save to a Git Service instructions. Once set up, the changes to our TiddlyWiki should automatically self-save (this can be changed within your wiki’s Control Panel too) or they can be saved manually using the TiddlyWiki checkmark save functionality.
    • I’ll note that you can presently use your GitHub password in these settings, but this isn’t quite as secure as generating a custom token (or password), and sometime in late 2020, GitHub won’t allow you to use your basic account password this way, so you may as well set up the personal access token now.
  • Setting up Personal Access Tokens
    • You will need a Personal Access Token (essentially a password that will be specific to your TiddlyWiki account) in order to save your TiddlyWiki file.
    • On GitHub, click on your user icon, select “Settings”, then “Developer Settings”
    • Next click on the “Personal Access Tokens” tab and then click “Generate new token”
    • Give your token a descriptive name like “TiddlyWiki”
    • Under scopes, select “repo” (and all of its sub-scopes)
    • Click the “Generate Token” button at the bottom of the page.
    • Once created, immediately copy this string somewhere safe since navigating away from the page will not allow you to recover it. (If you do, you’ll need to regenerate a new token.)
    • Finally copy the text of your token into the Tiddler noted above in place of your password. There’s no explicit save button, just ‘X’ out of the settings control panel and click your TiddlyWiki’s main save button.
    • Your token value should be stored in browser local storage.
    • Now you can edit any Tiddler and save it.
      • After edits to your wiki, you’ll see that the checkmark icon on the page is red (depending on your theme), indicating changes to save. You can click on it to force a save.
      • I’ve found it convenient to wait for the TiddlyWiki to schedule the save on its own, however, make sure you’ve saved any changes you want before closing your browser tab.
      • Sometimes saves aren’t always successful and you’ll see error warnings, but usually they’ll clear themselves up on subsequent auto saves.
      • If necessary, you can visit your GitHub repository for your wiki and it will indicate the interval of time since the last save.

We’re done!

  • Everything after this you may be able to either handle yourself by poking around your new wiki or you can find lots of help in the two Google Groups listed above or by searching around online, in fora, or even step-by-step videos on YouTube.
  • If you’ve done this as part of the IndieWeb or A Domain of One’s Own, be sure to log yourself into the IndieWeb wiki and add yourself to the examples on their TiddlyWiki page where you might also find some other useful ideas.
  • If you like, you can delve deeper into GitHub and use one of their apps or command line functionality to regularly back up your website to your desktop, or you can make branches of your site on your local computer and then push those changes up to the cloud.
  • If you find problems or encounter issues, feel free to drop me a line or catch me or others in the IndieWeb chat.

Review of Typlog as a turnkey platform for IndieWeb as a Service

Yesterday I ran across a tweet in the IndieWeb chat announcing that Typlog, a hosted website/blogging platform, now supports Webmention.

I looked at their website, and it also looks like they support a few other IndieWeb building blocks including WebSub and RelMeAuth by leveraging Twitter and GitHub. (The developer indicated they supported IndieAuth, but I highly suspect it’s just RelMeAuth, which is still a solid option for many IndieWeb tools.) 

Having just put together a Quick Start IndieWeb chart that includes services like micro.blog, i.haza.website, and pine.blog, I was immediately intrigued. This new platform (proprietary and not self-hostable, but very similar to the others) looks like a solid looking little platform for hosting one’s personal website (or podcast) that includes some IndieWeb building-blocks.

It’s got a 7 day free trial, so naturally I spun up a quick website. With just a few simple defaults, I had something pretty solid looking in only a few minutes with a pleasant on-boarding experience.

I’ll note that some functionality like importing content from WordPress, Tumblr, Ghost, or a podcast feed requires an actual subscription. Once you’ve finally subscribed, there are instructions to set it up to use your own domain name. However, most of the basic functionality is available in the trial. Another important indie feature is that it has a built-in export using JSON format, so that one can take their domain and content to another service provider if they wish.

It looks like it’s got a ton of common useful features! This includes support for podcasting, password protected posts, scheduling posts, membership posts, and integrations for Stripe, CloudFlare, Google Analytics, and MailChimp among many others. The platform is built with some basic and beautiful page templates and prefers to have markdown in the editor, but seems to work well with raw HTML.

They also allow adding custom code into <header> and <footer> so it should be straightforward to add support Microsub to one’s site using a service like Aperture so that you can have (feed) reader support.

Unfortunately it looks like there’s no Micropub support yet. I suspect that Typlog would be quite pleased to have a number of posting applications for both desktop and mobile available to it by adding this sort of support.

Also on testing, it looks like while the platform supports incoming Webmention, it doesn’t seem to be sending webmentions to links within posts. (Perhaps they’re batch processed asynchronously, but I haven’t seen anything yet.)

The platform seems to do really well for posting articles and podcasts and even has a custom template for reviews, but all of the user interface I’ve seen requires one to add a title on all posts, so it doesn’t lend itself to adding notes (status updates) or other indie-like posts like bookmarks, likes, or simple replies. It has a minimal built in h-card, but it could be expanded a bit for sending webmentions.

The pricing for the service starts at a very reasonable $4/month and goes up to $12/month with some additional discounts for annual payments.

In sum, I love this as another very indy-flavored web hosting service and platform for those looking to make a quick and easy move into a more IndieWeb way of hosting their website and content. While services like micro.blog and i.haza.website may be ahead of it on some technical fronts, like pine.blog, Typlog has a variety of different and unique features that many are likely to really appreciate or wish that other services might have. I imagine that over time, all of them will have relative technical parity, but will differentiate themselves on user interface, flexibility, and other services. I could definitely recommend it to friends and family who don’t want to be responsible for building and managing their websites.

One of my favorite parts of Typlog is that the company building it is based in Japan, where I’ve seen a little bit of development work for IndieWeb, but not as much as in portions of Europe, America, or Australia. It’s been great seeing some growth and spread of IndieWeb philosophy and platforms in Asia, Africa, and India recently.

And of course, who couldn’t love the fact that the developer is obviously eating their own cooking by using the platform to publish their own website! I can’t wait to see where Typlog goes next.