Marty McGuire

Posts Tagged indieweb

Sat Mar 11

This Week in the IndieWeb Audio Edition • March 4th - 10th, 2017

Audio edition for This Week in the IndieWeb for March 3th - 10th, 2017.

Thanks to everyone for the feedback so far! In responding to a couple of listener requests, I slowed my speaking rate down for this week’s updates. However, because I am re-using some common clips, it sounds like I am speeding up and slowing down quite a bit. My apologies for any confusion this causes! I plan to re-record the common samples soon.

You can find all of my audio editions here.

You can subscribe with your favorite podcast app on huffduffer.

Music from Aaron Parecki’s 100DaysOfMusic project: Day 48 - Glitch, Day 49 - Floating, Day 9, and Day 11

Thanks to everyone in the IndieWeb chat for their feedback and suggestions. Please drop me a note if there are any changes you’d like to see for this audio edition!

Sat Mar 4

This Week in the IndieWeb Audio Edition • February 25 - March 3, 2017

Audio edition for This Week in the IndieWeb for February 25th - March 3rd, 2017.

You can find all of my audio editions here.

You can subscribe with your favorite podcast app on huffduffer.

Music from Aaron Parecki’s 100DaysOfMusic project: Day 48 - Glitch, Day 49 - Floating, Day 9, and Day 11

Thanks to everyone in the IndieWeb chat for their feedback and suggestions. Please drop me a note if there are any changes you’d like to see for this audio edition!

Mon Feb 27

Site updates: Syndication links

A common IndieWeb principle, after "Own Your Data" is Publish on your Own Site, Syndicate Elsewhere .

In general, this means that you should make posts on your own site, then copy the post to silos like Twitter, Facebook, etc., to reach the folks in those communities. To complete the process, include links on your site from the original post out to the syndicated copies.

One fun reason to do this is that tools like brid.gy use syndication links in order to backfeed comments and reactions from silos like Facebook and Twitter to your own site.

I'd been collecting these links for a while and displaying them in a "hidden" way - so tools like bridgy could see them, but a human reading the page would not.

Yesterday I added a "See also:" section that includes links out to any syndicated copies of my posts on other sites.

Fri Feb 24

This Week in the IndieWeb February 18 - 24, 2017

Audio edition for This Week in the IndieWeb for February 18th - 24th, 2017.

You can find all of my audio editions here.

And maybe you can subscribe with whatever you consume podcasts with on huffduffer.

Music from Aaron Parecki’s 100DaysOfMusic project: Day 48 - Glitch, Day 9, Day 11

Thanks to everyone in the IndieWeb chat for their feedback and suggestions. Please drop me a note if there are any changes you’d like to see for this audio edition!

Tue Feb 21
↩ Replied to https://stream.jeremycherfas.net/2017/a-podcast-about-the-indieweb
post from A podcast about the Indieweb
Further to my note about a new #podcast about #indieweb things, I listened to Marty McGuire's rendering of This Week in the Indieweb. I really enjoyed it, even though I had read the text version. Production and audio were top notch, and it was very clear. My only quibbles concern …

Jeremy raises some great points here that mirror some of my own worries about trying to summarize the discussions happening on the IndieWeb wiki and the many #indieweb chat channels.

When I had the initial idea to do an “audio edition” of This Week in the IndieWeb, the question of “who is the audience” seemed to have an obvious answer: folks who would read the newsletter but preferred an audio edition.

However, it quickly became clear that doing a “direct read” of the newsletter — where much of the content is names and links to changes on wiki pages — wouldn’t make a lot of sense when spoken aloud. So, my first crack at the format evolved into answering a slightly broader question: “how can I explain these updates to someone who might not already be familiar with the wiki?”

My short (and unhelpful) answer is: this is hard. The discussions on the wiki tend to be very technical, jargon-heavy, and touch on an extremely wide set of topics. In the first episode, I attempted to give some structure with groupings like “IndieWeb Events”, “Software and Services”, “Silo Updates”, “Silo Issues”, etc., but I agree with Jeremy that it is still very fast and dense. While I want to keep the podcast short (less than 10 minutes), I think a next positive step would be to give topics more time to breathe with some explanatory commas that give context.

It is my hope that projects like this podcast will help find new ways to phrase and frame the things that the IndieWeb community are doing and talking about, helping to reach new folks. I have a feeling it is going to be a lot of work. :}

Mon Feb 20

Site updates: Tags and Media Fragments

Over the weekend I created an English audio version of the most recent This Week in the IndieWeb newsletter. This led to some great discussion in the #indieweb chat about improvements and next-steps in creating a podcast from audio posts on one's own website. Today I added a couple of features to my site towards that end.

First up, I added support for "tag aggregations" - essentially, pages that list all posts with a certain tag. So, any future editions of this audio newsletter that I post can be tagged with "this-week-indieweb-podcast" and will then show up on the "This Week in the IndieWeb Podcast" page. It should soon be possible to feed that page to a tool like Granary to convert the feed on that page, with its audio entries, into an RSS feed suitable for subscribing with a podcast app.

Next up, I added support for "Media Fragments", a W3C recommendation that allows linking to a specific timestamp to start (and even stop!) playback of video and audio. Aaron Parecki's recently implemented this on his own site and was kind enough to share the implementation! Now, you can create links that jump to a specific time of any audio or video post on my site.

For example, if you want to quickly jump to the part of the This Week in the IndieWeb audio edition that contains info about the next upcoming Homebrew Website Club meetings, it looks like this: https://martymcgui.re/2017/02/18/151503/#t=54

Media fragments could enable some fun things, such as a list of links that index directly to particular sections of a long recording.

Aaron also documented a fun way to use media fragments for attribution of other people's audio or video posts. For example, my audio newsletter made use of several of Aaron Parecki's pieces from his 100DaysOfMusic project. I gave attribution by linking to Aaron's posts from my post, and because Aaron's site supports Webmentions, you can see that my post shows up in the "mentions" list for one of the clips I used. With media fragment support, it should be possible to have the mentions on Aaron's post link directly to the exact portion of my audio post where it appears!

Features like this give me hope that it could be possible to make an IndieWeb podcasting experience that is richer and more interactive than the current directory model.

Sat Feb 18

This Week in the IndieWeb February 10 - 17, 2017

Audio edition for This Week in the IndieWeb for February 10th - 17th, 2017

Thinking about doing this as a regular thing, if I can get the production time down. Feedback welcome!

Music from Aaron Parecki’s 100DaysOfMusic project:

Wed Feb 8

HWC Baltimore 2017-02-08 Wrap-Up

Baltimore's February 2017 meetup for Homebrew Website Club met at the Digital Harbor Foundation Tech Center on Feb 8th.

Notes from the "broadcast" portion of the meetup:

martymcgui.re - reworked his micropub server to support the media endpoint he was working on last time. also added venue pages to his site for event locations. made progress on event-posting micropub client (eventually will be released publicly). also added support for deleted posts with dt-deleted and meta http-equiv status 410 gone.

jonathanprozzi.net - refactoring site templates. spent a lot of time debugging some simple problems, h-cards. wants to figure out a way to track incremental work on website when other work things are crazy so threads don't get lost. wants to keep segmenting his Hugo template while maintaining mf2 stuff. goal is to get to working on appearance of his site theme.

jjuran.org - currently working on a CV on his site. first use of img srcset to feed high-res images to clients that want them. uses his own Perl-based static site generator that is "showing its age". working on his own programming language so he can spend most of his time writing code in a high-level language.

We discussed the challenges of building your own tools for fun vs. starting from the goal of posting more (e.g. via Wordpress).

Left-to-right: martymcgui.re, jonathanprozzi.net, jjuran.org

We hope that you'll join us for the next HWC Baltimore on March 22nd back here at the Digital Harbor Foundation Tech Center.

Photo for HWC Baltimore 2017-02-08!

Thu Jan 26

Spano - a minimum-viable Micropub Media Endpoint

Micropub is an open API standard to create posts on one's own domain using third-party clients  and currently a W3C Candidate Recommendation. One of the (semi-) recent additions is the idea of a Micropub Media Endpoint. The Media Endpoint provides a way for Micropub clients to upload media files to a Micropub service, receiving a URL that is sent along in place of the file contents when the post is published.

Some of the things I like about Micropub media endpoints include:

  • The spec allows the media endpoint to be on a completely separate domain from the "full" micropub endpoint.
  • The spec doesn't specify anything about how the files are stored or their final URLs or filenames.
  • They make it easy to separate the handling of (large) media files from the (presumably much smaller) content and metadata of a post.
  • They enable Micropub clients to upload multiple files without creating multiple posts. This makes it simpler to create posts that contain multiple images, like a gallery.

Personally, I wanted a Micropub media endpoint server with a few extra properties:

  • It should be able to run completely separately from, and therefore work in conjunction with, any other micropub server implementation.
  • It should not store duplicate files. If the same file is uploaded twice, the same URL should be returned both times.
  • It should not allow overwriting files. If two images of the same name are uploaded, both are kept and receive different URLs.

Enter HashFS

My extra features above essentially describe a content-addressable storage storage system. CAS is a way of storing and accessing data based on some property of the actual content, rather than (potentially arbitrary) files and folders.

HashFS is a Python implementation of a content-addressable file management system. You give it files, it will put them in a directory structure based on a cryptographic hash function of the contents of that file. In other words - HashFS can take any file and give back a unique path to that file which will never change (if you later upload a new version of the file, it gets a different path).

To add the the fun of HashFS, there is a Flask extension called Flask-HashFS which makes it easy to expose a HashFS file store on the web via the Python Flask framework.

Introducing Spano

Spano is a Micropub Media Endpoint server written in Python via the Flask framework which combines Flask-HashFS for file storage with Flask-IndieAuth (introduced earlier) to handle authentication and authorization.

Spano is a server-side web app that basically does one thing: it accepts HTTP POST requests with a valid IndieAuth token and a file named "file", stores that file, and returns a URL to that file. The task of serving uploaded files is left to a dedicated web server like nginx or Apache.

Using Spano

Once Spano has been set up and configured for your domain, uploading is a matter of getting a valid IndieAuth token. IndieAuth-enabled Micropub clients will do this automatically. For testing by hand I like to log in to Quill and copy the access token from the Quill settings page. With token in hand, uploads are as easy as:

curl -D - -F "file=@myfile.jpg" \
  -H"Authorization: Bearer xxxx..." \
  https://media.example.com/micropub/

Which should output a response like:

HTTP/1.1 100 Continue

HTTP/1.0 201 CREATED
Content-Type: text/html; charset=utf-8
Content-Length: 108
Location: https://media.example.com/cc/a5/97/7c/2004..2cb.jpg
Server: Werkzeug/0.11.4 Python/2.7.11
Date: Thu, 26 Jan 2017 02:40:05 GMT

File created: https://media.example.com/cc/a5/97/7c/2004..2cb.jpg

Integrating Spano with your Micropub Endpoint

If you want Micropub clients to use Spano as your Media Endpoint, you need to advertise it. This is handled by your "main" Micropub server using discovery. Essentially, a client will make a configuration request to your server like so:

https://example.com/micropub?q=config

And your server's response should be a JSON-formatted object specifying the "media-endpoint". A bare minimum example:

{
  "media-endpoint": "https://media.example.com/micropub/"
}

In addition to advertising the media-endpoint, your Micropub server must be able to handle lists of URLs in places where it would normally expect a file.

For example, when posting a photo from Quill without a media endpoint, your Micropub server will receive a multipart/form-data encoded file named "photo". When posting from Quill with a media endpoint, your Micropub server will instead receive a list of URLs represented as "photo[]=https://media.example.com/cc/...2cb.jpg". Presumably this pattern would hold for other media types such as video and audio, if you are using Micropub clients that support them.

This particular step has been an interesting challenge for my site, which is a static site generated by Jekyll. My previous Micropub file-handling implementation expected all uploaded assets to live on disk next to the post files, and updating my Jekyll theme and plugins to handle the change is a work in progress. I eventually plan to move all my uploads out of the source for my project in favor of storing them with Spano.

Feedback Welcome!

Spano is probably my second public Python project, so I'd love feedback! If you try it out and run into issues, please drop me a line on GitHub. Or you can find me in the #indieweb chat on freenode IRC.

I'd also like to thank Kyle Mahan for his Woodwind Flask server application, which inspired the structure of Spano.