DanConwayDev

Only if users get notification in their daily driver clients. Otherwise the conversations die and move to a channel where participants do get notifications.

2024-12-20 15:44:56 GMT

The biggest friction with #GitViaNostr onboarding is the git server setup. We have ideas to fix that with a nostr-permissioned git server implementation inspired by
@npub180c…h6w6's #naddr1qq…c3xy
We envision many public instances that allow user to push new repos with no signup and zero-configuraiton required.
Let me know if you would like this.
#nevent1q…tew6

2024-12-20 15:41:07 GMT

nostr on-boarding flows are hard
#nevent1q…xcsp

2024-12-20 15:40:17 GMT

ngit v1.6 (beef-up onboarding) released with improved on-boarding and login flow.
Thanks to new contributor @npub1elt…cume who added nip05 address support to nostr git clone url.

2024-12-02 07:12:56 GMT

- reply

I thought about having a prompt when this error occurred but if the user is running a gui, they wouldn't see the prompt and the process wouldn't end.
I've therefore changed the error message to:
> no repo announcement event found at specified coordinates. consider running `ngit init` to create one if you are the repository maintainer
Another approach could be to issue a prompt with a timeout so the process would fail but for now I think this error message is clear enough and its not much of a lift to ask the user to run the `ngit init` command.

2024-11-30 20:13:41 GMT

- reply

I like it! Improvement suggestion: QTS reviews a la https://habla.news/u/[email protected]/DLAfzJJpQDS4vj3wSleum

2024-11-29 07:57:23 GMT

- reply

thanks for raising an issue about this. see this recent discussion about comment kinds: #nevent1q…wqaj
I'm looking to add NIP-22 comments soon

2024-11-28 17:02:35 GMT

- reply

I have added this in 6bcac672e04cb316de1f952c08b07937c7db3cc6. Note though that maintainters.yaml will not be created automatically `ngit init`. It complicates the on-boarding experience too much. If the file exists it will be continue to be updated and drawn up though.

2024-11-27 19:30:30 GMT

- reply

Thanks @nprofile…ehfp. I've already upgraded and started using the Nostr Connect changes I asked for.

2024-11-27 12:51:19 GMT

- reply

It started using 1622 for replies per nip34 but then reverted to kind 1 for more consistent inclusion in notifications across clients. I like nip-22 and want to add support. I'm in favour of supporting a range of ways of interacting with issues ans PRs in gitworkshop. The usefulness breaks down when the users your collaborating with don't get notifications on the clients they are using.

2024-11-27 12:41:52 GMT

- reply

The issue event is kind 1621. Your response was kind 1. What client did you reply with?

2024-11-26 19:25:03 GMT

- reply

Is there anything more suculent than a turkey breast cooked sous vide for 24hrs at 55°C? As an englishman, I'm waiting for Christmas obviously.

2024-11-26 19:17:07 GMT

- reply

Is there an APK i can download or should I install as a PWA? I notice you have web and mobile repos.

2024-11-19 09:18:16 GMT

- reply

I'm not crazy about breaking changes to the spec but I don't think anyone is using the optional parent commit ids.

2024-11-18 20:58:53 GMT

- reply

I've had ideas how to integrate that for a while but not quite got to it.

2024-11-18 20:41:06 GMT

- reply

For a minimum viable solution I thought we could just hard code it. I suppose in could initially add it as an CLI argument for `ngit init` for now and store it in blossom tag in 30317.

2024-11-18 20:36:21 GMT

- reply

Shouldn't that be caculated from within the fetch script?

2024-11-18 17:00:26 GMT

- reply

testing if kind 1 replies to to git issues show up in chachi. maybe its a reply kind 1111 maxi?

2024-11-13 21:25:24 GMT

- reply

I'm in the middle of a refactor which should fix this.

2024-11-13 21:24:51 GMT

- reply

Yes, I'm part way through a redactor of gitworkshop, which is on pause whilst I finish some better onboarding in ngit. The display of repo events and how they are connected to one another needs improvement. I have some ideas for this but I havnt got around to implementing them yet.

2024-11-13 16:26:01 GMT

- reply

Right now the need to sort out a git server seems like the biggest friction for on boarding.

2024-11-13 16:25:10 GMT

- reply

It requires a basic git server but not gitea or gitlab as all the PR functionality happens over nostr. I'm planning on releasing a basic git server implementation similar to song (or maybe fork or enhance song) that hopefully a number of people would run public instances of that would host anyone's repos no-KYC with zero setup or sign up required.

2024-11-12 11:28:36 GMT

- reply

There was some discussion on it in this thread although I recall more posts and contributors that was i can see on my nostr clients.
#nevent1q…7uvn

2024-11-12 11:11:10 GMT

- reply

Great to see. Thanks for working on this. I'd suggest calling it git-remote-blossom and using a similar URL scheme to the git remote helper included in ngit.
That uses nostr://npub123/identifier or nostr://npub123/relay.damus.io/identifier
So blossom://npub123/identifier

2024-11-11 17:29:31 GMT

- reply

I realised that it was blocking elsewhere. But it would be save a trip if I could supply the user public key if it was known to prevent this from becoming blocking.

2024-11-06 20:12:57 GMT

- reply

We have work to do on #GitViaNostr

2024-10-30 20:41:02 GMT

- reply

I think your taking this quote out of context. The next verse reveals the state of the mans heart: "When the young man heard this, he went away sad, because he had great wealth."

2024-10-29 15:23:54 GMT

- reply

looks good

2024-10-28 15:51:45 GMT

- reply

That no longer blocks! Thanks. How are AUTH requests handled in this nip46 signer scenario?

2024-10-28 10:11:48 GMT

- reply

@npub1drv…seet, I'm reopening this because whilst `Nip46Signer::new` is not blocking, `NostrSigner::nip46` is. When a nip46 signer is not connected (or not automatically responding) the utility will hang until the signer is connected. this is true of `4dbfa94` but I'm not sure if you have tweaked it since.

2024-10-26 22:19:23 GMT

- reply

The notifications, comments and conversations surfaced in non-superapps apps is what makes nostr so attractive for other stuff. We lose that at our peril. Forcing users / apps to announce in a kind 1 and use this as the 'social' root event to get these benefits feels wrong. I don't think you're suggesting that? Just that the other stuff events don't show up in the main feed?

2024-10-24 19:44:39 GMT

- reply

Have you tried https://nixbitcoin.org/ ?

2024-10-19 07:55:05 GMT

- reply

Thanks for testing this :)

2024-10-10 17:59:51 GMT

- reply

i3. simple. flexible. powerful.

2024-10-08 17:54:49 GMT

- reply

There are examples of git being used for folders of documents but its never taken off. I think its because there is less of a need of an overall repository state which is central for git version control.

2024-10-07 12:52:04 GMT

- reply

Thanks very much for your contribution. I'd like more flexibility and control over signing than what this offers. I have always admired nostr::npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr's signing in nostrudel. Now he is abstracting some of nostrudel code into applesuace (great name btw) I'm thinking about using this.

2024-10-03 19:38:48 GMT

- reply

I use it as my daily driver and get away without using GPU passthrough. Why is this a roadblock for your privacy?

2024-10-03 09:10:45 GMT

- reply

Cemex pour over? Yes please

2024-09-30 18:23:40 GMT

- reply

I've not been following the AUTH discussions. Has anyone suggested relays state their reasons for the request? That way clients can evaluate whether they need / want to respond to the AUTH or not.
`["AUTH", <challenge-string>,<request-code>]`

2024-09-30 18:15:32 GMT

- reply

Requesting DMs is a totally different ballgame. AUTH is totally reasonable then.

2024-09-30 15:33:10 GMT

- reply

They are just consolidating in case of future fee spikes

2024-09-30 10:40:06 GMT

- reply

I feel your pain.

2024-09-30 10:36:52 GMT

- reply

FYI the timestamp (the value used by Amethyst st least) is 9 days ago.

2024-09-30 09:19:57 GMT

- reply

Really good article. Instead of trying to deal with distributed consensus, could you have the coordinator DVM publish decision and data points used to make them and have auditor DVMs to check their work?

2024-09-30 08:29:34 GMT

- reply

Got it #nevent1q…dp9f

2024-09-30 08:25:11 GMT

- reply

nice! it looks like `git push --force` is working. or did you use `ngit send --in-reply-to nevent123...`?

2024-09-26 19:07:07 GMT

- reply

Thanks for covering my project

2024-09-25 18:34:30 GMT

- reply

I'm aware that right now most clients make finger printing pretty easy right now (see #nevent1q…acyk), but normalising auth-to-read removes all doubt and possibility for clients to resist this later.
I've thought more about zkps and either the relay must reveal their whitelist or the user sends a list that could easily fingerprint them.
I don't have any easy answers for an alternative. attaching ecash to request messages could be interesting.

2024-09-25 18:24:57 GMT

- reply

no worries. cross-client compatibility is how we win!

2024-09-25 18:19:59 GMT

- reply

perfect thanks

2024-09-25 15:48:15 GMT

- reply

closing due to inactivity and user didn't back to confirm whether it is still a problem.

2024-09-25 15:45:52 GMT

- reply

are you still getting this on the latest version?

2024-09-25 15:44:37 GMT

- reply

fixed by commit 635b5b119e7719a66d064853c3cb4c03872abfa9

2024-09-25 15:41:53 GMT

- reply

this should be fixed in ngit v1.5. can you confirm?
From the change log:
- intelligent protocol selection and fallback
- unless unusual protocol specified in repo event clone url it
will try in this order:
- fetch: https unatuth, ssh, https
- push: ssh, https auth
- save successful protocol in git config so it is tried first
next time
- enable override from nostr url (will only use this protocol)

2024-09-25 15:37:00 GMT

- reply

Is this working on v1.5.2? This may be related to #nevent1q…nwka

2024-09-25 15:35:32 GMT

- reply

This is working for me on linux on v1.5.2. please can you try again?

2024-09-25 15:34:24 GMT

- reply

I have add auth to the master branch in commit 4f84dc460c3494286233afe9ca480d3b7c0186b1 but after some testing I am not happy with the delay it introduces when using a nip46 signer.
I've raised an issue with rust-nostr which should hopefully resolve this.
#nevent1q…sc90
i figured that users can choice whether to approve auth requests through their nip46 signer.

2024-09-24 19:13:03 GMT

- reply

I've done some investigation and concluded the only way you can get that error is if you copied the git-remote-nostr binary into your PATH as ngit.
I've released v1.5.2 which should fix your login issues.
#nevent1q…7mkl

2024-09-24 19:10:33 GMT

ngit v1.5.2 released. download from https://gitworkshop.dev/
- login via nip46 QR code
- enable login directly in git plugin
- add resilience to git plugin so that a poorly formatted prs gracefully fail and won't cause issues elsewhere

2024-09-21 14:19:14 GMT

- reply

I need to enable first time login via the remote helper. For now you need to login first. Ie `ngit login`

2024-09-21 07:30:42 GMT

- reply

I think using a zero knowledge proof that I am one of a number of npubs is more practical as it doesn't require users to have, and want to spend ecash on privacy.

2024-09-21 07:28:16 GMT

- reply

Did you manually construct the nostr URL? I think you are using the wrong identifier. The easiest way to ensure you have it right is by looking it up on gitworkshop.dev/repos
nostr://npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf/nostr.thesamecat.io/Alexandria
What platform are you on?

2024-09-20 21:59:41 GMT

- reply

Good point about the block design. I think !# the best suggestion thus far.

2024-09-20 20:42:28 GMT

- reply

Nice!

2024-09-20 18:55:56 GMT

- reply

maybe we need zero knowledge AUTH? This would be fun to work on. Is anyone working on zero-knowledge-proofs on nostr?
#nevent1q…acyk

2024-09-20 17:32:31 GMT

- reply

What do you mean by read-limited?

2024-09-20 09:21:08 GMT

- reply

If relays deny requests for public events unless they have received an AUTH response, then it becomes a big problem. I won't be able to read a users public events from their outbox relays.

2024-09-20 08:36:15 GMT

- reply

I just deny all AUTH in my signer. That waybindont have to find the setting in every client / believe they will honour it.

2024-09-20 08:24:11 GMT

- reply

I can choose my clients but I can't choose other people's outbox relays.

2024-09-20 06:43:33 GMT

- reply

I'd prefer to include ecash in requests than to auth

2024-09-20 06:33:03 GMT

- reply

This git issue puts the title in the `subject` tag and the preview lacks context in most nostr clients:
#nevent1q…75uk

2024-09-19 21:57:04 GMT

- reply

I completely agree. Normalising AUTH-to-read for outbox relays creates incentives for relays operators to track each user's reading habits and and sell the data to advertisers.

2024-09-19 13:10:32 GMT

whats the best nostr tool to backup all my notes (and context) to a local relay? #asknostr

2024-09-19 12:31:12 GMT

- reply

Thanks

2024-09-19 12:31:01 GMT

- reply

Thanks

2024-09-19 09:34:12 GMT

What cashu wallet would you recommend for android? I have Minibits but need a second. #asknostr

2024-09-19 09:22:56 GMT

- reply

I proposed an update to nip34 for clarification. what do you think?
https://github.com/nostr-protocol/nips/pull/1505

2024-09-19 08:51:09 GMT

- reply

I think the issue title isn't being displayed in most clients. I have raised an issue about why:
#nevent1q…2ahd

2024-09-19 08:36:22 GMT

- reply

This is great. If you reference the event directly we can see how it renders in other clients like amethyst.
#nevent1q…7ph4

2024-09-19 06:59:43 GMT

- reply

I love how by the end of the video when she makes the analogy with IMessage and SMS we start to realise that she has a better understanding of whats going on than he does.

2024-09-18 17:54:18 GMT

- reply

Nice video. There is so much potential here!

2024-09-18 15:04:21 GMT

- reply

I have stopped kind `9978` from displaying in commit 7a11742a7031084d5c49e7d7bfb19a258df74005.
let me know if you see any other spam like event kinds.

2024-09-18 14:19:46 GMT

- reply

issue raised in wrong repo. opened here: #nevent1q…jvun

2024-09-18 14:06:22 GMT

I'm trying out #satshoot. make me an offer:
https://satshoot.com/naddr1qvzqqqrllupzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uqsuamnwvaz7tmwdaejumr0dshsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshsz9mhwden5te0vf5hgcm0d9hx2u3wwdhkx6tpdshsz9mhwden5te0vf5hgcm0d9hx2u3wwdhkx6tpdshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpzamhxue69uhky6t5vdhkjmn9wgh8xmmrd9skctcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsq9t6v9cz6mt995erzttnv968xtthxe5hjvf4jlzcha

2024-09-18 13:50:13 GMT

- reply

I'm on the homepage and I'd like to know the following before clicking links:
1. How will I receive the funds? Bank transfer, on chain, etc.
2. Do you custody the funds until I withdraw?

2024-09-18 13:42:13 GMT

- reply

changelog:
- add new nostr url format that works better for MacOS users
`nostr://<*protocol>/<npub123>/<*relay-hint>/<identiifer>`
\*optional
- status updates during clone, push and fetch
- intelligent protocol selection and fallback
- unless unusual protocol specified in clone url it will try in this order:
- fetch: https unatuth, ssh, https
- push: ssh, https auth
- save successful protocol in git config so it is tried first next time
- enable override from nostr url (will only use this protocol)
- enable building binaries via nix
- refactor into lib and bin structure
- bump dependencies

2024-09-18 13:41:53 GMT

ngit v1.5.0 released. download from https://gitworkshop.dev
highlights: new nostr url format that works better for MacOS users; status updates during clone, push and fetch; intelligent git protocol selection and fallback

2024-09-18 13:20:49 GMT

- reply

what system are you on?
try newly issued ngit v1.5.0 (available from gitworkshop.dev/ngit). this upgrades gitlib2, which handles interaction with the git server.
I suspect if you are still getting the issue it relates to unresolved gitlib2 issues:
https://github.com/libgit2/libgit2/issues/5279
https://github.com/libgit2/libgit2/issues/5752
I can't replicate it on that repository but I can with the following repository on debian:
#naddr1qq…8nml
I've not come across it on any other repositories, and it only started happening recently on that repository.
*I wonder if i can tie it down to a particular SSL upgrade with nix*

2024-09-17 14:00:42 GMT

- reply

this does look right but isn't it a link to wiki article rather than a proposal?

2024-09-16 22:12:29 GMT

- reply

Both contain the full diff but squash destroys the history completely whereas no-ff includes a reference to it, so it can be optionally stores and downloaded.

2024-09-16 22:08:04 GMT

- reply

Ah, you need to use the `--no-ff` flag like so: `git merge --no-ff <branch-name>`

2024-09-16 21:55:57 GMT

- reply

You want option 2. Consider using multiple feature branches rather than a single develop branch to make it clearer what exactly is being merged. Then you can work on different things in parallel whilst having an easier to read commit history.

2024-09-16 19:08:47 GMT

- reply

Three options:
1. No merge - squash the commits in the branch, rebase onto master, set the tip of master to that commit. History is lost.
2. Merge - don't squash. Merge into master. The CI should just run on the merge commit. This will keep the useful history for future reference for everyone.
3. Add directly onto master - rebase on master, reset master tip to the tip of your develop branch.
If you go for option one you could keep a local branch that hasn't been squashed for your own person reference.

2024-09-16 16:07:13 GMT

- reply

I'm struggling to replicate your issue. on a number of repositories `ngit pull` seems to work with or without the nostr remote.
is the behaviour different on previous versions?
Your error suggest that the ngit binary is trying to load the repository event via code in the nostr-remote-nostr binary (which is automatically called via git with that environment variable set). I cant see where that is happening during the `ngit pull` command.

2024-09-16 15:39:56 GMT

- reply

I'll try and replicate it. I assume you haven't added the nostr remote locally?
`git remote set-url origin nostr://npub/identiifer?relayhint=relay.whereever.com`
or
`git remote add nostr nostr://npub/identiifer?relayhint=relay.whereever.com`

2024-09-14 13:38:07 GMT

- reply

I like your list. How has Kierkegaard influenced you?

2024-09-14 13:30:29 GMT

- reply

Tell us more. How has it changed your life?

2024-09-13 22:08:49 GMT

- reply

It must be a post summer thing. I'm doing one meal a day. protein and veg with minimal carbs. Chicken, lamb, beef or pork. Today was a slow cooked brisket with a little carrot and celery, fresh veg stock, homemade chicken stock and accompanied with steamed shreaded green beans from our village.

2024-09-13 21:05:01 GMT

- reply

If any project maintainers comes across this warning when doing a `git fetch`. The easiest thing to do is to add a other commit and push it. It will update the nostr state and the git server. Another way is to add the git server as a remote and push directly to that.
If the warning is `n ahead` it means that someone has pushes commits to the git server and not to nostr. To prevent you inadvertently overiting those commits and lose them forever you can't push conflicting commits. You'll need to add the git server as a remote, pull the commits, which commit you want to be the head and for push to the git served remote and the nostr remote.

2024-09-13 20:41:57 GMT

- reply

The warning indicates that at the time (before your push) github was a commit behind the state on nostr. Maybe you force pushed the previous commit directly to github, or more likely their was some sort of error during your last push after it issued the updated state event but before the push to github competed.
Probably the lack of status updates during pushes made you think it was hanging so you exited early. I've added these in son they will be available in v1.5