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

relay.primal.net

Author Public Key

npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr

Show more details

Last Notes

2024-09-14 13:38:07

- reply

I like your list. How has Kierkegaard influenced you?

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 07:18:13

- reply

Yes. two approaches:
1. git's `iterdiff` could be used to generate this within ngit and submit it as part of the cover letter (if one is included). There is too much duplication here and there is no garentee that PRs will include this as they may be generated by other tools.
2. apply the patch and output the diff. this could either be done in browser or by a proxy. Ideologically I don't like the idea of being overly reliant on a proxy as I think reliance on back-end infrastructure reduces the simplicity, robustness, and censorship resistance nature of a client. It looks likely that gitworkshop.dev will do a *shallow clone in the browser to deliver files and other git information. Experimentation is needed to see if PRs can be applied without checking out (and downloading) just the reliant files to the PR rather than all files in the latest state. Otherwise this could be bandwidth intensive for the user. Another possibility I have been thinking about is having nostr specific git implementations (like song) apply PRs submitted so the commits could be downloaded via the efficient git protocol and potentially could be used to access the PR diff in a bandwidth efficient way.
Ultimately it would be ideal if we could do approach 2 with everything done in a bandwidth efficient way in the browser.
*for context see #nevent1q…xv0d

2024-09-11 06:43:57

- reply

The revenue split from the output of the bounty is a nice idea. Are you familiar with nostrocket.org from @npub1myg…sn5p?

2024-09-10 13:47:07

Cashu wallet mobile connected to a personal cashu mint via Nostr Web Services. No need to connect your own node over Tor. Mobile device only has access to a subset of the funds.
Could this provide a better self-sovereign mobile lightning experience?
#nevent1q…76dh

2024-09-05 06:04:17

- reply

Maybe its running on an airgapped network. It's still pretty brave to put out an incentive to hack into his local network. Shapo @nprofile…0m5x

2024-09-01 08:49:16

- reply

Ordering a peppermint mocha is not a sign of being cultured!

2024-08-30 11:50:49

- reply

There is a project called nostrCI that @npub1zaf…26k5
presented on in riga. its about interoperability across nostr clients and there is a overlap with CI on nostr. There is a signal group for it and a call happening at 1430 UTC. If you want to join the singal group or the call, please shout up.
@npub1mgv…pdjc @npub19w6…syzj @npub1myg…sn5p @npub1ecd…s735

2024-08-30 11:43:31

- reply

@npub1myg…sn5p is interested in this too

2024-08-28 15:49:25

- reply

are you referring to the "client overwrites my list with empty values" problem?

2024-08-28 08:16:52

- reply

As of yesterday they are now in zapstore. I plan to display all releases related to a git repository in gitworkshop.dev

2024-08-28 08:03:34

- reply

If there were a two way relationship between the 'application profile' in the app store NIP and the 'repository announcement' in nip34, then clients could associate those ratings with both things. currently it is one way (nip34 announcement is referenced by the application profile event).

2024-08-27 21:39:33

Those of us who are interested in DVMs for CI on nostr should start collaborating.
@npub1hw6…65gr @npub1wf4…dgh9 @npub1mgv…pdjc
eg. building artifacts, running tests and deploying code.
there is an open invitation - comment on this note and we will loop you in

2024-08-27 16:59:26

- reply

Yes. Its included in the tar zip of the release

2024-08-27 15:16:46

- reply

Your the Ubermensch user

2024-08-26 15:20:29

- reply

this is exactly what I was hoping for. the flow the current git remote helper is expecting is very similar to your video:
* song has a white list of npubs that can create repositories (just sk 79 in this example?)
* create git repo locally: `git init && echo "example" > README.md && git commit -am "initial commit"`
* create git announcement `ngit init --identifier my-repo --relays wss://git.oursong.com/npub123/my-repo --clone https://git.oursong.com/npub123/my-repo`
* `git remote add origin nostr://npub123/my-repo?relayhint=git.oursong.com | git push -u`
* song will receive the receive the state announcement nostr event which will authorise the push

2024-08-26 11:38:22

- reply

Implemented in ngit v1.4

2024-08-26 11:35:24

- reply

I implemented this in ngit v1.4 btw. It also stores the refs in a nostr event so an evil hit server can't issue you the wrong head.

2024-08-21 21:57:26

- reply

The repo announcement event can optionally list other maintainers.
A fork, in the tradition sense, can be created by issuing a repo announcement using a different identifier.
Alternatively, using the same identifier by an npub thats not listed as maintainer in the original; but it's polite to use a different identifier / name to avoid confusion.

2024-08-21 15:41:09

- reply

Its in the ngit repository: https://gitworkshop.dev/r/naddr1qqzxuemfwsqs6amnwvaz7tmwdaejumr0dspzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqvzqqqrhnym0k2qj

2024-08-20 12:09:22

- reply

@npub16r0…z5pl may be interested dispute his current keyword mute list

2024-08-20 12:08:13

#GitViaNostr just got 10x easier with a git plugin included in ngit 1.4
clone with a nostr url. any branch prefixed with `pr/` is an open proposal on nostr.
submit it to as a proposal via nostr by pushing a branch with a `pr/` prefix.
see https://gitworkshop.dev for a quick start guide
I'd love feedback

2024-08-08 18:27:06

- reply

I'm glad you're here building our society with us. Immigrants bring more than minuses
https://www.youtube.com/watch?v=bJX5XHnONTI

2024-08-08 08:28:58

- reply

I could not replicate the problem at the time. Do the up and down keys work for you @nprofile…pqw8?

2024-07-24 16:26:26

ngit v1.3.0 released. download from https://gitworkshop.dev
highlights: offline use and sign in from your android phone using Amber
shout-outs: @npub1w4u…0jr5 for Amber and @npub1drv…seet for rust-nostr
change log:
- NIP-46 remote signing (from Amber, etc)
- `list` breaks down proposals by status
- local cache in `.git` to enable viewing proposals offline and reuse by other git clients
- introduced `fetch` to download recent proposals
- improved repo selection and handling of multiple maintainers
- unqiue branch names for proposals to prevent name conflicts
- login to different npubs for different repositories
- store login details in git config so they can be reused by other git clients ran locally
- add NIP-31 alt tags to events
- add euc marker per NIP-34 tweak
- fix: ensure repo events of all maintainers are tagged in proposals
- fix: stop filtering out very large patches

2024-07-23 09:55:54

- reply

Is this any better? https://image.nostr.build/dd53c6d9c18ec70bbd104eeba9467d28bf5afc98bfc21e5f9e891370387399da.jpg

2024-07-23 08:48:17

- reply

I like the idea of keeping the information at the bottom and somehow make the author stand out. I'll play about with it.

2024-07-23 07:52:52

- reply

I explored other options, in vain, for making the repo summary card clearer for multiple maintainers whilst maintaining its simplicity.
I could revert to 'Alexandra by Silberengel' at the top and the slightly awkward 'other maintainers: liminal' at the bottom.

2024-07-23 07:17:54

- reply

The first user listed is the author of the event https://image.nostr.build/3b6f1812b081c4c17d54f7e7ba81a4e22fa67ae80ba6fb2d4acfe07958b13b88.jpg

2024-07-22 13:49:36

- reply

deleting didnt because the event belongs to a different user: @npub1m3x…a5sf
I sort of forget what the problem was now. Does it still need to be deleted, or the maintainers realigned?
The best way to have consistent maintainers is for all maintainers to issue an announcement which list each other.
If the repository has an accurate `maintainers.yaml` file, it should be auto-populated with these details when each maintainer runs `ngit init`.

2024-07-22 13:44:09

- reply

It turns out you didn't. The event I linked belongs to: @npub1m3x…a5sf

2024-07-20 22:03:54

- reply

That's a good idea

2024-07-20 21:16:07

- reply

It's good but not essential for each maintainer to issue a repo event. In this case it appears two npubs have issued an announcement listing different, but overlapping maintainers.
When you select a repo annoucement, it will display all the proposals and issues that tag that announcement or the corresponding announcements of the other maintainers it lists. Irrespective of whether or not they have issued one yet.
Similarly, if you create an issue it will tag it with the same set of announcement events.
Does this make any sense?
Ngit sort of works like this as well.
There is certainly a lot of room for improvement on how related and unrelated announcements that share an identifier get listed on the https://gitworkshop.dev/repo page. Suggestions welcome.
Do you think the author of the announcement needs to be more prominent somehow when there are additional maintainers?

2024-07-13 19:13:52

- reply

I see whst you mean now. I wasn't looking at the recent proposals section on the homepage.
What you are seeing is one cover letter and one commit from the same proposal but listed separately.
There are two problems uncovered here:
1) 'recent proposals' should just show the proposal root and not each each commit.
2) links to a commit (or a reply for that matter) should take you to the proposal page with the specific commit / reply highlighted.
I'll look onto this next week.

2024-07-09 07:50:00

- reply

Ouch. I didn't realise you weren't using a version with the fix.
I've added v1.3-beta1 which includes the fix https://gitworkshop.dev/ngit
Please nag me every day if you are having an issue like that.

2024-07-04 10:57:05

- reply

I'm only aware of the experimental frostr. https://github.com/nickfarrow/frostr

2024-07-04 06:33:54

- reply

I'd be interestdd to hear how you get on. The CI pipelines should 'just work' but im interested to know if they donin practice. Also intergration with deployment solutions might require more setup.
In was thinking of creating a DVM to run CI against proposals posted nostr using nip34. See gitworkshop.dev

2024-07-01 18:07:20

- reply

How are you getting on getting set up with an alternative?

2024-07-01 07:16:52

- reply

There is so much design space in #GitViaNostr, so few of us working on it and hardly any usage, that it makes less sense to duplicate functionality right now.
It is somewhat inevitable and eventually healthy when things are more mature as projects die, new projects do things better or on different stacks, etc.

2024-07-01 07:09:38

- reply

Welcome to the bizarre!

2024-07-01 07:05:01

- reply

I think we are probably long overdue a dev call!

2024-07-01 06:50:51

I've been thinking about how to improve #GitViaNostr
* make it more git native experience
* reduce the role of the git server
* integrate releases
Here is a concept ngit quick start guide: https://gitworkshop.dev/concept
I'd love your feedback
I've already started to build out some of the new features
@npub16r0…z5pl @npub1m4n…c2jl @npub1wqf…qsyn @npub1upl…sfek @npub1elt…cume @npub180c…h6w6

2024-06-25 07:03:50

- reply

How do you withdraw all funds on a federation to an existing lightning channel? I only have the option to send to another federation or setup a new channel.

2024-06-10 18:01:11

- reply

Thanks for your work on both this and Amber btw

2024-06-10 14:53:26

- reply

ndk supports the use of client or server-side caches. It currently stores every event it receives and begins flushing older(?) events when it reaches a configurable limit of 10,000.
I think a cache adapter for a local relay would be nice. It could simply look for a local relay on localhost:4869 and use that if it exists; optionally fallbacking to the in-browser dexie adapter.
What do you think @npub1zuu…c2uc @npub1l2v…ajft?

2024-06-10 14:41:02

- reply

Is there a mechanism for a client to indicate an event can be flushed from the relay?

2024-06-10 14:23:27

- reply

Yes. I can't believe this pain point still exists. It shouldn't be that hard to solve yet we as a developer community haven't sovled it.

2024-06-10 14:14:05

What's the point in a local relay? Is it a cross-client cache that is regularly flushed or place to store only important events? @npub1gcx…nj5z's Amethyst and @npub1ye5…knpr 's Nostudel both support them.
eg. android: Citrine by @npub1w4u…0jr5; desktop: nostr-relay-tray by @npub1tsj…qm8t

2024-06-07 12:37:20

- reply

Thanks for reporting

2024-06-07 12:30:42

- reply

What's a meter?

2024-06-07 09:11:23

- reply

fixed

2024-06-06 20:23:45

- reply

Its only the diffs of new proposed changes that get embedded in nostr events. These are proposals which could be submitted by anyone.
To get the full history of commits, use a git server listed in the repository announcement event.

2024-06-06 19:33:43

- reply

Yes. The maintainer could easily move to a different git server by changing the clone property using `ngit init`

2024-06-06 19:30:35

- reply

`ngit init` doesnt create anything on any git server but just acts as a pointer.
It assumes you have already pushed the repository to those servers.
creates a repo event.

2024-06-06 19:28:12

- reply

A proposal can act just like a PR.
If you run `ngit list` and checkout a proposal it will create a local branch for you.
The author can add extra commits using `ngit push`
you can run `ngit pull` from local branch and it will pull these extra commits.

2024-06-06 18:55:36

- reply

You do so much for the cause of gitworkshop / ngit. Thanks. I appreciate it more than you think.

2024-06-06 18:45:55

- reply

The binaries are available for download from gitworkshop.dev/ngit but I'd love to add support for releases as nostr events so the bi airies are signed.
Zap.store's approach of using bossom for the binairies is also nice.

2024-06-06 18:39:00

- reply

I think `git clone nostr://naddr123` should proxy s clone request to the git server listed in the repo event and create remote branches from all open proposals. That's near the top of my todo list

2024-06-06 18:25:52

- reply

The prototype I made worked like that but in practice it is quite inefficent and problematic for large repositories with lots of commits.
Its works well for a nostr event to point to one or more git servers to fetch the latest code and exchange proposes patches and related discussion in nostr events.
`ngit send` to share a proposal (patch)
`ngit list` to review existing proposals

2024-06-06 18:18:13

- reply

You only need to install rust ifnyoubwant tonbuild from sourcr. You can just download the binaries listed on gitworkshop.dev/ngit
I think I'll add zapstore style releases as nostr events and host the binaries via blossom.
I'm also happy to use a magnet link.

2024-06-06 18:08:55

- reply

Yes. I should finish this one off as @npub107j…ncxg has he hands full with a new born at the moment.

2024-06-06 18:00:06

- reply

I've had 2 weeks away from my desk so no real progress. I tried using the caching functionality with ndk but it appeared buggy. Perhaps I missunderstand how the ndk feature is supposed to work.
The end goal is to use a local relay that can be shared across clients but caching is probably a useful interim solution if its built into ndk.

2024-06-04 17:06:50

- reply

It arrived after a few restarts of Minibits but with no other message than 'zap recieved' message. I'm sure my capping experience was better with alby.

2024-06-04 09:16:49

- reply

Your opinion hasn't arrived.

2024-06-04 08:03:58

- reply

@npub1myg…sn5p what is the status of g-hole?

2024-06-04 07:59:07

- reply

I'd like to make a nostr git remote helper that will update a state event and push to multiple git servers listed in the announcement event

2024-06-04 07:56:38

- reply

I also push to github and include in the repository announcement event.
I'm excited about the prospect of song. Push permissions are only based on whether the head commit is listed in the repo state event.

2024-06-04 07:45:40

- reply

This is what I use as a git server for ngit and gitworkshop.

2024-06-04 07:43:43

- reply

The guys at codeberg host a gitea instance for open source projects.

2024-06-04 07:41:55

- reply

Have you considered @npub180c…h6w6's song for a self hosted option?

2024-06-03 20:19:47

- reply

Check out gitworkshop.dev

2024-06-03 06:02:44

- reply

Thanks. I'll fix this when I'm back at my desk next week.

2024-05-30 20:07:30

- reply

a heavily curated selfie

2024-05-30 20:04:38

- reply

They were oblivious. The people on the other tables were very understanding. One of them handed me a wine cooler to empty the vomit into.

2024-05-30 19:52:29

At a restaurant this evening my daughter was being sick into my cupped hands just as, 4-feet away, some marketing-exec-type was having an Instagram moment

2024-05-30 07:41:19

- reply

When would a QR with the actual diff embedded be better than an QR with an nevent?

2024-05-27 17:46:39

- reply

This would be great for contact list recovery on metadata.nostr.com

2024-05-27 07:33:43

- reply

V60! What method do you use?

2024-05-24 16:29:06

- reply

just pushed an update to include logout

2024-05-24 13:00:37

- reply

I actually meant this issue:
#note1m5q…zx8d

2024-05-24 12:57:53

- reply

this is another good reason:
#note1zlh…hcsl

2024-05-24 12:53:10

- reply

nostr links within event content are now displayed. There are previews for repos, issue and patches.
#nevent1q…5wak
I'm now thinking it would be a lot better to display a wiki instead of the ReadMe on the repository homepage.
What do you think @npub1wqf…zusk cqsyn @npub1l5s…gx9z @npub1896…x5ge?
This would require adding support for showing wiki content but that's no bad thing. Showing the ReadMe by querying the server's Web API feels dirty. Different git server implementations use a different API. Its just not a great setup.

2024-05-24 12:39:27

- reply

resolved by these two commits:
commit 7dba21cece8b78635d7569627aba95cc20291993 - embedded events
commit ea07b55491e278ea0a4d6e70b5fe436055cad337 - show repo, issue and patch as preview with link to event

2024-05-24 12:36:59

- reply

This could be further enhanced by:
1) better previews for other kinds (eg wiki)
2) the ability to open specialised kinds in NIP-89 clients
3) the ability revealing threaded conversations of embedded events

2024-05-24 09:34:26

- reply

patch kind with multi line commit message: #nevent1q…wzhf

2024-05-24 09:27:14

- reply

testing previews...
issue kind looks like this: #note143m…mquc
patch kind looks like this: #note12ff…rxnh
repo kind looks like this:
#naddr1qq…pk39

2024-05-23 16:08:16

- reply

this activity feed isn't currently covered of by another issue, It's somewhat similar to #note1ugj…l9ym but for followed repos. It would be much easiler to implement if we used the nip34 reply kind, but that would limit reach.

2024-05-23 16:04:33

- reply

this issue is waiting on the implementation of caching

2024-05-23 15:56:06

- reply

there is overlap with this issue:
gitworkshop.dev/r/naddr1qvzqqqrhnypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqq9kw6t5wahhy6mndphhqucjqc6/issues/note1gj2skkmmp0zst29m0dhaq70de8tw7wfjdt5q829u5h090dfrgr3qqs59r2

2024-05-23 15:55:50

- reply

there is overlap with this issue:
https://gitworkshop.dev/r/naddr1qvzqqqrhnypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqq9kw6t5wahhy6mndphhqucjqc6/issues/note1gj2skkmmp0zst29m0dhaq70de8tw7wfjdt5q829u5h090dfrgr3qqs59r2

2024-05-23 15:54:05

- reply

I've added page labels in commit c872965cdca0548e656ed647dfaa3256770be181 which should fix this

2024-05-23 15:04:16

- reply

resolved by commit 7cb3df2dff622c42b8e62f5b57dfcfaed180b5b7

2024-05-23 15:03:28

- reply

resolved by commit 7cb3df2dff622c42b8e62f5b57dfcfaed180b5b7

2024-05-23 13:52:50

- reply

ngit also uses NIP-31 alt tags for everything, at least on the main branch.

2024-05-23 13:03:04

- reply

I've just added NIP-31 alt tags to git events produced by gitworkhop.dev.
I'll update ngit also.

2024-05-23 12:28:13

- reply

First we need to extended rich rendering of bech32 entities beyond npubs to events. this is tracked in:
#note1rs5…qxds
https://gitworkshop.dev/r/naddr1qvzqqqrhnypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqq9kw6t5wahhy6mndphhqucjqc6/issues/note1rs5shxk8ems0d878tymvntej4zcv4rvg7ntcpac5539xrcvvntss2vqxds
Then we need to enable launching unsupported events in other applications. Perhaps NIP-89 would be better than hardcoding my favorite client (eg wikifreepedia) for each kind?
Your 2) is a good idea. There are some some interesting UX options for when note recommends viewing a nostr event in a particular client by linking directly to it.
I'm not sure about 3). Wont it be clear from the context that it is the wiki landing page for the repository?
PS: I just created a NIP-89 application handler for gitworkshop.dev. #naddr1qq…uzvz
you can recommended for nip34 event kinds here:
https://nostrapp.link/a/naddr1qqxnzde3xc6rvv3n8qun2v3eqgs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngrqsqqql8ky0uzvz/users

2024-05-23 12:04:45

- reply

Thanks

2024-05-23 11:27:17

- reply

I have added a /e/<bech32> which handles repo, patch, and issue events and npubs. I then created a NIP-89 application handler
https://nostrapp.link/a/naddr1qqxnzde3xc6rvv3n8qun2v3eqgs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngrqsqqql8ky0uzvz/reviews
I can't work out how to create NIP-89 recommendation events with nostrapp.link. what's the best way of doing that?

2024-05-23 07:09:22

- reply

the SilberWitch entry has an event ID of
fb29b7d99b662bfd929178de34f724e31f51202a71608561ddcb67069323139d
sw_gitcitadel (GitCitadel fork) entry has a event ID of
38566adf76ae5e533b20fe2076be42b7c05d2cd7d29740abd6fd3223b158c0d9

2024-05-22 15:46:11

- reply

getting the event id and deleting it with delete.nostr.com seemed to work. getting the event id isn't so easy as I don't expose the raw repo event anywhere.
I'll build deleting into the interface. Maybe warning if there are existing proposals / issues / any other references.