The search bar can currently only search hashes. This is because the only way afaik to get information from pijul changes is using the pijul CLI program. Which is very slow. So no data other than the hashes is currently loaded. For a selected change more information is loaded upon selection.

I made a GUI for pijul using Avalonia.FuncUI for F# (.NET). The syntax for F# is also based on ML, so it shouldn’t be all that different from OCaml that pijul is written in I assume?

I am using pijul version pijul 1.0.0-beta.11, built from source on Windows. With some own modifications to get it compile, as I explained in another topic (it seems unmaintained?).

I tried to fix the compilation errors in the pijul-gui project that is still on nest dot pijul dot com (to avoid 2 link limit). I assume that is a re-upload of this project that seems to have been removed by the original developers? But struggled to configure a remote and pushing using pijul. I somehow got it uploaded once (see pijul-gui-fork), but a lot of changes I wrote were not actually recorded and ended up being reverted.

So I could use some help on how to use pijul. I read all the documentation, but still can’t figure some things out.

The title of the GUI app is tijul, based on what I read on the Spanish (es) Wikipedia page Crotophaga sulcirostris.

Here is a screenshot:

Unfortunately pijul is still relatively unknown in comparison. And we know that the popularity/ubiquity/familiarity of a VCS tool is quite important.

Thank you for your long response, it largely echoes what i figured when i wrote the question. But obviously as a new incomer, i was curious what more experienced people in the area of research thought.

I have since spent more time reading the theory of Pijul and watching talks and I’m quite excited to dive in!

Properly handling conflicts using a single set of operations (for both “usual” ones and conflict-related ops), is several orders of magnitude harder than what the author describes. Part of the theoretical foundations of Pijul rely on a mathematical proof that the structure we use is the simplest possible that handles conflicts well, and that rather abstract structure required a huge effort in low-level system programming. The ability to do both isn’t common. Concretely, Pijul is based on maths (categories, graphs, complexity), yet required its own key-value store (the Sanakirja project) in order to implement branches. That key-value store also ended up being the fastest known on-disk key-value store (Pijul - Rethinking Sanakirja).

The main contribution of that blog post seems to be related to showing conflicts to the user in a nicer way than Git, which is certainly an important feature. However, the main problem with Git has nothing to do with that: the main problem with Git is that rebasing and merging are heuristics based on content similarity, with no model of conflict resolution.

I don’t think rediscovering Pijul accidentally is even possible. I know how incredibly hard it is to get these things right. The fact that no bibliography at all is mentioned in the blog post isn’t a very good sign of seriousness: indeed, a basic rule of research is that you can’t go very far without understanding what others have worked on. In particular, there have been multiple attempts at doing “CRDTs for version control” (I forget the names right now, but also I’m not writing a blog post), Mercurial is innovating way faster than Git, Pijul has been around for 10 years…

From the comments of this I found Pijul. I find this approach to version control very interesting but as an obvious newcomer, I am not well versed in the intricacies. I was hoping for some input from people who already knew about this and were involved, is this an ‘accidental’ copy of Pijul? Are there ideas here that are different?

Obviously it is much less mature, it is barely a python script currently. But I guess I just wanted more experienced input!

And the issue is not the mail alias, it is probably the mail server, because I also tried it with a proton mail.

Since I want to save it somewhere remote, I tried to make an account here: https://nest.pijul.com

But I used an E-Mail alias from addy.io, something like: [email protected]

And got this error:

The email could not be sent. Please check the address, and try again later.

The mail is valid (used it to make this forum account), aliases are probably disabled for spamming reasons, is it somehow possible to allow mine? or what should I do?

#[cfg(not(unix))]
- fn pager(_repo_config_pager: Option<&pijul_config::Choice>) -> bool {
+ fn pager(_config: &pijul_config::Config) -> bool {

And I used a portable openssl build from Download Free OpenSSL Windows Installers & ZIP Files , and ran (in powershell)$env:OPENSSL_DIR="PathToUnzippedOpenssl"before running cargo build.

Now compilation worked.

I could go through the pijul identity new prompt to generate a key, something that is not documented in Uploading public keys - The Pijul manual .

But then pijul identity prove [email protected]caused an exception:

thread 'main' (38592) panicked at <RustupPath>rustup\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\clap_builder-4.5.53\src\builder\debug_asserts.rs:732:9:
Argument 'no_keyring' is positional and it must take a value but action is SetTrue
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

So I still can not push anything to nest dot pijul dot com it seems?

pijul identity new --no-link --no-prompt --display-name 'Test User' --email '[email protected]'

Unfortunately, this gives me the following error:

Error: Cannot get path of un-named identity

I searched for this error message, and I found pijul/pijul - Discussion #953 - Regression: pijul identity new --no-prompt never works, which has a couple of patches that were merged recently. Would it be possible to get a new beta release that includes those patches? Or, alternatively, is there another way that I can create an identity non-interactively, that works on beta.11?

1. Based on pijul/pijul - Discussion #936 - [ID] do not stuck in pijul if without identities ↩︎

In other words, if I accidentally delete a file I just re-copy the file from the upstream source.

The main way to contribute is by testing I think, and seeing what you like and don’t like. There are a few remaining known bugs, but they’re so niche that unfortunately I might be the only one that can fix them.

The open source version of the Nest, which I’d like to turn into the actual nest, needs a lot of love (pmeunier/nest). It’s written in a mixture of Svelte and Rust.

My background is in Computer Science and Math. I found out about Pijul through a friend, and got interested because I enjoy category theory. I am reading through the paper that inspired Pijul, but I have heard that it has undergone significant changes since then.

I admit, I am a bit confused how I would get started with contributing. Looking for any resources that explain the current state of Pijul and some of the theory behind it now.

Best,
Coy

The Git experience in version control feels like the C++ experience in programming languages—gotten so messy with all the various options and features that it is a pain to learn and debug.

The Pijul experience in version control feels like the Go experience in programming languages… a breath of fresh air… and a bliss of using an elegant and user-friendly piece of software/solution that just works rather than being a Frankenstein monster that you need to constantly fight in a 100 different ways.

I feel Pijul deserves the chance to prove itself in a real-world production environment so that the world can really take notice of what it is capable of. This would let the world see what Pijul can do for projects. It could be the boost that can bring Pijul to mainstream.

I understand that there maybe high costs to changing a core part of existing tech stack for most large teams but it feels like the world is missing out a lot. I feel holding on to legacy like its the ultimate truth, neglecting its pitfalls… would make the world miss out on the joy of programming and the effectiveness of being efficient. A good version control system should stay out of the way of the programmer, so that the the programmer can focus on what they are here to do… programming. I feel that the world should try out emerging technology like Pijul so that there can be a transition from high-friction legacy software to productivity enabling software that stays out of the way of the user.

I am just a beginner, would love to know what you all think.

3.7G	.pijul/pristine
1.9M	.pijul/changes
  0B	.pijul/identities
3.7G	.pijul

  du -h -d 1 .pijul

  pijul debug > /dev/null # printed ()

• The compressed patches containing the actual contents of changes to your files. If you’ve made large changes to binary files, this could get big, especially if files are hard to compress.
• A datastructure which I’ve been meaning to store compressed for a long time now, but never managed to find the time. I’m still hopeful that I’ll be able to finish these things in 2025.

I’d be interested to see which of these is heavier, would you mind running something like du -h -d 1 .pijul ?

Also, pijul debug > /dev/null checks for corruption, which is unlikely by now, but may bloat your .pjiul

Looks like things have been quiet for a while. Any chance that I can get an update on the project? Sorry if there actually has been other activity around the site, I’m new to using Discourse. I noticed that there is also a Zulip and a Reddit, but I am most familiar with Discord. Any chance that one exists?

I’m Seraiah. I have a math and cs background and am familiar with a number of different languages. I just read the rust book recently and figured I aught to try a project. At the same time I’d like to learn to use pijul and maybe contribute at some point.

1. Replacement in ".ignore":4 4.32 "UTF-8"
B:BD 3.5 -> 2.0:2/2
  up 3.5, new 1:20, down
- l
+ dddaaaaaaaa
+ tttttl

I can delete any of the added lines without changing the metadata of the hunk, and it does exactly what I want: it only records the remaining ones, which to me works better than having a staging area. However, when I deleted the deleted line, the change was recorded anyway, as if I hadn’t touched the hunk at all.

I guess I need to change the metadata somehow to be able to exclude deletions, or any complex changed, from being recorder. Is this syntax explained somewhere?

is there something going on with the Nest ?

any help is greatly appreciated !

It’s just like the birthday paradox, where if you have 20 people in a room, then often 2 have the same birthday, but instead of a square root, the attacker benefits from the k-th root.

We stop the attack by working in some group that has a hard discrete log problem, like a secure elliptic curve. We’ve no secrets here so how we create the groups elements matters: If we create curve points using scalar multiplication, or create large finite field elements using exponentiations like your manual describes, then the attacker can run the attack in the scalar field or in the exponent. If otoh we hash-to-curve then nobody knows the scalars that relate those group elements, so the attacker must now work in the elliptic curve itself, but if they’d an algorith that worked here then they’d break the discrete log problem itself, so that’s impossible.

This is great for you because hash-to-curve is by far the fastest way to create a fresh elliptic curve point anyways. A “slow” hash-to-curve works by rejection sampling the x coordinate and solving the curve equation to see if some y coordinate exists. This succeeds half the time for fast curve, so already a couple hundred times faster than a scalar multiplicaiton, which itself should be 10 x faster than your exponentiation. RistrettoPoint::from_hash should be somewhat faster still.

Also an unrelated issue..

Your shallow clones might already be vulnerable to some unrelated subtracted patch attack on shallow clones. This fix would not change the status of this flavor of possible attack on shallow clones.

An accumulator would fix this possible attack, but they are extremely expensive. It’s likely cheaper to fix in other ways, like by having shallow clones do some validation that patches provided leave no “holes”, or going back to some signed check point of known good versions. Accumulators would provide no benefits except for shallow clones.

The adversary creates k buckets B_i each containing thousands of unrelated patches. Their attack algorithm identifies several distinct mappings f_j such that f_j(i) lies in B_i, but all the f_j yield the same combined product, aka H(f_j(0)) * H(f_j(1)) * … * H(f_j(k)) is the same for each j. This means each pair of f_j defines a colliding patch set.

All the patches in B_i are good for i>0, but half the patches in B_0 are malicious, so many of these f_j use all good patches, while many of the f_j contain exactly one malicious patch.

They submit one honest patch set that gets merged, after which they convince others that the dishonest patch was merged, maybe using signatures or web posting of the version identifier.

If you use David Wagner’s original attack, then you need roughly k=128 buckets, aka 128 patches in both the good and bad patch sets.

There is a faster attack that needs only k=16 buckets, but comes with more constraints, which I’ve now forgotten.

Do other VCSs have similar problems?

Very unlikely. Afaik, only a patch based DVCS would employ some commutative algebraic version identifier, but others like darcs might never have thought of doing so.

Actually exponentiations are vulnerable to generalized birthday bound attacks, since the adversary would know their own hashes, and the discrete log problem is easy in the exponent where your hashes occur. In concrete terms, an adversary would compute the hashes for many buchets of possible patches, then identify some version identifier product which they could obtain through many different selections of one patch from each bucket.

We discussed two defense mechanisms before:

• Cryptographic accumulators remain extremely expensive, but would prove that a bare identifier consists of accumulated hashes, without any patches being subtracted.

• Addition of hashes-to-elliptic-curves avoids generalized birthday bound attacks nicely, while being extremely cheap, far cheaper than exponentiations or scalar-point multiplication.

Addition of hashes-to-elliptic-curves is not an accumulator, but afaik you’ll only care when faced with shallow clones taken from adversarial repositories. Addition of hashes-to-elliptic-curves should siffice either (a) if shallow clones already involve some trust element anyways, or (b) if shallow clones make no sense anyways, or maybe (c) depending upon what patch state shallow clones do contain.

Anyways..

Assuming addition of hashes-to-elliptic-curves suffice, I’d expect RistrettoPoint::from_hash and RistrettoPoint: ops:Add in curve25519_dalek yield about the fastest implementation, since few elliptic curves have such a nice base field.

Also, there is no real change in how you hash patches per se, only in how you compute the version identifiers from the set of patches.

I’m just wondering if there is a clear reason why pijul’s behavior (in the graphic) is deemed more correct. It appears to me you have to guess what operations occurred between two file versions, and this graphic shows two different guesses.

I don’t know that the Pijul choice is any more correct, but it is likely to also be sensitive to the order of the patches you have. Many times, I pull the pijul repo and it gives order conflicts on Cargo.lock (and that’s with me making no local changes).

Neither tool knows the editing details of the file, but they do store different information about the “commit” made. They apparently have different algorithms for merge.

The “takeaway” in the above screenshot, is that Git merge arbitrarily places X. But, I also see Pijul’s merge as arbitrary. Am I missing something?

How does Pijul infer that lines A, B get prepended to the file. Technically it only sees the file A\nB\nG\nA\nB. It doesn’t know how that file was arrived at. It would need to know the operations performed on the file to know how to complete this unambiguously. For example, suppose that Alice does this sequence instead which produces the same state. From G\nA\nB: Shift A to the top of the file producing A\nG\nB, Inject B on line 2 producing A\nB\nG\nB, then insert an A between last two lines producing A\nB\nG\nA\nB. Is there a reason this sequence is not inferred? It’s just more edits?

Nest is open source now, but if I recall correctly there is a new version of Nest in development. The repo of the current open source Nest says contributions are accepted, though

If that fixed it, the issue would likely be a version mismatch between nest and the versioned release of pijul, in my admittedly limited understanding of the problem; nest’s source code is not public (see pijul/pijul - Discussion #963 - Thrussh should be updated to fix push command for nest)

As for contributing, being new (this is my first interaction with people using pijul in fact, hi!), I can’t comment on how to contribute, I feel like the manual book wants to make me believe that the repo’s discussion section is the place for this to happen, but far as I can tell while it does get some talks going, it seems incredibly stale in the case of pijul/pijul itself, the above issue is merely a version bump, has been known since February, and still hasn’t been merged

I recently discovered Pijul and found the mathematical theory very appealing. I’m using it for my current projects now and I’m curious to see how I’ll experience using it in the long term, compared to Git. I’m particularly interested in learning about the workflows or methodologies that people apply in Pijul, and generally principles to apply to get the most out of it.

Until now I’ve been doing version control with GUI tools, and while I’m getting along fine with Pijul’s CLI, I’m going to try creating a graphical Pijul client, to be based on the libcosmic GUI toolkit. I’m not sure if I’ll ever finish it, but it should be a good project for me to learn both how well Pijul works for the development of a large project, and simultaneously learn about the internals of it.

I ended up continuing this project with darcs, since darcs already has the ability to clone a repo from a static directory, and the aforementioned darcs show contents command has been useful when generating the site. I’d love to make this project also work with pijul, but given that I haven’t written a single line of rust before, I’m not sure if I’ll be able to implement those features myself.

The project site (showing its own code) is here if you’d like to check it out: https://repos.tuckerm.us/repos/eleventy-darcs/branches/main. I plan on posting more updates on the darcs-users mailing list.

I’ve included troubleshooting logs below for reference. To dive deeper, I’d like to access Nest’s source code and set up a test environment. Could someone guide me on how to get involved in this way? Alternatively, if there’s a known technical issue with Pijul, resulting in reduced engineering activity on the platform, I’d appreciate an update. I haven’t noticed much recent development, so any insight would help.

Thanks for any assistance or pointers on contributing!

Trouble Shooting Logs / ssh connectivity to nest:

• MacOS Version: 11.7.10
• Pijul: Installed via cargo install pijul --version “~1.0.0-beta”, version 1.0.0-beta.9

SSH Key Setup

• Generated: ssh-keygen -t ed25519 -C “EMAIL”

• ~/.ssh/config:

Host nest.pijul.com
    HostName nest.pijul.com
    User highvibe
    IdentityFile ~/.ssh/id_ed25519

• Public key uploaded to Nest: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILcrtP23IcXI5dAgI8l6i9LXx+L0G8EKb0kBvxxEJRGQ EMAIL

pijul identity

• pijul identity new (selected “no” to SSH key prompt to avoid hang):

~/Library/Application Support/pijul/identities/highvibe/identity.toml:
username = "highvibe"
email = "EMAIL"
origin = "nest.pijul.com"
[public_key]
key = "EJbs1yQA8Tdh9WnbD8TjtHyHn6KbtgYk4UXXTxCKVsUF"

[public_key]
version = 0
algorithm = "Ed25519"
signature = "2hgzvQijSacV3QJ6Z4iCUuv6LZQjDSCPDKd81yphyPTy7PpqidQ9gapq4oJnSVtLCED2CkEZFiEiHJa6JbwpMb7R"
key = "EJbs1yQA8Tdh9WnbD8TjtHyHn6KbtgYk4UXXTxCKVsUF"

identity prove Fails

• RUST_LOG=“pijul=debug” pijul identity prove highvibeAT[nestHOST]

  [2025-04-03T20:14:01Z DEBUG pijul_remote::ssh] Trying key Ed25519(...)
[2025-04-03T20:14:01Z DEBUG pijul_remote::ssh] fingerprint = "eulf5RwDiNbwc+gf1brMtxhdaJw0g8wL1Y5VlrR3llk"
[2025-04-03T20:14:01Z DEBUG pijul_remote::ssh] authenticate future
Error: "Not authenticated. Please check your credentials and try again."

SSH Succeeds, Hangs

• ssh -v highvibeAT[NEST HOST] echo TEST

debug1: Offering public key: /Users/don/.ssh/id_ed25519 ED25519 SHA256:eulf5RwDiNbwc+gf1brMtxhdaJw0g8wL1Y5VlrR3llk
debug1: Authentication succeeded (publickey).
debug1: Sending command: echo TEST
[Hangs]

Clone Fails

• RUST_LOG=“pijul=debug” pijul clone highvibeAT[NEST HOST]/pijul/pijul

[2025-04-03T20:15:55Z DEBUG pijul_remote::ssh] Trying key Ed25519(...)
[2025-04-03T20:15:55Z DEBUG pijul_remote::ssh] authenticate future
[Hangs]

Warning: Unable to automatically authenticate with server. Please make sure your SSH keys have been uploaded to the Nest.
For more information, please visit https://pijul.org/manual/the_nest/public_keys.html#ssh-public-keys

But of course Nest is not involved in this transaction, so it’s unclear what to do. Perhaps the manual should address this or pijul clone changed to not assume use of Nest.

Perhaps relatedly, pijul identity prove is not clear as to what it does or why one might want to do it. What does “associate” mean? Does it have something to do with auth?