Inspired by the concept of Ripped Sheets of Paper, I began to see a new blog design in my mind that departed from all the current trends. (Related: Things We Left in the Old Web.)

The large majority of blogs and social media feeds out there are:

• Highly rigid visually—a linear list of paragraphs.
• Mostly blue and white (with a little gray.)
• Bland. Often all posts are structured virtually the same, unless there are images.
• Alike. There are common templates.

So, yeah, no wonder the Web has deteriorated! We just don’t care. It’s understandable—we experimented for a good ten or twenty years. I guess that’s why I wanted this site to border on bizarre—to try to reach for the other extreme without simply aspiring to brutalism.

To show that leaving social media can free you to build your own special place on the web. I have no reason to scream and war here in order to stand apart.

The Old Web isn’t dead. It just got old enough that it constantly seems to leave the spreadsheet with all of its passwords open on the desktop. It is sinking into the sofa while images of a low-bitrate Spaghetti Western dance in its bifocals.

We decry the loss of privacy and data ownership that seemed to be there in the Old Web. And we always wish there had been security. However, there are other things we left in the pockets of that Old Gray Web on the couch.

High Def With No Color

It seems that everything is white and blue in the present day. We’ve settled on these neutral colors, in case we need to sell it all. The old garish animated construction cones and embedded MIDI files are relegated to Neocities now—and who even cares what that is?

When we post, we post a few words. A picture and a few words. Some gray words on white. With a little blue.

This is one reason I was happy to see RSS fall out of favor. I don’t really want to read everything in Arial, gray on white with a little blue. Blog posts that were beautifully arranged in their homes, now stuffed together into a makeshift public shelter of dreary gray and white and chalked around with a little line of blue.

Right now the spotlight is stolen by lovely chips like the ESP8266 and the BCM2835 (the chip powering the new Raspberry Pi Zero). However, personally, I still find myself spending a lot of time with the ATtiny44a. With 14 pins, it’s not as restrictive as the ATtiny85. Yet it’s still just a sliver of a chip. (And I confess to being a sucker for its numbering.)

My current project involves an RF circuit (the nRF24l01+) and an RGB LED. But the LED needed some of the same pins that the RF module needs. Can I use this chip?

The Rise and Fall of PWM

The LED is controlled using PWM — pulse-width modulation — a technique for creating an analog signal from code. PWM creates a wave — a rise and a fall.

This involves a hardware timer — you toggle a few settings in the chip and it begins counting. When the timer crosses a certain threshold, it can cut the voltage. Change the threshold (the OCR) and you change the length of the wave. So, basically, if I set the OCR longer, I can get a higher voltage. If I set a lower OCR, I get a lower voltage.

I can have the PWM send voltage to the green pin on my RGB LED. And that pin can be either up at 3V (from the two AA batteries powering the ATtiny44a) or it can be down at zero — or PWM can do about anything in between.

My problem, though, was that the SPI pins — which I use to communicate with the RF chip — overlap my second set of PWM pins.

You see — pin 7 has multiple roles. It can be OC1A and it can also be DI. I’m already using its DI mode to communicate with the RF module. The OC1B pin is similarly tied up acting as DO.

I’m already using OC0A and OC0B for my green and blue pins. These pins correspond to TIMER0 — the 8-bit timer used to control those two PWM channels on OC0A and OC0B. To get this timer working, I followed a few steps:

// LED pins
#define  RED_PIN   PA0
#define  GREEN_PIN PB2
#define  BLUE_PIN  PA7

Okay, here are the three pins I want to use. PB2 and PA7 are the TIMER0 pins I was just talking about. I’m going to use another one of the free pins (PA0) for the red pin if I can.

DDRA |= (1<<RED_PIN) | (1<<BLUE_PIN);
DDRB |= (1<<GREEN_PIN);

Obviously I need these pins to be outputs — they are going to be sending out this PWM wave. This code informs the Data Direction Register (DDR) that these pins are outputs. DDRA for PA0 and PA7. DDRB for PB2.

// Configure timer0 for fast PWM on PB2 and PA7.
TCCR0A = 3<<COM0A0 | 3<<COM0B0 // set on compare match, clear at BOTTOM
       | 3<<WGM00; // mode 3: TOP is 0xFF, update at BOTTOM, overflow at MAX
TCCR0B = 0<<WGM02 | 3<<CS00; // Prescaler 0 /64

Alright. Yeah, so these are TIMER0’s PWM settings. We’re turning on mode 3 (fast PWM) and setting the frequency (the line about the prescaler.) I’m not going to go into any detail here. Suffice to say: it’s on.

// Set the green pin to 30% or so.
OCR0A = 0x1F;
// Set the blue pin to almost the max.
OCR0B = 0xFC;

And now I can just use OCR0A and OCR0B to the analog levels I need.

TIMER1, 16-bit is Better, Right?

Most of these AVR chips have multiple timers and the ATtiny44a is no different — TIMER1 is a 16-bit timer with hardware PWM. Somehow I need to use this second timer to power th PWM on my red pin.

I could use software to kind of emulate what the hardware PWM does. Like using delays or something like that. The Make: AVR Programming book mentions using a timer’s interrupt to handcraft a hardware-based PWM.

This is problematic with a 16-bit timer, though. An 8-bit timer maxes out at 255. But a 16-bit timer maxes out at 65535. So it’ll take too long for the timer to overflow. I could lower the prescaler, but — I tried that, it’s still too slow.

Then I stumbled on mode 5. An 8-bit PWM for the 16-bit timer. What I can do is to run the 8-bit PWM on TIMER1 and not hook it up to the actual pin.

// Setup timer1 for handmade PWM on PA0.
TCCR1A = 1<<WGM10; // Fast PWM mode (8-bit)
                   // TOP is 0xFF, update at TOP, overflow at TOP
TCCR1B = 1<<WGM12  // + hi bits
        | 3<<CS10;  // Prescaler /64

Okay, now we have a second PWM that runs at the same speed as our first PWM.

What we’re going to do now is to hijaak the interrupts from TIMER1.

TIMSK1 |= 1<<OCIE1A | 1<<TOIE1;

Good, good. OCIE1A gives us an interrupt that will go off when we hit our threshold — same as OCR0A and OCR0B from earlier.

And TOIE1 supplies an interrupt for when the thing overflows — when it hits 255.

Now we manually change the voltage on the red pin.

ISR(TIM1_COMPA_vect) {
    sbi(PORTA, RED_PIN);
}
ISR(TIM1_OVF_vect) {
    cbi(PORTA, RED_PIN);
}

And we control red. It’s not going to be as fast as pure PWM, but it’s not a software PWM either.

Why Not Use Another Chip?

I probably would have been better off to use the ATtiny2313 (which has PWM channels on separate pins from the SPI used by the RF) but I needed to lower cost as much as possible — 60¢ for the ATtiny44a was just right. This is a project funded by a small afterschool club stipend. I am trying to come up with some alternatives to the Makey Makey — which the kids enjoyed at first, but which alienated at least half of them by the end. So we’re going to play with radio frequencies instead.

I imagine there are better other solutions — probably even for this same chip — but I’m happy with the discovery that the PWM’s interrupts can be messed with. Moving away from Arduino’s analogWrite and toward manipulating registers directly is very freeing — in that I can exploit the chip’s full potential. It does come with the trade off that my code won’t run on another chip without a bunch of renaming — and perhaps rethinking everything.

Whatever the case, understanding the chip’s internals can only help out in the long run.

If you’d like to see the code in its full context, take a look through the Blippydot project.

OpenFL is good. It is pleasing. This we know. It makes computer programs. However, it is itself one of these programs. Gah! So it is actually very bad and frustrating! But oh how we love it still—we needn’t be primates.

Okay, let’s see how good it is with the new Xcode. This new Xcode 7 lets us sideload. Yes, it’s true. It lets us put our mobile programs into our mobile computers without anything special—without a premium account of any kind or any permission—as if we were now in control.

How it does this is by granting us little licenses through a plain, average Apple ID. We will need to tell Xcode about our account. And we will need to create these things called provisioning profiles for each one of our apps. And we will need to click the Fix Issue button many times. More to come on that.

For this, you must have OpenFL installed for Mac. Download the latest Haxe from that page and then run, in a Terminal:

$ haxelib install openfl
$ haxelib run openfl setup

Now, let’s get a sample going.

$ openfl create NyanCat iNyanCat
$ cd iNyanCat

OpenFL already has a number of sample programs—we’re copying the built-in NyanCat sample for our purposes. It’s true that Nyan Cat is not as funny as it used to be, but it is funny enough for Xcode to at least compile.

Edit the project.xml file in there.

<meta title="NyanCat" package="org.openfl.samples.nyancat" 
  version="1.0.0" company="OpenFL" />

Best to change the Bundle Identifier. (The package setting above.) This has to be globally unique (as in one-of-a-kind on all of planet Earth) so put something in that’s peculiar.

<meta title="NyanCat" package="com.kickscondor.nyancat" 
  version="1.0.0" company="OpenFL" />

I am also using the beta release of Xcode 7. So it was necessary to use xcode-select to point OpenFL in the right direction.

$ sudo xcode-select -s /Applications/Xcode-beta.app/Contents/Developer 

Right ok. Back to trying to get this thing to come up.

$ openfl test ios

The openfl test ios command will be very chatty—screens and screens for several minutes. It is making something for us.

⛺ Plug in the iPad or iPhone at this point. If this is your first time connecting it, tell it to Trust this computer.

Hold up.

=== BUILD TARGET NyanCat OF PROJECT NyanCat WITH CONFIGURATION Re
lease ===
Check dependencies
Code Sign error: No matching provisioning profiles found: No prov
isioning profiles with a valid signing identity (i.e. certificate
and private key pair) matching the bundle identifier “com.kicksco
ndor.nyancat” were found.
CodeSign error: code signing is required for product type 'Applic
ation' in SDK 'iOS 9.0'
** BUILD FAILED **
The following build commands failed:
        Check dependencies
        (1 failure)

It’s true—this thing it’s saying about the provisioning profile is true. We have no provisioning profile. This isn’t confusing. All error messages are repellant, so, no, you can’t look directly at it, but it’s speaking the truth to you.

Normally, if your program is in Apple’s store, you would go to Apple’s site to fix this. You would follow something like these steps. But we want to use Xcode 7 for this.

If you haven’t intuited this already, you must install Xcode 7.

Go into the Export/iOS folder under the iNyanCat folder. Open the iNyanCat.xcodeproj file.

Clicking on the bolded NyanCat project name on the left side of Xcode will show a page with this at the top:

And now we create the team profile. From the Team selector, choose Add an account… and enter your Apple ID credentials.

A Fix Issue button will appear. Press it.

You may also want to be aware of the Deployment Target area.

Sometimes upping the version on this will get you through problems.

At this point, you could just run the project from Xcode. (If you want to do that, just click on the arrow in the toolbar—the one that looks like a Play button—but be advised that it will take FOREVER to build.)

So, no, let’s not—let’s head back to the Terminal, as our build was almost complete when we had the provisioning profile problems.

$ openfl test ios

And it should appear on the iPad.

[ 60%] InspectingPackage
[ 60%] TakingInstallLock
[ 65%] PreflightingApplication
[ 65%] InstallingEmbeddedProfile
[ 70%] VerifyingApplication
[ 75%] CreatingContainer
[ 80%] InstallingApplication
[ 85%] PostflightingApplication
[ 90%] SandboxingApplication
[ 95%] GeneratingApplicationMap
[100%] Installed package /Users/kicks/Code/iNyanCat/Export/ios/bu
ild/Release-iphoneos/NyanCat.app

And So Now It Just Works?

Yes, so basically now you can just stick to the Terminal and rebuild your app without needing to do anything with Xcode again.

The only issue that arises is if you want to create another new app.

You will need to edit the project.xml and change the Bundle Identifier in the new project. It’s a different app, it needs its own Id.

You will need to load the xcodeproj file into Xcode and hit Fix Issue again. This will assign this Bundle Identifier to your account. It’s like reserving a spot with Apple.

And then you should be in business for that project.

Problems Unforeseen

I had my share of problems—I will now relive these with you.

First, this one.

[....] Waiting up to 5 seconds for iOS device to be connected
[....] Using (null) (679c2f770cab0a8d8dc691595a8799b6aee88ca0).
------- Install phase -----
[  0%] Found (null) connected through USB, beginning install
Assertion failed: (AMDeviceIsPaired(device)), function handle_
device, file ios-deploy.c, line 1500.

This means your iPad needs to trust. Unlock the iPad and you should see a popup: Trust this computer? Yes, please.

Next problem:

[ 60%] TakingInstallLock
[ 65%] PreflightingApplication
[ 65%] InstallingEmbeddedProfile
[ 70%] VerifyingApplication
AMDeviceInstallApplication failed: 0xE8008015: Your application
failed code-signing checks. Check your certificates, provisioning
profiles, and bundle ids.

I opened Xcode and discovered that the iPad Mini I had hooked up was listed as “ineligible.”

If your device is listed as “ineligible” then this means that the Xcode you’re using doesn’t include a Developer Disk Image for that specific version of iOS. In my case, I had 8.0.2 on the iPad Mini. What on earth causes a missing Developer Disk Image, though? Well, let’s see what’s included in my Xcode 7 installation:

$ ls /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS
.platform/DeviceSupport
6.0/            7.0/            8.1/            8.3/            Latest@
6.1/            7.1/            8.2/            9.0 (13A4280e)/

These are the versions I can sideload on to. As you can see, 8.0.2 is not present. The simplest way to solve this is for me to upgrade my iPad Mini to one of these versions.

You may also need to look for a newer Xcode release. I had problems with this because I had upgraded to iOS 8.4 on an iPad, but—as seen above—Xcode didn’t support iOS 8.4 yet. My device was ineligible because it was way too upgraded.

This problem also persisted when I hadn’t loaded symbol files onto the iPad Mini. Return to Xcode and load the xcodeproj file and ensure you can deploy to the device from there—once again, “Fix Issue” is your friend.

Here’s another one that plagued me for awhile.

[ 52%] CreatingStagingDirectory
[ 57%] ExtractingPackage
[ 60%] InspectingPackage
[ 60%] TakingInstallLock
[ 65%] PreflightingApplication
AMDeviceInstallApplication failed: -402653058

I tried upgrading the ios-deploy tool that comes with OpenFL. No good. I tried entering device information into the project.xml. Not that either.

I believe it went away when I started using Xcode to setup the provisioning profile. Xcode will connect to the device and put symbol files on it. You might try using Xcode’s arrow button (looks like a Play button on an audio player) and select your iPad in the area right next to the button. It will take a long time—but it only needs to happen once.

There also was this troublesome error that appeared while openfl test ios was running.

clang: error: -fembed-bitcode is not supported on versions of iOS
prior to 6.0

There are two possible solutions here. First, this is fixed in lime 2.4.8. So run haxelib list and ensure that lime is at least more recent than that. If not, run haxelib upgrade. 👈 Do this anyway—seems intellegent.

Second option is to simply open the XCode project and change the deployment target to (at least) iOS 6.0. (Bitcode enables the Apple Store to optimize your binary, at the cost of losing access to iOS 5.)

chmod: Unable to change file mode on /usr/lib/haxe/lib/lime/2,4,8
/templates/bin/ios-deploy: Operation not permitted
sh: /usr/lib/haxe/lib/lime/2,4,8/templates/bin/ios-deploy: Permis
sion denied

This one can be solved by manually making the file executable using sudo:

sudo chmod 0755 /usr/lib/haxe/lib/lime/2,4,8/templates/bin/ios-deploy

Mongo Bonus Mongo

I also had difficulties getting the MongoDB driver for Haxe going under iOS. It worked fine for local testing (openfl test neko) but not for the device. I got compiler errors.

I forked the driver and made some alterations. Try this.

$ haxelib git mongodb-kicks https://github.com/kickscondor/mongo-haxe-driver

Add then add to your project.xml:

<haxelib name="mongodb-kicks" />

It is nice little touches like this, such as being able to bring in forked code from Github, that make OpenFL such a pleasure—even when it’s in a somewhat crabby mood about having to move itself onto such a suffocating platform such as Apple’s.

⛺ UPDATE: Recent versions of Xcode (7.2, for example) have a few different error messages that I thought I would cover also.

------- Install phase -----
[  0%] Found XXX 'DeviceName' (...) connected through USB, beginning install
Assertion failed: (AMDeviceIsPaired(device)), function handle_device,
file ios-deploy.c, line 1500.

This one is a trust issue. Unlock your iPad or iPhone. You should see a dialog box asking if you want to trust this computer. Tap Trust.

You may also need to unplug the device and then plug it back in. This error can persist even after tapping Trust.

[ 65%] PreflightingApplication
[ 65%] InstallingEmbeddedProfile
[ 70%] VerifyingApplication
AMDeviceInstallApplication failed: 0xE8008016: Unknown error.

This is a code-signing issue. You want to use the Fix Issue button in Xcode. (See the And So Now It Just Works? section above for some instructions.)

Lastly, there’s a new popup on iOS that will block your app, with the title Untrusted Developer. The message continues: Your device management settings do not allow using apps from developer “iPhone Developer: [email protected] (XXXX)” on this iPad. You can allow using these apps in Settings.

The solution to this is in iOS Settings. Go to the Settings app. The General settings > tap Profile > tap [email protected] (or whatever the e-mail address was in the warning above.) Now trust [email protected]. And click Verify app. Go back to your app and it should run.

It seems like this information hasn’t been disclosed quite enough as it should: Makey Makey’s version 1.2, produced by JoyLabz, cannot be reprogrammed with the Arduino software. In previous versions, you could customize the firmware — remap the keys, access the AVR chip directly — using an Arduino sketch.

🙌 NOTE: Dedokta on Reddit demonstrates how to make a Makey Makey.

Now, this isn’t necessarily bad: version 1.2 has a very nice way to remap the keys. This page here. You use alligator clips to connect the up and down arrows of the Makey Makey, as well as the left and right arrows, then plug it into the USB port. The remapping page then communicates with the Makey Makey through keyboard events. (See Communication.js.)

This is all very neat, but it might be nice to see warnings on firmware projects like this one that they only support pre-1.2 versions of the Makey Makey. (I realize the page refers to “Sparkfun’s version” but it might not be clear that there are two Makey Makeys floating about—it wasn’t to me.)

⛺ UPDATE: The text on the chip of the version 1.2 appears to read: PIC18F25K50. That would be this.

Some Notes About Connecting to iPads

Now, how I came upon this problem was while experimenting with connecting the Makey Makey to an iPad. Instructions for doing this with the pre-1.2 Makey Makey are here in the forums—by one of the creators of the MM.

With the 1.2 version, it appears that the power draw is too great. I received this message with both an iPad Air and an original iPad Mini.

Obviously a Makey Makey isn’t quite as interesting with an iPad — but I was messing with potentially communicating through a custom app.

Anyway, without being able to recompile the firmware, the iPad seems no longer an option. (The forum post should note this as well, no?)

Interfacing the Sparkfun Makey Makey with Arduino 1.6.7

If you do end up trying to get a pre-1.2 Makey Makey working with the latest Arduino, I ran into many problems just getting the settings right. The github repos for the various Makey Makey firmwares are quite dated.

One of the first problems is getting boards.txt to find my avr compiler. I had this problem both on Linux and Windows. Here’s my boards.txt that finally clicked for me:

############################################################################
menu.cpu=Processor
############################################################################
################################ Makey Makey ###############################
############################################################################
makeymakey.name=SparkFun Makey Makey
makeymakey.build.board=AVR_MAKEYMAKEY
makeymakey.build.vid.0=0x1B4F
makeymakey.build.pid.0=0x2B74
makeymakey.build.vid.1=0x1B4F
makeymakey.build.pid.1=0x2B75
makeymakey.upload.tool=avrdude
makeymakey.upload.protocol=avr109
makeymakey.upload.maximum_size=28672
makeymakey.upload.speed=57600
makeymakey.upload.disable_flushing=true
makeymakey.upload.use_1200bps_touch=true
makeymakey.upload.wait_for_upload_port=true
makeymakey.bootloader.low_fuses=0xFF
makeymakey.bootloader.high_fuses=0xD8
makeymakey.bootloader.extended_fuses=0xF8
makeymakey.bootloader.file=caterina/Caterina-makeymakey.hex
makeymakey.bootloader.unlock_bits=0x3F
makeymakey.bootloader.lock_bits=0x2F
makeymakey.bootloader.tool=avrdude
makeymakey.build.mcu=atmega32u4
makeymakey.build.f_cpu=16000000L
makeymakey.build.vid=0x1B4F
makeymakey.build.pid=0x2B75
makeymakey.build.usb_product="SparkFun Makey Makey"
makeymakey.build.core=arduino
makeymakey.build.variant=MaKeyMaKey
makeymakey.build.extra_flags={build.usb_flags}

I also ended up copying the main Arduino platform.txt straight over.

Debugging this was difficult: arduino-builder was crashing (“panic: invalid memory address”) in create_build_options_map.go. This turned out to be a misspelled “arudino” in boards.txt. I later got null pointer exceptions coming from SerialUploader.java:78 — this was also due to using “arduino:avrdude” instead of just “avrdude” in platforms.txt.

I really need to start taking a look at using Ino to work with sketches instead of the Arduino software.

It seems like the Beaker Browser has been making an attempt to provide tools so that you can create JavaScript apps that function literally without a server. Their Twitter-equivalent (‘fritter’) runs entirely in the browser—it simply aggregates a bunch of static dats that are out there. And when you post, Beaker is able to write to your personal dat. Which is then aggregated by all the others out there.

One of the key features of Beaker that allows this is the ‘fallback_page’ setting. This setting basically allows for simplified URL rewriting—by redirecting all 404s to an HTML page in your dat. In a way, this resembles mod_rewrite-type functionality in the browser!

What I’ve been wondering is: would it be possible to bring server-side includes to Beaker? So, yeah: browser-side includes. My patch to beaker-core is here. It’s very simple—but it works!

Quick Example

Here is Beaker editing the index.html of a new basic Website from its template. I’m including the line:

<!--#include file="inc.html"-->

This will instruct beaker to inline the inc.html contents from the same dat archive. Its contents look like this:

<p style="color:red">TEST</p>

And here we see the HTML displayed in the browser.

But Does Beaker Need This?

I’m not sure. As I’ve been working with static HTML in dat, I’ve thought that it would be ‘nice’. But is ‘nice’ good enough?

Here are a few positives that I see:

Appeal to novices. Giving more power to HTML writers can lower the bar to building interesting things with Dat. Beaker has already shown that they are willing to flesh out JavaScript libraries to give hooks to all of us users out here. But there are many people who know HTML and not JavaScript. I think features for building the documents could be really useful.

Space savings. I think static blogs would appreciate the tools to break up HTML so that there could be fewer archive changes when layouts change subtly.

Showcase what Beaker is. Moving server-side includes into Beaker could demonstrate the lack of a need for an HTTP server in a concrete way. And perhaps there are other Apache/Nginx settings that could be safely brought to Beaker.

The negative is that Dat might need its own wget that understands a feature like this. At any rate, I would be interested if others find any merit to something like this. I realize the syntax is pretty old school—but it’s already very standard and familiar, which seems beneficial.

All this recent discussion about link directories and one of the biggest innovations was sitting under my nose! The awesome-style directory, which I was reminded of by the Dat Project’s Awesome list.

An “awesome” list is—well, it isn’t described very well on the about page, which simply says: only awesome is awesome. I think the description here is a bit better:

Curated lists of awesome links around a specific topic.

The “awesome” part to me: these independently-managed directories are then brought together into a single, larger directory. Both at the master repo and at stylized versions of the master repo, such as AwesomeSearch.

In a way, there’s nothing more to say. You create a list of links. Make sure they are all awesome. Organize them under subtopics. And, for extra credit, write a sentence about each one.

Generally, awesome lists are hosted on Github. They are plain Markdown READMEs. They use h2 and h3 headers for topics; ul tags for the link lists. They are unstyled, reminiscent of a wiki.

This plain presentation is possibly to its benefit—you don’t stare at the directory, you move through it. It’s a conduit, designed to take you to the awesome things.

Hierarchical But Flat in Display

Awesome lists do not use tags; they are hierarchical. But they never nest too deeply. (Take the Testing Frameworks section under the JavaScript awesome list—it has a second level with topics like Frameworks annd Coverage.)

Sometimes the actual ul list of links will go down three or four levels.

But they’ve solved one of the major problems with hierarchical directories: needing to click too much to get down through the levels. The entire list is displayed on a single page. This is great.

Curation Not Collection

The emphasis on “awesome” implies that this is not just a complete directory of the world’s links—just a list of those the editor finds value in. It also means that, in defense of each link, there’s usually a bit of explanatory text for that link. I think this is great too!!

Wiki-Style But Moderated

The reason why most awesome lists use Github is because it allows people to submit links to the directory without having direct access to modify it. To submit, you make a copy of the directory, make your changes, then send back a pull request. The JavaScript awesome list has received 477 pull requests, with 224 approved for inclusion.

So this is starting to seem like a rebirth of the old “expert” pages (on sites like About.com). Except that there is no photo or bio of the expert.

As I’ve been browsing these lists, I’m starting to see that there is a wide variety of quality. In fact, one of the worst lists is the master list!! (It’s also the most difficult list to curate.)

I also think the lack of styling can be a detriment to these lists. Compare the Static Web Site awesome list with staticgen.com. The awesome list is definitely easier to scan. But the rich metadata gathered by the StaticGen site can be very helpful! Not the Twitter follower count—that is pointless. But it is interesting to see the popularity, because that can be very helpful sign of the community’s robustness around that software.

Anyway, I’m interested to see how these sites survive linkrot. I have a feeling we’re going to be left with a whole lot of broken awesome lists. But they’ve been very successful in bringing back small, niche directories. So perhaps we can expect some further innovations.

I’m sorry to be very ‘projecty’ today—I will get back to linking and surfing straightway. But, first, I need to share a prototype that I’ve been working on.

Our friend h0p3^[1] has now filled his personal, public TiddlyWiki to the brim—a whopping 21 MEGAbyte file full of, oh, words. Phrases. Dark-triadic memetic, for instance. And I’m not eager for him to abandon this wiki to another system—and I’m not sure he can.

So, I’ve fashioned a doorway.

This is not a permanent mirror yet. Please don’t link to it.

Yes, there is also an archive page. I took these from his Github repo, which appears to go all the way back to the beginning.

Ok, Indieweb.xyz has been open for a month! The point of the site is to give you a place to syndicate your essays and conversations where they’ll actually be seen.

In a way, it’s a silo—a central info container. Silos make it easy. You go there and dump stuff in. But, here in the Indieweb, we want No Central. We want Decentral. Which is more difficult because all these little sites and blogs out there have to work together—that’s tough!

Ok so, going to back to how this works: Brad Enslen and I have been posting our thoughts about how to innovate blog directories, search and webrings to the /en/linking sub on Indieweb.xyz. If you want to join the conversation, just send your posts there by including a link like this in your post:

<p><em>This was also posted to <a href="https://indieweb.xyz/en/linking"
  class="u-syndication">/en/linking</a>.</em></p>

If your blog supports Webmentions, then Indieweb.xyz should be notified of the post when you publish it. But even if your blog doesn’t support Webmentions, you can just submit your link by hand.

How Indie Do I Need to Be?

One of my big projects lately has been to make it very easy for you all out there to participate. You no longer need a ton of what they call ‘microformats’ everywhere on your blog.

You literally just need to:

1. Include the link above in your blog post. (You don’t even need the class="u-syndication" part, but I would still recommend it. If you have multiple links to Indieweb.xyz in your post, the one marked u-syndication will be preferred.)
2. Send the Webmention.

It helps if you have the microformats—this makes it easy to figure out who the author of the post is and so on. But Indieweb.xyz will now fallback to using HTML title tags (and RSS feed even) to figure out who is posting and what they are posting.

The Blog Directory

A feature I’m incredibly excited about is the blog directory, which lists all the blogs that post to Indieweb.xyz—and which also gives you a few hundred characters to describe your blog! (It uses the description meta tag from your blog’s home page.)

I think of Indieweb.xyz as an experiment in building a decentralized forum in which everyone contributes their bits. And Indieweb.xyz merges them together. It’s decentralized because you can easily switch all your Indieweb.xyz links to another site, send your Webmentions—and now THAT site will merge you into their community.

In a way, I’m starting to see it as a wiki where each person’s changes happen on their own blog. This blog directory is like a wiki page where everyone gets their little section to control. I’m going to expand this idea bit-by-bit over the next few months.

Just to clarify: the directory is updated whenever you send a Webmention, so if you change your blog description, resend one of your Webmentions to update it.

Bad Behavior and the Robot Police

We are a long way off from solving abuse on our websites. We desperately want technology to solve this. But it is a human problem. I am starting to believe that the more we solve a problem with technology, the more human problems we create. (This has been generally true of pollution, human rights, ecology, quality of life, almost every human problem. There are, of course, fortuitous exceptions to this.)

Decentralization is somewhat fortuitous. Smaller, isolated communities are less of a target. The World Trade Tower is a large, appealing target. But Sandy Hook still happens. A smaller community can survive longer, but it will still degenerate—small communities often become hostile to outsiders (a.k.a newcomers).

So while a given Mastodon instance’s code of conduct provides a human solution—sudden, effortless removal of a terrorist—there will be false positives. I have been kicked out, hellbanned, ignored in communities many times—this isn’t an appeal for self-pity, just a note that moderation powers are often misdirected. I moved on to other communities—but I earnestly wanted to participate in some of those communities that I couldn’t seem to penetrate.

So, yeah: rules will be coming together. It’s all we have. I’m impressed that the Hacker News community has held together for so long, but maybe it’s too much of a monoculture. HN’s guidelines seem to work.

Commenting

Last thing. A recent addition is a comment count on each submission. These comment counts are scraped from the blog post. It seems very “indieweb” to let the comments stay on the blog. The problem is that the microformats for comments are not widely supported and, well, they suck. It’s all just too complicated. You slightly change an HTML template and everything breaks.

Not to mention that I have no idea if the number is actually correct. Are these legit comments? Or is the number being spoofed?

I will also add that—if you submit a link to someone else’s blog, even if it’s an “indieweb” blog—the comment count will come from your blog. This is because the original entry might have been submitted by the author to a different sub. So your link contains the comments about that blog post for that sub.

Really tight microformat templates will need to become widespread for this to become really useful. In the meantime, it’s a curious little feature that I’m happy to spend a few characters on.

So, HTML is a bit different on the distributed Web (the Dat network which the Beaker Browser uses, IPFS and so on) because your file history sticks around there. Normally on the Web, you upload your new website and it replaces the old one. With all of these other ‘webs’, it’s not that way—you add your new changes on top of the old site.

Things tend to pile up. You’re filing these networks with files. So, with a blog, for instance, there are these concerns:

• I want common things like headers and footers to be in separate files—because they bloat every one of my pages.
• I also want them in separate files so that when I change something in my header it doesn’t change EVERY PAGE in my site—pushing lots of changes onto the network.
• The trend with Dat seems to be that websites are delivered more as applications—where you could potentially access the underlying posts in a format like JSON, rather than just having a raw HTML dump.

Ultimately, I might end up delivering a pure JavaScript site on the Dat network. It seems very efficient to do that actually—this site weighs in at 19 MB normally, but a pure JavaScript version should be around 7 MB (with 5 MB of that being images.)

<link rel="include" href="/includes/header.html">

document.addEventListener('DOMContentLoaded', function() {
  let eles = document.querySelectorAll("link[rel='include']");
  for (let i = 0; i < eles.length; i++) {
    let ele = eles[i];
    let xhr = new XMLHttpRequest()
    xhr.onload = function() {
      let frag = document.createRange().
        createContextualFragment(this.responseText)
      let seq = function () {
        while (frag.children.length > 0) {
          let c = frag.children[0]
          if (c.tagName == "SCRIPT" && c.src) {
            c.onload = seq
            c.onerror = seq
          }
          ele.parentNode.insertBefore(c, ele);
          if (c.onload == seq) {
            break
          }
        }
      }
      seq()
    }
    xhr.open('GET', ele.href);
    xhr.send();
  }
})