Thanks for replying. Maybe I misunderstood something. The way I saw it, I can not use plakar without having to install Go first (the dependency). And that bothers me a bit.
Let me explain my reasoning. Suppose I made an .ptar archive today, put it on a USB stick, threw that in a vault and forgot about it. Ten years down the road I want to restore that archive. But the .ptar file alone is useless without the plakar tool. So I have to install plakar first. Ideally plakar should sit on that USB stick, right next to the archive, ready to be installed. But plakar is dependent on Go, so I have to hunt Go first. And who knows what the state of Go will be ten years down the road. The .ptar file that I made today may end up unusable ten years later, because Go evolved in some unpredictable way.
first, we're going to release pre-built binaries for various platforms with our next stable release which will remove the need to install a go runtime as you'll have a standalone native executable for plakar / ptar.
then, the format is open and we'll publish a friendlier documentation should someone want to implement their own builder/reader.
finally, it's likely we'll publish a library + standalone executable in C, so that people can easily implement a binding to their favourite language and/or have a small executable in a language that traverses the decades :-)
Let me explain my reasoning. Suppose I made an .ptar archive today, put it on a USB stick, threw that in a vault and forgot about it. Ten years down the road I want to restore that archive. But the .ptar file alone is useless without the plakar tool. So I have to install plakar first. Ideally plakar should sit on that USB stick, right next to the archive, ready to be installed. But plakar is dependent on Go, so I have to hunt Go first. And who knows what the state of Go will be ten years down the road. The .ptar file that I made today may end up unusable ten years later, because Go evolved in some unpredictable way.