Yeah I agree that monetization seems hard here. But one niche that might work - tons of people are using LLMs to build out side projects and keeping tickets in the same repo as the project could be really frictionless for LLMs to reach for without an MCP server.

Don't sell to developers for their day jobs, but sell to developers for their hobbies.

Sure.

Identities in git can barely be called that. You define your name and email, maybe sign your commit. Those signature can be checked but it's really optional and often left to another system (e.g. github or your git viewer). Access right in the git remote is also a completely different thing.

In a distributed/p2p system with social interaction you need well defined identities that carries public keys. If you want to work offline, you actually need a full self-certified history of public key updates. Any changes in the entities (bug, pr, ...) need to have an author and a clear logical time so that you can backtrack to which pubkey(s) was active at the moment. Note that if you accept external contribution from a webui, you still need those identities being created in the background, possibly later to be "adopted" when using the native tooling.

Identities in git-bug is a part that nearly didn't change since the inception, and it's time for an upgrade. At the moment they are a linear series of changes (that is, NOT a CRDT) and are stuck within one repo. You can push/pull around but you are really just making a copy that you need to maintain.

My plan is to split this concept in two parts: pubkey log, and how they anchor within the repo's logical time. It turns out that if you split that way, the first part is pretty much exactly what did:plc is. Additionally, for complicated reasons like allowing recovery without opening major weakness, that's the one thing where having a centralized reference is important, so relying on the public https://plc.directory/ makes sense.

same question here. the other limitation i ran into immediately was only having two status types: open and closed

Were you aware of git-bug when you created gitsocial? If so, which patterns did you reuse and which ones did you decide to diverge from? Or would you say the two projects embody fundamentally different visions?

No mention of Fossil, which works great and proves that the difficulty is in gathering dev interest.

It may be that the presence of Fossil as a mature option is enough to dissuade people from choosing/working on alternatives. I’m pleased to see git-bug slowly making progress though, maybe it will get there in time.

Hits hard.

I looked into them. Most of them use some CRDT-ish machinery to merge concurrent ticket changes. (Fixing merge conflicts in tickets would be too disappointing.) As a CRDT person, I noticed that implementing CRDT merges in git itself mostly makes that machinery unnecessary. Then you can keep your tickets in plain Markdown, having CRDT merges for both code and metadata. I have it working here btw

https://replicated.live/blog/meta

You could always FFI to libgit2 rather than calling git

Glad to hear it! Thanks.

The agent requirement is a symptom of a deeper potential issue: not using the system's ssh. Providing built-in as a fast-path option is fine, but ~/.ssh/config can do a lot of useful things, and providing an easy option to say "just use real ssh" lets people have their config just work.

Specifying identify files for specific hosts, using bastion hosts (ProxyJump), etc. For example, my laptop SSH config detects when I'm not on my university network or VPN and adds a ProxyJump through the department bastion host, but connects directly when I'm on the network. Configurations like that break when software makes too many assumptions about how ssh is configured.

you don't need an agent for hsm.

also, don't know a good security researcher who uses agents (some even use ssh config to limit which keys are even tried per domain)

ssh config hacks are also a must if you have, say, two or more identities to github.com for example.

hi - this is incorrect

I use a Yubikey for some of my keys, and I've never used an "agent", don't know how, and don't want to start, unless someone can give me a good reason to

ssh-keygen -t ed25519-sk

that's all you need to use a Yubikey with SSH

I can somewhat understand your point about issues tied to branch, but have some remaining questions about how this working in practice:

- If I am on a branch where this issue exists and unaddressed, is it easy to find out if there is another branch where this issue has been addressed

- I am on a branch that does not have the issue reported, but know it's reported on another branch -- does that mean the issue doesn't exist on this branch? Is it on the reporter to correctly identify the root branch where the issue was first created? Do you have to somehow merge to make this work "right"?

The issue there was collaboration, one person would be on master and see no hint that a case was already being worked on (status, comments, etc all being different until the branch was merged). The other bullets, that put the information in different locations, were attempts to deal with this.