add default.nix which can produce ps and pdf files

[apoelstra]

Will also patch the git commit into the "revision" variable which appears in the ps output, if told to build a git repo rather than the current source tree.

[apoelstra]

Force pushed to a .nix which more closely matches the file I'm actually working with to add the full booklet contents, color, etc.

You can see how the dependency management is going to work, once we break up the setup code into more than a single file, and we output the full booklet, but it's hopefully clearer how we'd output other documents too.

[roconnor-blockstream]

99463184ca456853d5624e3830d439fd58ddd933 seems to add an extra blank line on line 2060 for no good reason.

[apoelstra]

@roconnor-blockstream I'll check on the "no good reason" blank line while in flight today, but I suspect that it's there because Nix multiline strings always end in a newline (or is it that they start with a newline? I forget), so if we don't have these newlines in the target output, it forces you to cram lots of stuff onto single lines.

Edit no, this one was indeed for "no good reason" :) I'll remove it.

[apoelstra]

@roconnor-blockstream pushed new version which

• Renames nextCtIdx to nextFooterIdx to match my local "complete" branch and to reflect that this value indicates the page number to be drawn in the footer, not an index into any content
• Removes the extraneous blank line :)
• Splits the page tests and diff into a checkPhase section and added a doCheck flag
• Minor refactorings

[apoelstra]

Rebased to address commetns.

[apoelstra]

Will undraft when this is ready for review again. Hopefully today or tomorrow.

[apoelstra]

Restored the old cp line rather than using ln -s and relying on sed's magic link-replacing behavior.

Added Makefile which figures out the git commit ID and passes it to nix.

[VzxPLnHqr]

@roconnor-blockstream @apoelstra Apologies to barge in on this PR, but it seemed the most relevant location given that you are nixifying codex32 things here and that would be immensely helpful.

I have a (currently failed) attempt to add apoelstra/volvelle-website to nixos-airgapped. My attempt is failed currently because there is some sort of permission error when trying to run wasm-pack and my rust/nix skills are not the greatest yet. You may be able to diagnose in 30 seconds and it would be greatly appreciated!

Also, is that volvelle-website repo even the correct one to be doing this with? I noticed that this repo seems to have more activity. Do you intend to add some sort of nix build .#codex32-offline-website magic to this repo that builds the static website?

[apoelstra]

You may be able to diagnose in 30 seconds and it would be greatly appreciated!

Afraid not. I just checked my local nix CI scripts to see if I got wasm-pack working, and the answer is no, I only have wasm-pack code in one place, and it's all commented out with a confusing explanation. Unfortunately wasm-pack is a nightmare to use in an airgapped context, because it downloads random crapand does not respect lockfiles.

Also, is that volvelle-website repo even the correct one to be doing this with? I noticed that this repo seems to have more activity.

Yeah, this repo is where the "real" work is happening. The website is more-or-less a demo and an aid for doing workshops. (I think I will do one in October at TABconf so probably you'll see a bunch of activity there in the week(s) leading up to that, and nothing until then.)

But you raise an interesting point that we should have a self-contained "codex32 tool" that people can build and use locally. WASM is nice because you can run it in the browser and easily have nice interactive interfaces, but it's pretty awful in every other respect.

One soluion for you would be to just build the site and nix-package the binary output....that'd fly in Nix land even though it wouldn't fly in Guix. But I definitely understand if you refuse on principle to do that!

Do you intend to add some sort of nix build .#codex32-offline-website magic to this repo that builds the static website?

Probably not, unless we can get away from wasm-pack. (Which honestly shouldn't be too hard ... in theory I just need to run cargo with a wasm32-unknown-unknown target and then write a tiny bit of glue code ... but I don't know how.)

[VzxPLnHqr]

...see if I got wasm-pack working, and the answer is no... Unfortunately wasm-pack is a nightmare

Thanks for your reply and suggestions. It does give me some comfort that it was not just me who was unable to figure out the wasm-pack stuff with nix!

Regarding a self-contained "codex32 tool," agree that would be helpful.

[VzxPLnHqr]

I opened a PR to the website repo with a flake such that nix build .#codex32-website will put a static copy of the website in ./results/www.

[BenWestgate]

...see if I got wasm-pack working, and the answer is no... Unfortunately wasm-pack is a nightmare

Thanks for your reply and suggestions. It does give me some comfort that it was not just me who was unable to figure out the wasm-pack stuff with nix!

Regarding a self-contained "codex32 tool," agree that would be helpful.

@VzxPLnHqr: What features are you expecting a self-contained "codex32 tool" to have? I may have already made one.

[VzxPLnHqr]

What features are you expecting a self-contained "codex32 tool" to have? I may have already made one.

@BenWestgate I have not played with it too much yet, so maybe a self-hosted / static version of the website will suffice? (such as as what I added to nixos-airgapped ). But a simple command line interface could be nice too. Is that what you have made already?

[BenWestgate]

What features are you expecting a self-contained "codex32 tool" to have? I may have already made one.

@BenWestgate I have not played with it too much yet, so maybe a self-hosted / static version of the website will suffice? (such as as what I added to nixos-airgapped ). But a simple command line interface could be nice too. Is that what you have made already?

Yes, https://github.com/BenWestgate/codex32/blob/master/reference/python-codex32/src/codex32.py has functions for all sorts of codex32 needs.

I started working on a Gtk GUI for importing with error correction: https://github.com/BenWestgate/bails-wallet/blob/master/bails-wallet/string_entry.py I think it was meeting most or all of the criteria of https://github.com/BlockstreamResearch/codex32/blob/master/docs/wallets.md when I last tested it.

These were originally for my project https://github.com/BenWestgate/Bails which uses the python library above to support creating codex32 backups and importing them to Bitcoin core. If andrew's bitcoin/bitcoin future PR https://github.com/bitcoin/bitcoin/pull/27351#issuecomment-2059322038 gets merged most of that code except my GUI and error correction can be deleted.

[roconnor-blockstream]

Page: 1 1 seems to now have portraitPage begin twice. Presumably this is an error

[apoelstra]

Oh, good catch. This appears in title.inc.ps but shouldn't because the default.nix code now does it.

[apoelstra]

Fixed.

[roconnor-blockstream]

Oh, good catch. This appears in title.inc.ps but shouldn't because the default.nix code now does it.

Maybe I'm being too picky, but you patched the wrong commit. You should have put the title.inc.ps patch in add version to footer; use portraitPage and landscapePage on every page. However instead you patched nix: generate postscript file from include files.

nix: generate postscript file from include files was supposed to be a nop with regards to the SSSS32.ps file, but now that files has a diff in it, a diff that gets reversed again in add version to footer; use portraitPage and landscapePage on every page.

[apoelstra]

I don't think you're being too picky. Though I'm surprised I made a mistake like that, given that I used git blame to zero in on what I thought was the correct commit, and then ran nix-build on every subsequent commit which showed that the SSSS32.ps file was consistent with the nixfile.

I'll fix the history. Sorry about that.

[apoelstra]

Ah, I see the issue. I was misled by git blame (or perhaps, misled by my weird PR structure where I introduced code intending to later modify it).

Fixed.

[roconnor-blockstream]

Are you familiar with gitattributes's export-subst?

Bitcoin uses this to insert a define GIT_COMMIT_ID into this file. This method might make for a better way adding shortids to the (generated) postscript.

[apoelstra]

No, I am not familiar -- though it looks like it needs git-archive to work. I am averse to using git-archive, especially the way Bitcoin Core does, because it interacts with nix in unpredictable ways. (For example in rust-bitcoinconsensus when I try to verify that the vendored Core code matches the relevant Core commit, I have a giant list of whitelisted files which seem to be .gitignored in one case but not in the other, and files which always have diffs that I can't reproduce locally, presumably because they are done by git attributes.)

I can go learn all these things if you want but I feel that my existing way, which behaves predictably and uses explicit code, will be easier to maintain.