FR: Add HEN Support for position import, export, and teaching games

[hemme]

I am the author of HEN, a new serialization format specifically designed to represent static positions in Go (similar to how FEN works for Chess).

HEN format was born out of the following vision: «Imagine if we could share [kifu diagrams | tsumego | joseki] images (PNG+hen) and study them directly in our favorite app.»

To achieve this, I suppose one should proceed step by step: first, by integrating HEN as such (as in this FR), and then by allowing PNG import and export (which could be a separate FR).

All-in-all I believe this format (HEN) would be a great addition to libaduk.com and I would like to suggest the following features:

• Create a scratch board from a HEN string: Allow users to generate a scratch board directly by parsing a HEN string.
  Import/Overlay HEN position: Add the ability to import a HEN position and overlay it onto the stones already present on a scratch board.
• Export to Clipboard (scratch mode): Implement a function to copy the HEN representation of the current position on a goban directly to the clipboard.
• Export to Clipboard (Review mode): Similar to the above, but allow copying the HEN representation of a specific position from a goban of a finished game or variation.

I would also be happy to help with the implementation.

BTW: if you want to mess around with HEN and PNG+hen artifacts, see:

• PlayGo - a free educational toolkit: https://hemme.github.io/playgo/goban.html
• HEN Worker: an open-source Cloudflare worker that processes HEN strings and produces goban PNG on the fly (e.g., https://hen.hemme-dev.workers.dev/cx/hen.13x13_13GbwMw_12Fbw3Lbw_11Fb2wLbw_10Gb2w2bw_9Jb2w2.b.png)
• hen-python: a library to handle HEN (supports hen2sgf and sgf2hen, embeds HEN into PNG, and extracts HEN from PNG+hen)
• hen-js: another library to handle HEN (supports hen2sgf and sgf2hen, embeds HEN into PNG, and extracts HEN from PNG+hen)

Thank you for considering these suggestions!

[Seth-Rothschild]

I'm theoretically open to this, but I have to admit to not being a user with the problem that I think HEN is trying to solve. That's not to say it's not a real problem! It's just not one that I've wrapped my head around.

Would you be able to tell me a bit more about the pain point and bad user experiences this is trying to address? If I'm understanding correctly the flow would be:

1. I'm a person who wants to share a (Joseki) on say (the OGS forum)
2. Right now to share it I would have to:
   a. Go write it out the board position somewhere (e.g. some local app like Sabaki or on a demo board on OGS or on Libaduk)
   b. Get a picture of it with a screen capture
   c. Share it somehow to make it interactive, either with a link to where it was created or in SGF form and hope that the SGF implementation is sufficiently clear about where it should start new users and how to handle wrong moves?
   d. If you want users to play it on multiple sites, upload the problem separately to multiple sites

Is that roughly the flow and the pain point? If so, what's the expected flow with HEN

[hemme]

A couple of expected flows involving PNG+hen (or just HEN):

A. Draw the layout anywhere HEN is supported. Share a PGN+hen picture (that's simply a PGN with HEN metadata) somewhere (r/baduk, Telegram, Whatsapp, email... a post in your club's website, a page at SL....).
Import / open the PGN+hen on your favorite app (Libaduk, KaTrain, AI Sensei, Sabaki...) and you are done.

B. Share a link to a HEN-worker: the HEN will be part of the resulting URL (HEN is URL-compliant by design). People navigate the link and get the PNG+hen image in their smartphone.
BTW, some platform could generate the PNG just when you paste the URL. E.g. Telegram builds the PNG as a preview, on the fly, so you don't even have to bother with downloads and uploads on your smartphone.

C: Print a QR code embedding a HEN string (or a URI like web+hen://<hen>) then let every body to open a position with any HEN-compliant app.

D: Use your clipboard to transfer a HEN position from app A to app B or to the hen part of a HEN-worker URL so it can build a PGN+hen image.

BTW, almost every use-case can involve just SGF in place of HEN (apart from the HEN-in-the-URL case, since SGF would need extra byte for the URL-encoding). Anyway HEN is roughly 50% shorter than SGF (and, for example, this would lead to better QR codes, shorter URLs and so on).

[hemme]

If it can help, I wrote a functional manifesto about HEN and PIC+hen (PNG / GIF)