It is, as far as I know, an unsolved problem how to implement full metadata transparency on a mobile device.
For example, Aztec, a privacy focused blockchain, requires recipients to download the entire block to determine if any private message is addressed to them (and BTW use techniques resembling Signal's double ratcheting in creating these identifiers) [1]
This is infeasible on mobile devices. At best, it allows the user to select a proxy server they trust to identify messages intended for them and forward a notification.
I'm trying to understand, would jj's first class conflicts solve the issue of having "stacks" of PRs that can easily be updated at any point in the stack? This is one of the features most absent from git, but prevalent in Google's tooling as well as Meta's. The only good known solution I know is graphite.dev
Not 100% sure I understand what you're saying, but I think the answer is "yes".
You can modify any* commit in `jj` regardless of whether it has commits on top of it at any time. Either by another commit into it, or by directly checking out the commit and editing the source tree. If this creates conflicts with commits on top of it `jj` just records those commits as having conflicts/adds conflict markers without interrupting the workflow.
* Commits pushed to remotes are marked immutable so you have to pass an extra flag to say ignore that and modify them anyways. Which you generally wouldn't want to do.
If I understand you correctly we're imagining you pulled a repo with main at commit A. You added commit B on top of A. Someone else added commit C on top of A to main on the remote, and you're asking what happens?
Nothing until you pull and rebase B on top of C (two distinct steps). Once B is on top of C, when B is checked out there will be conflict markers in the source tree that will presumably break your build until you resolve the conflict (unless the conflict is in README or something).
My CI workflow has always been on top of a git based forge. As far as the forge is concerned jj is git and absolutely nothing changes with regards to that.
A is the remote, B is a coworkers commit, C is mine (iiuc jj uses stacked commits instead of branches)
Let's remove the merge conflict and keep the commits in alphabetical order
B pushes a breaking change, I push a commit to C without knowing.
Are my builds and PRs now at the mercy of changes and events outside of my control?
(my hunch is that there are a bunch of confusing situations in jj like git, and that being different enough will cause user churn and people will stick with the tool they already understand the quirks of)
You're both working on the same branch on the remote? It will refuse to push unless you do `jj git push --force` at which point it will overwrite your coworkers work with yours. This is regardless of conflicts, like with git you have to pull the remote work locally, rebase on it, and then push it.
> iiuc jj uses stacked commits instead of branches
Locally jj doesn't really use branches, you can just create a commit on top of any other commit without creating a branch. It does represent branches (it calls them "bookmarks" for whatever reason) and pushing is pushing a bookmark to a git-branch on the remote.
> Are my builds and PRs now at the mercy of changes and events outside of my control?
I don't believe there's any circumstance where your work is silently rebased on top of other work, or anything else that fits this description.
Since jj does not have branches, it sounds like we are forced into the rebase environment?
With git, I can push my changes without a force, regardless of what the work I build on does
I think jj's biggest challenge to adoption or replacing git is not technical, it's that it requires people changing how they think about and perform a very central act of their non-coding activities. CUE suffers from this as well. The biggest pushback I hear is about being able to wrap their heads around it. Devs seem to be largely burnt out on tooling changes right now, we left that hype cycle as the ai/agent cycle was emerging
> I don't believe there's any circumstance where your work is silently rebased on top of other work, or anything else that fits this description.
This sounds like merge conflicts are "shifted-left"? Today we see merge conflicts when a PR is opened and devs fix as needed. With jj it sounds like they couldn't push until the merge fix is resolved. Many times it's not important to deal with that straight away and the dev can continue to get their task done, see builds and results for their changes, etc...
Is this "shift-left" of conflict resolution an accurate way to describe jj's approach / philosophy?
> Since jj does not have branches, it sounds like we are forced into the rebase environment?
No, I tend to use rebase by default (because I like linear history) so its the language I use but it's equally valid in both git and jj to merge via merge commits instead of rebases.
While JJ doesn't have a concept it calls branches, it has all the same semantic power of branches. The difference here is just that git insists on each leaf commit in the source control tree being tagged with a name it calls a branch, jj is perfectly happy to have leaves in the source control tree where you haven't given them a branch-name.
> This sounds like merge conflicts are "shifted-left"? Today we see merge conflicts when a PR is opened and devs fix as needed. With jj it sounds like they couldn't push until the merge fix is resolved. Many times it's not important to deal with that straight away and the dev can continue to get their task done, see builds and results for their changes, etc...
The behaviour here is the exact same between git and jj. If both you and a coworker push to the same remote branch you have to handle conflicts before pushing with either VCS. If both you and a coworker push to different remote branches and then you submit the change through a pull request you see conflicts when you try to merge the branches (or a reasonable forge like github will test merging behind the scenes and surface it early).
> Is this "shift-left" of conflict resolution an accurate way to describe jj's approach / philosophy?
No. jj never shifts conflict resolution left. JJ does sometimes shift conflicts right, allowing you to defer fixing the conflict until later.
This is only absent from git because you said "easily". ;-) git can certainly handle doing this, it has more than enough functionality for it. But you're kind of fighting against the grain to do it.
Yes, jj very much supports this workflow. It's not a single feature, though:
- `jj absorb` automatically guesses what patches in your stack your changes should go to and puts them there, leaving uncertain ones behind. Combine this with `jj undo`, and you can first try an absorb and then immediately undo it if it gets it wrong.
- `jj squash --interactive --into X` (aka `jj squash -i -t X`) is the more controlled option, where you can select the specific files/hunks/lines to amend X with. The auto-rebasing then adjusts the rest of the stack to match. If it creates conflicts, you can either undo, fix them now, or fix them later.
- if you want to experiment with reordering your stack (or more generally, reorganizing your DAG), you can do so without it making a bigger mess than is absolutely necessary. That's not just because of undo. If you try to rebase a patch too early and it produces tons of conflicts, you can rebase it back and the conflicts will be gone (assuming you didn't have some in the first place, but if you did you'll be back to the same ones). You can try different places within the stack and see what'll work best.
- As an expansion of the above, you can also split off pieces of one diff and insert it or squash it anywhere in the stack (eg `jj split --revision X --insert-after Y` aka `jj split -r X -A Y`, or `jj squash --interactive --from X --into Y` aka `jj squash -i -f X -t Y`). You don't need to be "at" X to rip off pieces and put them elsewhere, you can do it anytime.
In summary, the full answer is "hell yeah!"
Note that this doesn't magically eliminate all problems that arise from collaboration. You can't push your stack somewhere and have other people start working off of it and modifying it while modifying it yourself locally. Or rather, you can, but you'll end up with a mess. Perhaps much less of a mess than eg git, because jj tracks evolving changes and not just commits and so you might be able to have some idea of what's going on once you've pulled the conflicting mutations back into your local repo. But generally speaking, you still have to be disciplined about changing anything that other people can see and possibly depend upon. (jj can help by automatically making such things immutable once you've made them visible to others, but that too can be a bit confusing and require setup specific to your situation.) This comes up a lot in code review, and there are solutions that handle parts of the problem with varying degrees of success, but I've already rambled quite a bit.
It may be unclear since I screwed up the formatting of my post, but that's why I didn't end there. The rest of jj's capabilities change when and how I use it.
The absorb command originated in mercurial, which is where I've used it most. With `hg absorb`, I'd only use it when I was fairly sure that it would do the right thing, and I imagine it'd be the same with git. With jj, having `jj undo` as a fallback means I can use it just to see what it does and if it gets something wrong, undo it and do what I want in a different way. (But not that different -- `jj squash -i --into X` means I can do the same thing as it was doing manually.)
Inventing the automobile has clearly made humanity less fit. Should we stop driving?
No. Going back to the stone age is not the solution. For the majority of our day, commuting without a vehicle will be impractical. So will coding without AI, especially as AI improves.
To retain human competency, we will have to find a novel solution. For walking, we created concentrated practice time - gyms/outdoor runs. Some evolution of leetcode, or even an AI guided training, might be the solution for coding skill preservation.
> Inventing the automobile has clearly made humanity less fit. Should we stop driving?
Yes, pretty please.
I live in a town of 400 thousand, it's basically 10 kilometers accross. Very easily walkable. Why does everyone drive? I'm about as fast on foot as when they're stuck in morning traffic. I'm also enjoying my time more than the people stuck in traffic. (And I'd enjoy it even more if there weren't so many cars around!)
I don't understand people who drive to the gym to walk there. They could just walk to the gym and back, instead of going to the gym...
> Inventing the automobile has clearly made humanity less fit. Should we stop driving?
Perhaps an apt analogy. One could argue that the lure of convenience of automobiles led to one of the worst decisions of the 20th century, to restructure society around automobiles, causing a self-perpetuating reliance feedback loop with many destructive side-effects (physical, environmental and cultural). We should pause a bit and not rush head-long into AI without trying to think the path forward through. It's a decision that we will all make together as a culture. There are many current troubles with AI already, even if they make no mistakes at all.
Kulipa issues Visa/MasterCard cards backed by stablecoins.
It matters to people who do not have access to a fully open banking system (e.g. Argentina).
TECH
We synchronize the card payment network with blockchains and non-custodial wallets. It's quite complex to manage a ledger you don't fully control, so we're treading new ground here.
TEAM
We believe in the 2 pizza rule: We hire as few people as possible, at the highest possible bar. We have some ex-Meta & Google L7s, for instance. 5 engineers currently at the company.
YOU
Senior engineers with backend experience. Smart and excited. All the rest is bonus: Blockchain, Typescript, AWS.
We issue Visa & Mastercard cards not backed by a bank. Instead we use stablecoins held in non custodial wallets.
This type of service is crucial for many people in places like Argentina, Colombia, Nigeria, Turkey, where inflation soars and sheltering in foreign currency is hard and often impossible.
Down the line, we want to take card payment settlement time down from days to minutes, which will remove a huge and expensive inefficiency in the card scheme.
We are headed by an ex-Mastercard, Google, Meta, and Binance team. Still very small: 5 people on the engineering team. We intend to continue growing small and senior. Our current team is skewed heavily towards senior with two former L7s from Meta/Google.
We have raised a seed early this year and are seconds from going live with first cards.
In Israel this is done naturally by feeding children Bamba, a puffed peanut snack, at a very early age. Research shows significantly decreased levels of peanut allergy.
Bambas are recommended in the U.S. as well, but our kid entered anaphylaxis after eating just 5 bambas his first time, at about 6 months of age. It's certainly possible to have a peanut allergy despite early exposure. Recommendation in the U.S. is now for pregnant women to eat peanuts to expose the fetus in utero, but even this doesn't always work.
Kid is desensitized now after a year of oral immunotherapy, so add us to the chorus of voices saying "It works", but it can strike early and severely despite the parents' best efforts.
It's not just about early exposure to allergens, it's also early exposure to pathogens. There's a growing body of research that constant disinfection of hands and surfaces is what really caused the allergy outbreak. Humans need to prime their immune systems with exposure to pathogenic bacteria at an early age so that it can learn to fight them and not other substances which leads to allergies.
People mention this quite often to me because my toddler is on oral immunotherapy for peanuts, and there’s a small but important distinction here. It’s extra important when relatives start to think it’s okay to be casually leaving peanut products lying around within the toddler’s reach. (It’s not)
The general consensus among allergists is that early exposure reduces the chances of developing the allergy in the first place, but people on oral immunotherapy are still allergic, they just have a high tolerance and can still have anaphylactic reactions. Some will outgrow the allergy, but for peanuts most don’t and the data doesn’t yet exist for whether peanut oral immunotherapy increases the likelihood of outgrowing the allergy.
There are some early studies out [1] that indicate remission is possible with OIT. (For laypeople, "desensitization" ~= can tolerate some peanut exposure without a reaction, but still needs to carry an epipen and remain on the maintenance dose for life, while "remission" ~= no longer has a peanut allergy). The numbers were 71% desensitization and 21% remission for OIT vs. 2% both for a placebo. It was heavily dependent on age, with 71% of 1-year-olds, 35% of 2-year-olds, and 19% of 3-year-olds achieving remission.
Data will be scant at this time, because the full treatment takes a long time and needs to be adhered to closely. It's 30 weeks of OIT, followed by 2 years of a maintenance dose, followed by a 6-month hiatus to verify whether the maintenance dose can be stopped while still achieving remission, so data necessarily lags the start of any clinical trials by 3+ years.
I thought there was a study that suggested the weapon of first resort should be breastfeeding mothers eating the allergen-triggering foods so the kids get exposed to them indirectly.
Makes me wonder if there is something we should be doing with baby formula.
Yeah, we hadn't heard of this when our son was born, but the allergist mentioned it. When our daughter was born, we gave her something like this at his recommendation. The ones we got were some puffs that have a whole pile of allergens in tiny doses. Causation vs correlation and all that, and a small sample size, but our daughter doesn't have any issues with any allergies.
The economist Emily Oster wrote an excellent series of books about pregnancy anf early kid years, where she dives into details about various studies, whether they are causal, etc. It's one of the best practiacl explainations of reading research I've encountered targeted at non-academics, really well done. She has a chapter on peanut exposure allergies and i think inrecall that these early-exposure results are in fact from causal research vs just correlational research (basically there are at least two types of papers out thwre -- correlational and causal. As you might guess causal is harder to get for many reasons). Great books; she may also have published some chapters on her substack (substack came after the book I think).
I realize as I write this that you are probably saying that for your own experience you can't disentangle correlational from causation, to which I would say -- correct!
Emily Oster is a national treasure that is still flying under the radar for most people.
As above, she presents excellent science in an approachable manner for non-science minded folks. She also has enough of the technical details for this with the knowledge to be confident she has done a strong analysis.
If you are a parent and haven’t checked her stuff out, please do. (Zero affiliation or connection)
For example, Aztec, a privacy focused blockchain, requires recipients to download the entire block to determine if any private message is addressed to them (and BTW use techniques resembling Signal's double ratcheting in creating these identifiers) [1]
This is infeasible on mobile devices. At best, it allows the user to select a proxy server they trust to identify messages intended for them and forward a notification.
1 - https://www.taurushq.com/blog/enhancing-token-transaction-pr... (search for "synchronizer")