With a name like "proxyHAM", there's a reasonable suspicion that it was indeed operating on an amateur band.

So on that site I see a long list of organizations that are nominally nonpartisan but would typically be classified as "liberal" (a lot of unions, "Code Pink", UfA, MoveOn), a few with technical issue-specific interest (EFF, FSF), a few corporations, and two Pirate Parties. But, the page answers the question "who opposes" with "In a word, everyone. Democrats, Republicans, ...". Is any organization on that list arguably Republican, or Conservative, in more than the sense that "a few members may have voted in a republican primary or argued with a republican politician some time during their lives"?

I'm glad to see IPv6 adoption growing, and that one of my home ISPs now provides IPv6 that the router I have connected to it autoconfigures without too much digging, but some of your points aren't meaningful to a "non-technical end user", and some aren't a clear benefit of only IPv6...

• - All protocols work over IPv6, unlike the breakage on IPv4. What's a "protocol"?
• - IPv6 "just works" without user setup, great autoconfiguration. Same could be said for IPv4 (plus UPnP, etc.) configured by DHCP behind a typical NAT device. And I've had to do a lot of tinkering to get IPv6 to work, although it's getting better.
• - As many public IP addresses as you want for devices on IPv6. What's a "public IP address"?
• - Safer because network security is built into IPv6, not optional. Not true. You can still run cleartext protocols (including telnet, plain HTTP, etc.) over IPv6. Some IPv6 RFCs may mention IPsec, but you can run IPsec over IPv4 or IPv6 about equally well.
• - Add IPv6 to see the whole Internet, not just the IPv4 part. Which is nonexistent right now, except for URLs used by the JavaScript in "Test your IPv6" pages. (There may be large private IPv6 networks out there, as well, but you can't see those just by "adding" IPv6.)
• - New quality of service features for stutter-free video or gaming. You mean DSCP, which is also defined for IPv4?
• - Faster networking for a better all-round user experience. Possibly. For applications like Skype or player-to-player gaming, in situations where both users had a NAT device without UPnP or other traversal support, the service provider's server will no longer be a potential bottleneck, and RTT should be reduced. For BitTorrent, users would already have been using NAT traversal or port-mapping, so no real change. For the all the client/server stuff, maybe a router could be designed with a faster fast-path for IPv6, but are such devices in wide use yet? Or will they be within the next 10 or even 15 years?

My dad uses AOL (webmail, not dialup), he's younger than 70 but not by much.

However, my younger brother also uses AOL... about a year ago he got a gmail account, but last time I sent him mail at his gmail address, he didn't respond, and when I called him he said he hadn't seen the message. Then I re-sent the message and CCed his AOL account, he answered from there. So, I haven't seen the UI myself, but I'm sure it's "good enough". He's hardly a tech newbie; has a BS in physics, currently in grad school.

+1 on the self-hosting. For outgoing e-mail there are various "email send" services aimed at transactional e-mail from cloud-hosted applications but that are easy enough to point Exim or whatever at. For incoming I guess it would technically be "running a server", and might be iffy on dialup, but I've never used an ISP that actually blocked incoming port 25.

Does this mean that the 2012 patent to PKware for high-strength encryption applied to individual members of an archive, #8090942, is ripe for challenge?

Actually, the article (and if I understand it correctly, the report) doesn't recommend the "127.0.53.53" solution for ".corp" and ".home". It recommends that those be kept permanently unassigned and unassignable in the global registry, similar to ".test" and ".invalid". The "127.0.53.53" solution is one of the "emergency response options", maybe if some widely-deployed software sends unencrypted security-sensitive logs to "logserver.corp" by default, or if some seemingly-innocuous top-level TLD turns out to contain a similar widely-deployed security-sensitive name after people already start registering names.