DanConwayDev

freedom tech developer and creator of ngit, https://gitworkshop.dev and https://metadata.nostr.com

Public Key

npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr

NIP-05 Address

dan@gitworkshop.dev

NIP-57 Address

danconwaydev@minibits.cash

Profile Code

nprofile1qqs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnyxj4avg

Publishing to

relay.damus.io

relay.nostr.band

nos.lol

Author Public Key

npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr

Show more details

Last Notes

2024-11-12 11:11:10

- 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-06 20:12:15

make nostr on boarding great again

2024-11-02 22:51:10

- reply

There is a spec for a android signer which doesn't use nip46. Perhaps thete could be an alternative for desktop?

2024-11-02 22:21:55

- reply

Yes. That's a good idea. I'm in the process of making some improvements to the on-boarding experience so once I've made that easier and more forgiving I'll do some video demos and live sessjons.

2024-11-02 21:12:27

- reply

Let's reduce the friction. Any ideas?

2024-10-31 20:49:59

- reply

Ok, ill check it out but it looks like I have some refactoring to do now that NostrSigner is now a dynamic trait.

2024-10-31 20:48:34

- reply

I'm quite frequently getting the following error when trying to sign events with the remote signer, whereas I do not get this under rust-nostr v0.35.0 :
`Error: failed to sign event
Caused by:
not subscribed`

2024-10-29 17:15:24

- reply

In don't see any pubky git or nostr projects?

2024-10-24 19:44:39

- reply

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

2024-10-10 17:59:51

- reply

i3. simple. flexible. powerful.

2024-10-08 17:54:49

- 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

- 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

- 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

- reply

Cemex pour over? Yes please

2024-09-30 18:23:40

- 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

- reply

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

2024-09-30 15:33:10

- reply

They are just consolidating in case of future fee spikes

2024-09-30 10:40:06

- reply

I feel your pain.

2024-09-30 10:36:52

- reply

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

2024-09-30 09:19:57

- 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

- reply

Got it #nevent1q…dp9f

2024-09-30 08:25:11

- 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

- reply

Thanks for covering my project

2024-09-25 18:34:30

- 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

- reply

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

2024-09-25 18:19:59

- reply

perfect thanks

2024-09-25 15:48:15

- reply

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

2024-09-25 15:45:52

- reply

are you still getting this on the latest version?

2024-09-25 15:44:37

- reply

fixed by commit 635b5b119e7719a66d064853c3cb4c03872abfa9

2024-09-25 15:41:53

- 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

- reply

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

2024-09-25 15:35:32

- reply

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

2024-09-25 15:34:24

- 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

- 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

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

- 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

- 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

- 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

- reply

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

2024-09-20 20:42:28

- reply

Nice!

2024-09-20 18:55:56

- 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

- reply

What do you mean by read-limited?

2024-09-20 09:21:08

- 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

- 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

- reply

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

2024-09-20 06:43:33

- reply

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

2024-09-20 06:33:03

- 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

- 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

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

2024-09-19 12:31:12

- reply

Thanks

2024-09-19 12:31:01

- reply

Thanks

2024-09-19 09:34:12

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

2024-09-19 09:22:56

- 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:17

- 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:51:09

- 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

- 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

- 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

- reply

Nice video. There is so much potential here!

2024-09-18 15:04:21

- 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

- reply

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

2024-09-18 14:06:22

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

2024-09-18 13:50:13

- 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

- 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

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

- 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

- reply

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

2024-09-16 22:12:29

- 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

- reply

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

2024-09-16 21:55:57

- 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

- 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

- 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

- 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 14:23:06

- reply

What command are you running?

2024-09-14 13:38:07

- reply

I like your list. How has Kierkegaard influenced you?

2024-09-14 13:30:29

- reply

Tell us more. How has it changed your life?

2024-09-13 22:08:49

- 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

- 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

- 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

2024-09-13 20:34:41

- reply

Here you are pushing the main branch rather than a PR branch so instead of pushing a patch event it will push a state announcement event (30618).

2024-09-13 20:27:47

- reply

I could do with building some better error reporting when specific events are requested but not returned by any relays.

2024-09-13 20:10:47

- reply

Can you open the network tab in developer tools and press refresh? It should be requesting the event from the relay hint which is wss://relay.nostr.band and some default relays. If you filter by wss://relay.nostr.band you could see why its not responding with the event. I'm cant be much more helpful because its getting the event fine at my end.

2024-09-13 16:35:47

- reply

published v1.4.6

2024-09-13 15:41:07

- reply

I have fixed this on the master branch. I'll push a v1.4.6 shortly to patch v1.4.
with the fix your branch could be called `article-editor` or `pr/article-editor`
if you are logged in as the author of the PR (git config nostr.npub matches the PR author)
or `article-editor(3fbba0ec)` which is what it would be named if you weren't logged in as the author and checked out the branch on a remote with the nostr url.
I think there might be other problems with the repo (potentially stemming from oversized patches). Hence the need for blossom for large patches and the discussion we were going to have.

2024-09-13 14:02:29

- reply

I'll look into it. Its probably down to a change that adds a id postfix to pr/ branches when your not the author.

2024-09-13 07:21:45

- reply

Thanks so much for bring this into being. It's an important project in in nostr land. v1.0.0 is a big milestone. Congratulations. You should celebrate with balloons or something.

2024-09-12 15:29:51

- reply

What about @nprofile…5ql5?

2024-09-12 14:33:59

- reply

8am CDT works for me

2024-09-12 13:20:38

- reply

Do mornings work for you?

2024-09-12 08:37:12

- reply

A lot of events of events don't get rebroadcast. It very much depends on the reach of the user, what kind the events are, where they are initially pushed, how much engagement there is with the event as clients tend to rebroadcast events they reference, etc.

2024-09-12 06:27:59

- reply

Hrm. That's 5am for me which is a little early. I could do an hour later?

2024-09-11 20:06:38

- reply

Wow. Thanks for sharing.

2024-09-11 11:45:36

- reply

I can make a call during those times most evenings.

2024-09-11 09:28:33

- reply

Is that UTC?

2024-09-11 09:25:09

- reply

I can't do this Sunday

2024-09-11 08:57:51

- reply

Yes. Sometimes even on the correct repo it shows no PRs / issues until I refresh the page.

2024-09-11 08:56:35

- reply

I'm definately not interested in hosting a central one as I don't want to create a point of centralisation and I do host content. You wouldn't need an instance per repo but you'd need to use an instance that you or someone else is hosting and allowing your pubkey to write to.
What in suggested would just make pulling proposal commits marginly more efficient. Thinking about it, probably only if the commits where too big for events and you had to use an alternative like I just mentioned with blossom.

2024-09-11 08:49:52

- reply

Yes. I think I've mentioned it before but I'm planning on using blossom as a fallback for large commits that result in events that are so big relays won't accept them. I think this is the bestway of doing it without relying on the contributortoo indefinitely host a git server with the patch on it. This does add complexity and depending on how it was handled in the interface, effect other NIP-34 clients as they may no longer be displaying all PRs submitted unless they add at least partial support.
I'd love to get the input from your team on this. Could I join one of your dev calls to discuss it with you?

2024-09-11 08:43:07

- reply

I'll look at how they do it but I'm not going to get to this straight away as it only effects one or two users. I'm guessing incognito mode is a work around?

2024-09-11 08:40:25

- reply

I'm planning to do this as part of a refactor to implement caching and bring mor stability and robustness. This is the next thing on the gitworkshop priority list aside from bug fixes. You may want to do something outside of gitworlshop in the interim.

2024-09-11 08:28:27

- reply

If you go into network tab in the browser devtools you should see a problem connecting to relays. A page refresh resets all.your connections ans uaually fixes it. Ideally this should be detected by gitworkshop.dev and done automatically.Its would also work a lot better if there was caching and it onlymasked for new events, instead of the events it has previously fetched.