Bcc

IndieWeb folks,

While privacy was not the most common topic at #indiewebcamp earlier this summer, I think the independence of controlling one's own Web presence has a lot in common with freedom from surveillance.

In that spirit, I thought you all might be interested in the 1984 Day rally, taking place this Sunday, 1pm (after the Doctor Who live stream, of course) on the Embarcadero. The Web page for the event suggests, apparently without any irony at all, RSVPing on Facebook, but I thought an email/blog post was a more appropriate way to tell you all that I'll be there. Daniel Ellsberg (of the Pentagon Papers) will speak, among others.

Hope you're well and to see you soon,
Nick

P.S. Can you RSVP to an event within the description of an event itself? Test case: the paragraph above.

Hi Ben,

Thanks for the invitation to the post-unconference unofficial meetup; I send my post-facto regrets.

Of course, this email slash blog post is also an attempt to RSVP using the proposed microformat and WebMention. We'll see how it goes, of course, as this sort of indieweb interoperability isn't something one can easily test within the isolated safety of one's own environment.

Implementing is of course the best way to find bugs. For example, wouldn't it be great if WebMention explicitly noted that the mention operation is idempotent so that I wouldn't feel bad about repeating the WebMention POST when I re-generated my static site content?

All that aside, nice meeting this week. Let's have more of these RSVP-able events in the Bay.
—Nick

Hi Seb,

(CCing Mohit and Brooks, with whom I've been having these conversations in San Francisco cafes.)

Thanks for getting this conversation started, formally, with your blog post. I appreciate both the prompt to think about my own tooling for paper-writing and dissertation-writing (which I hope to be a single process) and the requirements/resources dump you provided. I'm afraid I too missed the Scholarly Markdown workshop (reading about the NSA and recovering from PLSC made me oversleep), but instead spent the weekend reading up on the relevant tools.

And I'm also shocked, on reading through the resources you mention and following a few (dozen) links on my own, to find that this problem is much closer to solved than I would have guessed. Zotero, Mendeley, Dropbox, BibTeX for gathering references and papers and exporting them for reading and review on devices; then Markdown, Pandoc and [pdf]LaTeX for writing and rendering papers; and GitHub, Hyde and gh-pages for version-tracking, hosting and presenting.

Mohit and I just finished a workshop paper a week ago. As is our wont, we started writing text, in Markdown, version controlled and hosted in GitHub. To fit the paper template, we had to switch over to LaTeX at some point (we clearly did not even consider using the .doc template). It's a simple enough process, and I'm familiar with LaTeX from teaching it to myself one weekend in college in order to write up a physics lab report with the equations nicely formatted, so I did the conversion manually.

The conversion process, while not long, was slow enough that I only did it a couple times, and eventually had to stop accepting changes from Mohit in Markdown. And the biggest issue I noted was around citations -- Mohit and I hadn't natively used \cite{} syntax, of course, or had any stable convention on how to refer to cited works. But I was pretty excited when I realized that Mendeley, in addition to having a nice feature for synchronizing out to a BibTeX file, has a handy shortcut (Command-K) for copying the Citation Key in LaTeX format. And I hadn't realized it at the time, but Scholarly Markdown and Pandoc both suggest the use of these citation keys, with the convention of prepending an @. Thanks to citeproc-hs, we could write in Markdown with occasional references to @Whitten1999 and with a script running Pandoc and a library.bib and appropriate CSL (another standard, who knew!), render out to HTML while writing/reading and eventually to PDF through a conference-specific LaTeX template.

While Jekyll is tempting, I agree that we academics seem to be tending more towards Python than Ruby; fortunately, there's Hyde. Mohit and I are rendering static pages for Privacy Patterns (hey, that's what the workshop paper I just mentioned is about) by writing in Markdown in a GitHub Wiki and then running scripts around Hyde to generate template-based static HTML, which is what you see at http://privacypatterns.org. With post-commit hooks written in some combination of Pandoc and Hyde, I'm confident that without writing any entirely new libraries of code, we can automatically publish our academic writing in progress just by typing `git push dissertation master`. Ah, I look forward to that.

—Nick

P.S. Yes, this doesn't answer any of your requirements about integrating academic review and commenting into this online academic work, which hasn't been as much a priority for me, but rather clearly should be. Maybe something will come of open standards for Web annotation. Or does Github's functionality for inline commenting for code review work for us?

P.P.S. You want to know the biggest open problem I have right now? Usable diffs of changes to plain text documents. I'm confident this should really be a trivial problem, but as it is right now I can't easily see what the changes are within a single line of text in a Markdown document. In working with computer scientists in the past, this has led to awkward solutions like hard-wrapping paragraphs at 78 characters (so that line-by-line differences are closer to usable). Nice diffs for reviewing changes is essentially what will stop me from getting Deirdre and other lawyers on board with this being our collaborative writing process.

P.P.P.S. Okay, and I have a handful of other open questions too. Does this work for collaborative writing or just for an individual dissertation? Do we make these repositories public or private during the writing process? Is a dissertation one giant repository, or do we set up repos for each project, paper or deliverable and then a "dissertation" is a set of configuration files which compile these repos into a nicely readable Web site with its own domain name?

If you were building a new platform, a platform that you fully and confidently expected to be the future of computation, would you want its most commonly cited advantage to be "cheaper than other laptops"? Do you think that kind of positioning would motivate cutting-edge development? Would you expect consumers to be excited about a device — even one with functional advantages over its alternatives — when they've only seen its category as the cheaper and lower-build-quality version of what they have now?

Or would you want there to be a premium, interesting, even exotic version, to demonstrate the possible future of the platform? Would you want developers, early adopters and advocates to have the opportunity for something luxurious to inspire pride and comfort? Would you want to highlight that in fact what makes the Web so amazing is that it's the kind of platform that can run effectively on cheap, even disposable devices with limited form factors and also on immaculately-designed high-end machines perfectly suited to it?

I don't think the Pixel will be a top-seller. I won't recommend it to many of my friends and family, including the ones to whom I've recommended or even outright given cheaper Chromebooks. But I want one, even though I can't really afford it. And I think that's a nice feeling to have about a Web-dedicated device.

—Nick

Please see attached comments, also publicly available at: https://www.w3.org/2012/04/ntia-multistakeholder-comment.html

Nick Doty
Privacy
World Wide Web Consortium